MCP Stories From The Field

We’re nearly two weeks out from Perplexity CTO Denis Yarats’ announcement that  the company is dropping the Model Context Protocol (MCP) and switching to direct APIs and CLIs (and Perplexity’s new Agent API product). The interview sparked a wave of debate, with Garry Tan agreeing, tweeting “MCP sucks honestly”, and a host of entrepreneurs and vibe coders piling on, while enterprise and security-focused voices pushed back.

Honestly, there’s no new information from the last N times this debate has happened in the last 15 months since MCP was announced, and it should be obvious that MCP is far from dead, despite the recurring hate. The arguments for MCP's have been made many times over by engineers smarter than me, so I won’t repeat them here. 

This isn’t quite tabs vs. spaces, even if it feels that way sometimes. This debate isn’t recurring for religious reasons, it’s the symptom of a huge gap in the market. 

Instead of taking a hardline position on MCPs flaws, I’ll just share what I see every day in my job, talking to the development organizations behind many of the largest and most complex codebases in the world. Yes, some are governments and banks and manufacturers with 50-year-old COBOL codebases, but some are the most forward-thinking tech companies out there. And today, I’m seeing three emergent patterns for dealing with MCPs at scale, and the gaps in the context layer market:

Careful MCP scoping and quality control

I tweeted a while ago that Stripe’s blog post about their Minion agents was basically a guide for dev tools founders, and I want to zoom in on one of these screenshots

Stripe explains how their Toolshed layer works in more detail in their second Minions blog post. 

To support all of these, we built a centralized internal MCP server called Toolshed, which makes it easy for Stripe engineers to author new tools and make them automatically discoverable to our agentic systems. All our agentic systems are able to use Toolshed as a shared capability layer; adding a tool to Toolshed immediately grants capabilities to our whole fleet of hundreds of different agents.

Toolshed currently contains nearly 500 MCP tools for internal systems and SaaS platforms we use at Stripe. Agents perform best when given a “smaller box” with a tastefully curated set of tools, so we configure different agents to request only a subset of Toolshed tools relevant to their task. Minions are no exception and are provided an intentionally small subset of tools by default, although per-user customizability allows engineers to configure additional thematically grouped sets of tools for their own minions to use.

Since minions operate autonomously with full freedom to call their MCP tools, we also have an internal security control framework that ensures they can’t use their tools to perform destructive actions. As a first line of defense, though, our devboxes already run in our QA environment, and consequently, minions don’t have access to real user data, Stripe’s production services, or arbitrary network egress. This is no accident: we built isolated devboxes deliberately, so humans have an environment they can experiment within safely. But, as with so much else, a development environment that’s safe for humans has proven to be just as useful for minions.

Stripe’s blog post describes an in-house infrastructure layer that acts as a gate for MCPs. Each internal agent (presumably they have dozens or hundreds of different special-purpose minions and other agents, beyond just “inner loop” coding agents like Cursor, Amp, Claude Code, and Codex). 

(I’d love to hear from developers at Stripe about examples here. Of the 500+ MCP tools out there, how do you decide who gets what? Is the access hard gated, or can agents search for the tool they need?)

Another customer (2k+ developers) I spoke to in January described an official, internal registry of MCPs available to their developers, plus device-level monitoring to track when team members violate that registry and access external MCPs (which is permitted, but tracked). They want developers to explore and write their own MCPs! Ultimately, questions around reliable authentication and authorization are all that are holding them back.

Like I said in my tweet above: building infrastructure like Stripe’s Toolshed, or MCP registries that are tunable to a customer’s risk appetite, for every other company in the world is a massive opportunity and need.

MCP multiplexing

I spoke to a company recently (just under 1k developers) that built their own “Code Mode”-style MCP router for all developers to use. Similar to Stripe’s approach above, this platform allows the team to roll our MCPs to every developer instantly. But instead of controlling context bloat via scoping, their platform provides agents with the ability to search, as part of the core agent loop, for an MCP (or tool) to solve a need:

If we start putting a bunch of our tools into Claude Code, you start eating up the context window too quickly.

What I want is a single platform that is an entry point that can fan out to all of the MCPs we use.

I don’t have details of the implementation, but the description painted the picture of a Cloudflare search() and execute()-like interface. It’s fun to think about where this pattern goes: will agents run two layers of searches (or write JavaScript to do so), first for MCP servers, and then for tools provided by that MCP server? We do know that a lack of tool visibility can cause problems downstream, and this abstraction could get messy. Circling back to the original topic that spawned this article, CLIs used in place of MCP servers create discoverability gaps. One customer told me:

When we prompted our agent to use the JIRA CLI early on, it wasn’t good at using those capabilities. With MCP tools, where it has descriptions for the capabilities and input parameters, it was much better at adhering to it. This probably depends on the CLI; the GitHub CLI is so broadly used, but that’s not the case for others.

Will agents pay similar costs when using MCP “multiplexers”, without descriptions and schemas pre-loaded?

This debate is alive and well. I’m excited for the future.

Let a million MCPs bloom

Finally, I spoke to another company in early March with 3,000+ developers that described their approach:

We’re a tech-first shop, we’re building a ton of MCPs internally. It’s totally democratized internally, in terms of teams having the ability to build and ship MCPs to make context available to some audience.

The first time I heard this sort of approach as an intentional strategy was late last year (with a larger, older, less tech-first company). It surprised me a bit, and I (naively) interpreted it as tech-debt-in-the-making. But hearing it from more directions now makes me question that knee-jerk reaction, and I can see the appeal. 

It’s the wild west out there; CISOs are worried that exerting too much control could lead to “black market” MCPs popping up internally that operate outside of security and legal boundaries. Or, by locking too much down, execs could slow the company down, the worst sin of all today.

And frankly, I don’t have details on the MCP authentication/authorization mechanisms this company used. Perhaps MCP control is being enforced at the auth layer?

I sincerely wonder if we’ll see a shift if (when) performance or security incidents arise as a result. 

Clients and infrastructure aren’t living up to this moment

My takeaway is that there is no consensus, which is a familiar place in dev tools. What’s clear is that, at scale, a structured format to control the context layer is needed. Who will sign up to help companies manage the unpredictable and infinite combinations of services of interest? If the agent clients continue to ignore this need for the enterprise, or can’t get it right, I expect to see billion dollar startups in this space. Or perhaps it’ll all be consumed by the agent auth ecosystem? I’m excited, regardless.

And in the meantime, we’ll continue to build Sourcegraph search and Deep Search as native for agents, whether via MCP or CLI. And our new Agent Advocate will set the standard for agent enablement.

But one consensus is clear: every single enterprise I’ve spoken to in the last 3 months (dozens and dozens of them) uses MCP heavily. It goes without saying, but the AI solopreneur dev tools bubble on X is not representative of the real world.

A special thanks to the following individuals for their contributions to this blog post: Justin Dorfman and Stephanie Jarmak