Your product is about to become a tool an agent picks up. Decide now whether it should be.

MCP just locked its biggest revision ever, and it quietly changes the unit of distribution from "a user opens your app" to "an agent calls your tool." That's a strategy decision, not an integration ticket.

A couple of weeks ago the Model Context Protocol shipped its final 2026-07-28 spec — the largest revision since it launched. Most of the coverage was about the plumbing: it's stateless now, it runs on ordinary HTTP, the session handshake is gone. Real changes, and if you operate a server they matter. But that's not the part I'd flag for makers. The part I'd flag is what MCP has quietly become while everyone argued about transports: the way software gets used by agents instead of by people. There are close to ten thousand servers in the official registry now, MCP lives under the Linux Foundation with AWS, Google, Microsoft and Salesforce behind it, and this same release added MCP Apps — servers can now render their own interactive UI right inside the agent. The protocol stopped being a developer curiosity. It became a distribution surface.

Here's the shift, plainly. For twenty years the unit of distribution was a human opening your thing. They found your site, signed up, clicked around. Everything we know about product — onboarding, activation, retention — assumes a person on the other end of the screen. MCP points at a different default: your customer asks their agent to do something, and the agent reaches for whatever tool can do it. Your product isn't the destination anymore. It's a capability the agent picks up mid-task, uses, and puts down. Nobody onboards. Nobody sees your landing page. The agent reads your tool definitions, decides if you're the right instrument for the step it's on, and calls you or doesn't.

That reframes a bunch of maker questions at once. Your tool descriptions are now your marketing copy, and the audience is a model deciding whether to invoke you. Your schema is your UX. And the thing you spent months polishing — the interface — may never get looked at by a human again, because MCP Apps means the agent renders a small purpose-built surface at the moment of use and skips the rest. If your product is a discrete, callable action — send the invoice, book the room, run the check — this is very good news. You can be useful to someone who never signs up, never learns your name, and never sees your brand. Distribution without a front door.

But I want to make the harder argument, because I live on the other side of it. Not every product should be a tool an agent picks up. I build Murror, an AI companion for understanding your own emotions, and "expose it as an MCP tool so agents can call it" is a genuinely bad idea for us, and it's worth being precise about why. The value of Murror isn't a returnable result. There's no output an agent could fetch on a user's behalf. The entire point is a person sitting with their own thoughts for ten minutes — the slowness, the privacy, the fact that it's them doing it and not a delegate. Wrap that in a tool call and you've automated away the only thing that was working. Some products are a step in someone's workflow. Some products are the place the workflow was trying to get them to. Those are different, and MCP makes you decide which one you are.

So the useful exercise this week isn't "how do I ship a server." It's one honest question: is your product an action or a destination? If the value is a result someone wants and doesn't care how they got — an action — then being agent-callable is close to free distribution and you should be looking hard at it before your competitor does. If the value is the experience of a person actually being there — a destination — then racing to become a tool call is optimizing for a future where your product's whole reason for existing has been abstracted away. Worse, you'll have spent your scarce weeks building the integration instead of the thing.

One more note if you decide you are an action, because MCP got this right and it's easy to skip past. The new spec routes every UI-initiated step through the same consent and audit path as a direct tool call — nothing happens to a user's data or account without the same permission gate. If you go agent-accessible, inherit that seriously. An agent acting on someone's behalf, with their stuff, at machine speed, is a lot of trust to be handed by someone who never saw your face. The makers who earn a place in the agent era won't be the ones who shipped a server fastest. They'll be the ones who were honest about whether they should — and, if they did, treated that borrowed trust like it was hard to get. Because it is.