MCP Gets Ready for the Real World

Code2

By: Craig Matsumoto


Popularity of the Model Context Protocol (MCP) has developers dreaming about a future where AI bots go whizzing about the Internet collecting data and completing tasks, all in automated fashion. We're not there yet. But the work to prepare for that future is well underway, judging by the enthusiasm at the MCP Developers Summit.

The grassroots conference gathered 300 developers in San Francisco. It was organized on short notice by Acorn Labs and sold out quickly, despite being held on the Friday before the U.S. Memorial Day holiday. That's how deep the interest runs.

Much of the conference focused on what's next for MCP—not only planned updates from Anthropic and the community, but also the community's wish list for enabling enterprise-grade agentic AI. Security is certainly high on that list (as we've discussed before), as is an official registry of MCP servers. But the most interesting wish-list items tie to a composable AI future, where agents and applications communicate with one another and with a multitude of servers, including third-party ones.

There's a soft-skill angle as well, because MCP's success is inspiring AI usage among non-developers. More on that momentarily.

The conference demonstrated the enthusiasm and community spirit that has helped MCP grow. But as developers know, most of the MCP work you're seeing in the press and on social media has targeted internal use cases. There are no illusions about the work required to make agentic AI wander more freely about the web. At the same time, there's plenty of energy and motivation to make that happen, with MCP as a catalyst. Alternative and complementary protocols exist, but MCP is the de facto standard at the moment and has the momentum to become a more formal standard.

(The talks at the conference are posted to the MCP Developers Summit YouTube channel, which is hosting a series of additional live talks as well.)

MCP's Rapid Rise


MCP provides a common way for AI agents and large language models (LLMs) to connect to data sources. It's often called the USB-C of AI. MCP goes further than APIs do, in that it exposes underlying capabilities. A database, for example, might have an MCP server that tells agents how to navigate a GUI or even how to manipulate the database (given proper authorization, of course).

MCP's rise exemplifies the viral effect of open-source software, but that's not the entire story. Anthropic, which developed the protocol for internal use, open-sourced it in November 2024, and momentum hit warp speed in the spring as OpenAI and other major players embraced it.

But as speakers at the Summit noted, MCP's spread is also due to a bit of happenstance: The protocol has limited scope, meaning it's relatively simple to build an MCP client or server. It helps that Anthropic provided reference examples and primed its LLM, Claude, to generate the code. That helped the protocol build a following as more companies dabble with its potential.

Plenty of organizations have launched MCP internally, further automating their AI operations. In the process, issues arise such as security and discovery (for example, looking up whether someone else already wrote the MCP server you need). They loom even larger when you think about agents reaching across the web to third-party data sources.

Meeting Security Challenges

Nobody claims MCP is fully baked in terms of security. Compare it to web surfing, where a security framework of identity, authorization, and authentication allows us to connect to sites across the Internet. Similar security standards for MCP would let agents (and humans!) connect to resources across the web.

Here's an example of the work being done in this area. OAuth 2.1 is the authorization standard cited in the latest MCP specification, and for now, every MCP device must act as its own authentication device. Aaron Parecki, director of identity standards at Okta, described recent IETF proposals that point toward OAuth being more centralized. Enterprises enjoy single-sign-on services like Okta; making MCP similarly convenient, albeit with the right security constraints, would likely be popular.

But developers also have to worry about attack vectors throughout the supply chain, as Arjun Sambamoorthy of Cisco noted. In addition to malicious servers and clients, there's the possibility of tool poisoning, in which a tool could do something malicious, such as examining file lists and downloading certain documents.

Registries: What's Even Out There?

While security is a primary concern, there's a more elementary gap: the ability to find out who else "speaks" MCP. The answer is to build an MCP registry. The problem is that everybody seems to have done this themselves, leading to myriad incomplete registries out there.

This is not just a bookkeeping issue; multiple speakers pointed out the need for an official MCP registry — and indeed, one is in the works. As explained by a trio of presenters from Block, GitHub, and the Pulse MCP project, the aim is to consolidate the many registries out there, within reason. The result will be huge, so the registry team is not going to include only basic search capabilities. The hope is that other developers will craft more specialized apps that perform advanced search and filtering on the registry, catering to different personas (such as developers vs. non-developers).

They envision end users interacting with these intermediate kinds of tools—enriched mirrors of the registry—rather than with the entire thing. This makes sense, as it gives the registry a modular feel and keeps the scope simple for the team building it.

State: MCP Gets Chatty

On the more esoteric side, speakers at the recent Summit discussed how a more stateful MCP could yield richer results, setting up agents to chain or collaborate to form fully autonomous systems.

This is described as composition, and it came up in multiple talks. Nick Cooper, a member of OpenAI's technical staff, outlined multiple forms this could take. One server could oversee multiple other servers and orchestrate activity among them. Separate servers could work in a federated manner. Agents could seek out other agents to delegate to.

One subtlety in all that is that agents and tools will need a way to work asynchronously, waiting for intermediate steps to complete. That wait might be measured in seconds, but speakers also said some jobs will benefit from wait times of hours or days.

Asynchronous tasks for MCP are in the works, as speakers from Anthropic noted, but that brings up additional concerns. Cooper noted that developers will need ways to direct a tool in-flight—for example, stopping it if a long-awaited response stops being useful to the user. Nicholas Aldridge, a principal engineer at AWS, noted that network issues could become a problem. He suggested the possibility of letting clients ask tools for a job status.

Aldridge and others also noted the need for state. AI agents in this asynchronous world can't all be stateless; they will need a way to retain and transfer context. Brenden Lane and Nitin Sharma of PayPal, who gave an extremely detailed talk about their implementation of MCP, noted the need for standardized state channels to make this happen. (They also noted the need for registries and publish-subscribe protocols as elements of a composable AI world.)

One possibility is for the MCP server itself to incorporate state and a user database (because stateful operations require retaining context about different users). Dina Kozlov, senior product manager at Cloudflare, demonstrated an example of how context can work, using MCP servers on Cloudflare combined with the platform's Durable Objects storage.

Soft Skills Needed

So far, MCP has been a developers' story, but what happens when non-technical employees get interested? It's a scaling issue, but also an issue of training and the soft skills necessary to avoid employee frustration (not to mention employees breaking rules out of impatience). Angie Jones, vice president of developer relations at Block, detailed how her company handled that issue in a matter of months.

Engineers at Block, the 12,000-employee company that owns applications such as Square and Cash App, developed an AI tool called Goose, which they eventually made into an MCP client. Goose was built as a developer time-saver. But as other departments took notice, Block had to grapple with adapting Goose to more general use cases. For example, the company didn't have MCP servers for non-engineering applications such as Snowflake or Google Workspace.

Goose also existed in a world of GitHub repositories and server builds—things non-developers didn't understand. That didn't stop them from trying, which led to calls for help when they got stuck. Block had to operationalize AI, Jones said. The company created a team to build MCP servers on-request (Block doesn't use any external MCP servers, on principle); developed authentication for MCP servers and integrated it with their identity provider; and automated the installation and updating of Goose, the latter being a step that employees had quickly fallen behind on.

A2A et al

MCP has the world's attention, but it's not the only agentic AI protocol out there. A2A, launched by Google earlier this year, is a complementary protocol that handles agent-to-agent communications. Its scope is different from MCP's, but it's easy to envision the two overlapping as they mature.

Laurie Voss, vice president of developer relations at LlamaIndex, ran through roughly a dozen alternative protocols in a lightning-round talk. Some have features that MCP lacks, such as asynchronous task support, but Voss said MCP has adoption on its side, particularly because it started by addressing a small initial problem. Now it can expand to bigger things — such as asynchronous tasks.

The multitude of protocols brings up an important point, though: MCP is not a true standard. That might have to be the protocol's next step. For now, Anthropic seems happy to curate it, and the community is glad to have that guiding hand. As MCP scales in usage and capabilities, it seems likely that both sides will tire of that arrangement. Handing off MCP to a standards organization seems like an inevitable step.