Ryan chats with Srini Venkatesan, CTO at PayPal, about validating AI-generated deterministic code for security, developing autonomous SDLC harnesses with iterative feedback loops, and creating a seamless headless checkout experience.

1218. This week, we look at "dog-directed speech" — the high-pitched, sing-songy register people love to use with dogs — and what the research says about whether dogs actually like it. Then we look at why it's "bated breath" and not "baited breath," and how Shakespeare used the phrase in "The Merchant of Venice." Plus, we have a familect about "spicy water."

The dog segment was by Karen Lunde, a career writer and editor. She writes I'll Go First, a newsletter where she shares her story, and then hands you a writing prompt and a metaphorical pen. Find her at igofirst.org.

Save the date for Grammarpalooza — The Game Show: Thursday, September 24 at 5 p.m. PT / 8 p.m. ET.

A hearty thank-you to our Keepers of the Commas and one Immortal on Patreon. We appreciate your support!

• Larry Rosenblum
• Mahala Russell
• George Wilson
• Laurel Paul
• Linda Cox
• Birna Anna Björnsdóttir
• Marlen Ruiz

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Find an edited transcript.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Castria Communications
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

---

Hosted on Acast. See acast.com/privacy for more information.

Download audio: https://sphinx.acast.com/p/open/s/69c1476c007cdcf83fc0964b/e/6a970b03da248a131d12ac61/media.mp3

Welcome in! You’ve entered, Only Malware in the Building. Join us each month to sip tea and solve mysteries about today’s most interesting threats. Your host is ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Selena Larson⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Proofpoint⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ intelligence analyst and host of their podcast ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠DISCARDED⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Inspired by the residents of a building in New York’s exclusive upper west side, Selena is joined by her co-hosts ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠N2K Networks⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Dave Bittner⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Keith Mularski⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, former FBI cybercrime investigator and now Chief Global Ambassador at ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Qintel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.

Being a security researcher is a bit like being a detective: you gather clues, analyze the evidence, and consult the experts to solve the cyber puzzle. This week, Dave, Selena, and Keith explore the pros and cons of allowing select U.S. companies to conduct offensive cyber operations under strict government guardrails. They discuss what the proposed framework could mean for private-sector security researchers, how researchers have already been operating in this space for years, and where the line between defense and offense gets blurry. They also look at how adversaries such as China and Russia use proxy companies and other private-sector entities to conduct cyber operations—and consider whether giving trusted U.S. companies similar capabilities could strengthen cyber defenses or create new risks.

Download audio: https://traffic.megaphone.fm/CYBW1541117321.mp3

---

Almost all of the noise about MCP has been about tools. Everybody ships tools, everybody argues about tools, everybody counts how many tools their server exposes as if that were the score. But the protocol has two other primitives that get a fraction of the attention and are, I would argue, the genuinely underrated good parts: prompts and resources. Prompts are repackaged, ready-to-run queries — the good questions, pre-written and parameterized. Resources are the documents and context an agent should have alongside those questions — the reference material, the docs, the data. And the more time I spend with them, the more I think prompts and resources are ideas we should be dragging back out of MCP and into REST and GraphQL, because they solve a problem those APIs have always had and never named.

Start with prompts, because they are the ones that surprised me. An MCP prompt is, at its heart, a curated query — a specific, useful, parameterized way of asking something, written by whoever knows the system best and handed to the consumer ready to run. It is the difference between giving someone two hundred operations and saying “good luck” and giving them the fifteen questions that are actually worth asking, phrased the way an expert would phrase them. When I built out the MCP prompts and resources layer across API Evangelist and APIs.io, the prompts turned out to be the part people got the most value from the fastest, because they collapse the gap between “you technically can ask this” and “here is the good question, ready to go.” That is a documentation and onboarding win that has nothing to do with agents specifically — it is just good API design that MCP happened to formalize.

Now resources. A resource in MCP is context that rides along — the docs, the schema, the reference data, the this-is-how-this-actually-works material that a consumer needs in order to use a capability well. For the entire history of APIs, this stuff has lived somewhere else: in a separate docs portal, in a wiki, in a getting-started guide that drifts out of sync with the API it describes. MCP’s move is to make the accompanying context a first-class part of the interface itself, sitting right next to the capability instead of two clicks and one stale page away. When an agent — or a human — reaches for a capability, the resource that explains it comes along. That co-location of capability and context is quietly one of the best ideas in the whole protocol, and it is the one nobody is putting on their launch slides.

Here is what I keep thinking: neither of these ideas is actually specific to MCP. A curated, parameterized query and a piece of co-located reference context are things every REST and GraphQL API would be better for having, and almost none of them do. We have spent years treating the OpenAPI as the operations and the docs as a separate deliverable, when MCP is quietly demonstrating that the good questions and the accompanying context belong with the interface. There is nothing stopping us from bringing prompts back to REST as blessed, parameterized example queries shipped alongside the spec, or bringing resources back as reference context bound to operations instead of exiled to a portal. MCP did not invent the need. It just built primitives for it, and those primitives are portable ideas we should steal.

This also reframes what MCP is actually contributing, which matters after I have spent a whole series calling it last-mile plumbing and poking at its authorization gaps. The tools are the least novel part — an agent could already curl a well-described API, as I have argued. The prompts and resources are where MCP is teaching us something we did not already know how to express: that an interface should ship with its best questions and its context attached. That is a design lesson worth keeping even in a hypothetical future where the specific protocol fades. The plumbing is disposable. The idea that capability, curated queries, and context belong together is not.

So if you are building an MCP server, spend real effort on the prompts and resources, not just the tools — they are probably where your consumers, human and agent alike, will get the most value, and they are the part most servers neglect. And if you are building a plain old REST or GraphQL API with no MCP anywhere in sight, steal the ideas anyway. Ship your best questions as parameterized prompts. Bind your reference context to your operations instead of banishing it to a docs site that goes stale. MCP’s tools got all the attention, but its prompts and resources are the parts I would most want to keep, and the parts I would most encourage you to bring home to whatever API you are already building.

Blazorise 2.3.2 improves Graph performance with large datasets, speeds up Autocomplete keyboard navigation, improves SVG Charts, and fixes DatePicker and FluentUI issues.