MCP: Origins and Requests For Startups — Theodora Chu, Model Context Protocol PM, Anthropic

You are working with a model when you remember a Slack message that explains the problem. You copy it into the conversation. Then you find the relevant Sentry error logs and paste those too. In Theodora Chu’s account, this repeated transfer of context was the starting point for MCP: around mid-2024, co-creators David Soria Parra and Justin Spahr-Summers wanted Claude, or any other language model, to reach outside its context window and retrieve what it needed.

The ambition extended beyond retrieval. If a model could reach external systems, it could bring back context and take actions there. Model agency became the organizing problem: how do you give a model the ability to interact with the outside world?

An integration inside a closed ecosystem can require several kinds of work before it becomes usable: securing access through a business-development or partnership relationship, agreeing on an interface, and then implementing it. An open, standardized protocol would let more builders participate without repeating those negotiations for every client. As reasoning and tool calling improved, MCP’s creators wanted the integration ecosystem to let models put those capabilities to work.

A small internal team built the protocol and introduced it at Anthropic’s November Hack Week. Engineers began building servers to automate their own workflows and those of other teams. That internal enthusiasm led to the public Model Context Protocol launch on November 25, 2024.

Public interest did not immediately match the internal response. Builders asked why another protocol was necessary, why it needed to be open source, and whether models could already call tools. The distinction became clearer when people could use MCP to automate something they actually did. Existing tool-calling ability was only part of the problem; builders still needed a practical way to connect those models to their systems.

Chu identifies Cursor’s adoption as the next major source of momentum, with MCP spreading across coding environments including VS Code and Sourcegraph. This is a story about growing usage rather than a strict sequence of first integrations: Sourcegraph was already named in the original launch announcement. By the time of the talk, Chu also reported adoption by Google, Microsoft, and OpenAI.

The criterion for becoming a standard remained usefulness to builders. Chu invited users to report problems and contribute fixes directly, treating community feedback and pull requests as part of how the protocol would improve. The ecosystem had reached this point less than a year after launch.

For Chu, an agent depends on the model’s intelligence to choose actions and decide what to do. Delegating to it resembles assigning a task to a person: you have an intended outcome without knowing their exact response in advance. MCP’s design therefore anticipates models becoming more capable over time, rather than assuming every useful action sequence must be fixed beforehand.

That expectation informed the move to Streamable HTTP, a decision Chu describes as controversial but useful for communication involving agents. Her shorthand about greater bidirectionality needs one technical distinction: the older HTTP+SSE transport already carried messages in both directions, using SSE and client HTTP POST requests. Streamable HTTP replaced that transport arrangement with an endpoint supporting POST and GET; it can still use SSE. stdio also remained a standard transport.

A second assumption determined where complexity should live: the team expected many more servers than clients. If that prediction holds, making each server easier to build has broad benefits across the ecosystem. MCP therefore prioritizes server simplicity and server tooling, accepting additional client complexity when the two conflict. Chu explicitly leaves open the possibility that the prediction could be wrong; it is a design bet, not an observed law of the ecosystem.

The preceding six months of work had added remote MCP support and prompted a rethink of authentication. Chu acknowledges that the initial design was wrong and credits community contributors with explaining how it needed to work with identity providers. At the time of the talk, the correction was in the draft specification. The subsequent June 18 revision documented the authorization changes and elicitation discussed here; draft status matters when following the recording.

Alongside Streamable HTTP as the primary remote transport, the team updated SDKs and improved MCP Inspector. Inspector gives server builders a tool for debugging their integrations, and Chu considers it one of the project’s most underused tools. These changes address the practical work surrounding a server: connecting it, handling authorization, and understanding why an interaction is not behaving as expected.

Elicitation addresses an ordinary obstacle to useful agency: the user has not supplied enough information. Chu’s example is a flight-booking tool receiving a request for the best flight to Atlanta. The destination is clear, but the selection criterion is not. Best could mean cheapest or fastest. The draft feature lets the server request clarification from the end user and receive the answer back through the client.

The interaction has a simple sequence:

1. Receive the request to book the best flight to Atlanta.
2. Ask whether the user values the cheapest or fastest option.
3. Return the user’s preference to the server so it can continue with a defined criterion.

For example, if the user chooses fastest, the application can preserve the destination while filling in the missing preference. A compact application record would then look like this:

{
  "destination": "Atlanta",
  "preference": "fastest",
  "bookingStatus": "pending"
}

The clarification supplies a decision criterion; it does not itself book a flight.

The next capability was discovery. Work on a registry API aimed to make it easier for models to find MCP servers that had not been supplied upfront. That goal follows the same assumption about improving model intelligence: a more capable model may be able to identify a missing capability as well as use one already available to it.

Supporting this agent experience also required shared development patterns. Chu described plans for open-source examples from Anthropic and the community, so builders could learn useful conventions together. She paired that with a commitment to keeping MCP open and work on its next phase of governance.

Agent composition fits into the same client and server roles. Chu describes an agent as a server acting as a client, and vice versa: it can expose capabilities to one participant while consuming capabilities from another. That allows communication among agents, servers, and clients without making an agent a wholly separate category of integration.

An emerging standard still needs an ecosystem of useful implementations. Asked where founders should build, Chu puts most of her emphasis on servers:

These percentages express her priorities for builders, not measured market shares or expected returns.

Higher quality does not mean exposing every existing API endpoint as a separate tool. Chu criticizes that one-to-one wrapping because it skips the design question that matters: what capabilities will let a model complete the user’s task? An MCP server has three users: the end user, the client developer, and the model. Forgetting the model as a user makes it easy to produce an interface that mirrors a backend but is awkward for an agent to use.

Work backward from the intended interaction:

1. Identify the end user’s use cases.
2. Write the prompts the user is likely to give the model.
3. Determine which tools the model needs to respond correctly.

The resulting tool boundary should follow the task, rather than automatically inheriting the boundary of each API endpoint. This makes tool design an interface-design problem, not just an adapter-generation problem.

Domain coverage matters alongside interface quality. Much of the early ecosystem served developers, but the opportunity extends to sales, finance, legal work, and education. Builders with knowledge of those domains can identify the context and actions their users need, then expose capabilities that fit those workflows.

If servers become the larger population in the ecosystem, the tools used to build and operate them become valuable infrastructure. Chu identifies two settings with different audiences but a shared need for simpler server development:

• Internal enterprise deployments: MCP servers act as interfaces between teams.
• External products: Indie hackers and other builders expose capabilities to outside users.

Both create opportunities for hosting, testing, evaluations, and deployment tooling.

Automated server generation is the more speculative extension. As models improve at writing code and interacting with external systems, Chu imagines them creating their own MCP servers on the fly. The model would generate an integration when it needed one, instead of depending entirely on integrations prepared in advance. She describes this as a moonshot that may be early for the capabilities available at the time.

The final startup request concerns AI security, observability, and auditing. These needs extend beyond MCP: giving any AI application more access to external systems and real data increases its security and privacy implications. The same agency that makes integrations useful creates a need to understand and protect what those applications can reach and do. Chu closes by urging founders to build that infrastructure now.