Does Your Product Need an MCP Server?

A protocol almost nobody outside engineering has heard of just crossed ninety-seven million downloads a month. That's more than most Fortune 500 companies have employees, for something called the Model Context Protocol, or MCP if you'd rather not say all three words out loud in a meeting. And the meeting where your company decides what to actually do about it probably doesn't have a single product person sitting in it.

That's not a knock on engineering. It's just backwards. This piece is the missing half: what MCP actually is, why it just got a lot more real, and the two questions that decide whether your own product needs one.

MCP has been around since November 2024, when Anthropic released it quietly enough that it took a while to notice. The early growth was real but modest, about 100,000 downloads in the first month, mostly from engineers building AI coding tools. It solves a boring, expensive problem. Before it, every AI application needed a custom, one-off integration for every tool or data source it touched. MCP standardizes that connection once, so any compliant client can talk to any compliant server, the same basic idea as a USB-C port, except the thing plugging in is a language model instead of a laptop charger.

By December 2025, Anthropic had handed the protocol over entirely, donating it to a new Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI. That's the polite way of saying no single company owns it anymore, which is usually the moment a protocol stops being a bet and starts being infrastructure.

Then, on July 28 this year (2026), the protocol's maintainers shipped the update that mattered most for anyone planning to run this at scale. The core moved to a stateless architecture. Requests can now span multiple round trips. Routing happens through headers instead of workarounds. List results can be cached instead of re-fetched every time. And authorization, the part every enterprise security team had been complaining about since the beginning, got meaningfully harder to break. None of that is exciting to read. It's exactly the boring, plumbing-level work that decides whether something like this holds up once real companies start depending on it.

Roughly 28 percent of Fortune 500 companies are already running MCP servers in production, and the SDK download count sits at that 97 million a month, up from a hundred thousand in under two years. Coding tools got there first, which is exactly why product leaders are hearing about this secondhand: your engineers met MCP through Claude Code or Cursor months before anyone described it in a way a non-engineer would sit through.

The bigger tell is who's racing to build the other side of the connection. Salesforce, ServiceNow, and Microsoft are all actively exposing their own products as MCP servers right now, which means an agent can act inside those systems with actual structure instead of guessing at a screen. Gartner put AI-native development platforms on its short list of top strategic technology trends for the year. When your CRM vendor and your analyst firm are pointing at the same thing from opposite directions, it's usually not a fad anymore.

Here's the part almost nothing written about MCP actually answers: should your product be one of the things an agent can reach?

Not "should we do something with AI." That decision got made somewhere else in the company already. The real question is narrower and more useful: should this specific product, or this specific workflow inside it, be exposed through MCP, and to whom. Call it the Exposure Question, and it comes down to two smaller ones.

First, is someone already trying to connect an agent to you the hard way? Partners scraping your dashboard, customers asking their AI assistant to do something your product technically supports but has no structured way to hand off, a support team fielding the same "can your tool talk to my tool" question every week. That's not a hypothetical demand signal. That's a queue.

Second, would exposing this actually save someone a real, repeated task, or would it just look good on a slide? A well-scoped MCP server that lets an agent check an order status or pull a report on someone's behalf is worth building. One built because a competitor announced theirs first usually isn't, and it tends to show.

If the answer to both is no, that's a perfectly fine outcome. You get to go back to your actual roadmap.

You've likely met MCP without the name attached. Our design system guide covers Figma's own version of this, the Dev Mode and Code Connect stack that lets an AI coding tool read your design tokens directly instead of guessing at them from a screenshot. That's MCP, quietly doing its job inside a tool most product and design teams already use every day. It's a useful reference point precisely because nobody had to explain the acronym to use it. The integration just worked, which is the whole point of the protocol in the first place.

We ran into the less glamorous side of this ourselves. Our internal Hooman Dashboard has an MCP connection that, for a while, kept authenticating into a test workspace instead of the real one. Small bug, mildly embarrassing, and exactly the kind of thing that happens at a much larger and costlier scale inside enterprises adopting this. Authorization that doesn't map cleanly onto who's actually supposed to have access to what is the single most-cited pain point in enterprise MCP deployments, which is precisely what the July 28 update targeted. We fixed ours. The protocol just fixed a version of the same problem for everyone else.

Software Is Having Its Tailoring Moment covered why custom software got cheaper to own relative to buying something off the shelf, and it mentioned MCP briefly along the way, as one reason the old integration objection to custom builds is dissolving. What this piece is asking is narrower, and it applies no matter which side of that argument you land on: once your product exists, should an agent be able to reach into it directly. You can build fully custom and still get this wrong. You can buy an off-the-shelf platform and still get this right, if the vendor already exposed the right MCP server for you.

Google's A2A protocol handles agent-to-agent communication, a different layer than MCP's agent-to-tool connection, and the optimistic read is that the two stack neatly on top of each other. The other read, and the tech industry does love a good standards war, is that we end up with two or three competing layers doing overlapping jobs until one wins by attrition. Both readings are being argued right now by people who understand this far better than a single blog post can settle. Worth knowing the disagreement exists before you commit a roadmap to either side of it.

Once you expose something through MCP, or once an agent can already act inside your product some other way, a second question shows up right behind the first one: can the agent actually finish what it came to do. We covered that half of this separately in Is Your Website Ready for AI Shopping Agents?, which is about the completion problem on the browsing side. MCP and browser agents are solving different parts of the same shift: one gives an agent a structured way in, the other decides whether it can get anything done once it's there. Getting only one right just moves where the failure happens.

APIs took the better part of a decade to go from a nice-to-have to something a partner won't sign a contract without. MCP is on a similar path, just running at a noticeably faster clock speed, helped along by a foundation that isn't owned by one company and adoption numbers that would embarrass most startups' total user counts.

The Exposure Question doesn't need an answer this quarter. It needs to be asked in the same room as your actual product roadmap, not left to whichever engineer happens to read the changelog first.

Run the Exposure Question against one real workflow this week, not a hypothetical one, and see which side of the table it lands on.