One Year of MCP: From Local Tools to Asynchronous Agents

When a local protocol meets enterprise identity

An employee signs in through the company’s identity provider and expects access to their work tools. MCP’s first remote authentication design could not fit that arrangement cleanly: it combined issuing tokens and serving resources inside the MCP server. That could suit a startup connecting a public server to its own accounts, but enterprises already had a central authority for identity. The integration server needed to accept tokens issued elsewhere.

[Model Context Protocol (MCP)](https://modelcontextprotocol.io) is an open standard connecting AI applications to data and tools. Its first year moved from essentially local-only servers to remote connections in March 2025, revised enterprise authentication in June, and long-running tasks in late November. In the anniversary conversation, co-creator David Soria Parra identifies the adoption announcements around April from OpenAI, Microsoft, and Google as an inflection point, following early builders and clients such as Cursor and VS Code.

The anniversary also brought MCP into the [Agentic AI Foundation (AAIF)](https://agenticai.foundation) under the Linux Foundation. David describes its immediate purpose as neutral ownership, with MCP’s technical governance unchanged. Additional protocols should have substantial adoption and a complementary purpose; applications have more room for experimentation. The foundation should avoid collecting competing protocols for the same communication problem or taking on abandoned projects.

Authentication: separate the resource from the token issuer

MCP deliberately specifies how unfamiliar clients and servers should authenticate, using OAuth’s token-based access mechanism. David acknowledges that the first design reflected an incomplete understanding of enterprise requirements. With help from OAuth specialists, the June revision separated two responsibilities: - Token issuance: a separate authority provides the token used to obtain access. - Resource serving: the MCP server accepts the token and provides the requested resource. This separation lets MCP fit an existing identity system.

Passing a token and obtaining one are different problems. A token associated with an agent’s workload identity could be passed to an MCP server, but MCP did not yet prescribe how the agent should obtain it. Closed enterprise environments could arrange this themselves; unfamiliar clients and servers still lacked a satisfactory general solution for agents authenticating on a user’s behalf.

Transport: optional streams become missing capabilities

Streamable HTTP was designed to support both simple tool servers and stateful agents that need ongoing communication in both directions. The aim was to retain useful properties of standard input/output (stdio) connections while operating remotely. Standard HTTP provided a useful foundation, but clients could skip opening the server’s return stream. In practice, clients omitted it, leaving servers without the channel needed for requests back to the client, including model sampling.

Server-side state complicates horizontal scaling. A tool call, a subsequent request back to the client, and its response might reach different server instances. Those instances need to reunite the operation and its result, often through shared state such as Redis or Memcache. The approach is workable, but adds coordination that a single-server implementation does not need.

The next transport iteration was still being designed around three requirements: - Simple servers stay simple: exposing a tool should require little infrastructure. - Richer communication remains possible: agents may need full bidirectional streams. - Deployments can scale: transport coordination must work across server instances. Recent discussions brought engineers from Google, Microsoft, AWS, Anthropic, and OpenAI together around these constraints. MCP sought consensus while leaving decisions with roughly eight core maintainers, combining broad input with a small group able to move quickly.

The application decides what the model sees

MCP connects an AI application to servers; the model is not a protocol participant. The application decides how to present tools and orchestrate their execution. Loading every available tool description into context creates bloat. Progressive discovery offers another approach: provide enough information to begin, then let the model request details as needed. Tool-calling models can perform this pattern without specialized training, although training can improve how effectively they use it.

Programmatic MCP composes tool calls in code. A conventional loop calls tool A, returns its result to model inference, calls tool B, and returns again before combining results. Instead, the model can generate code that runs the sequence in a sandbox and passes intermediate values between calls. This can reduce token use while preserving MCP’s authentication, discovery, and self-documentation benefits; no savings figure was given.

The same application boundary clarifies how MCP works with skills, which supply domain knowledge and task-specific behavior: - Skills describe how to work: for example, how an accountant or data scientist should approach a task. - MCP supplies external connectivity: access to the operations and company data sources the task requires. - An execution environment runs bundled scripts: skills can contain code, but need somewhere to execute it. That runtime alone does not supply MCP’s authentication component.

Separating instructions from integrations also separates their maintenance. A Linear MCP server can improve without requiring changes to the skill using it. Hosting execution on the server lets web and mobile clients use an integration without providing their own script runtime.

A shared MCP client can pool connections and centralize discovery, potentially finding a server from a registry when a skill describes a need. Per-skill clients were also considered viable. Client architecture remained open to experimentation, rather than being dictated by the protocol.

Internal adoption starts with a deployment command

MCP’s reported origin was an organizational scaling problem: Anthropic’s development-tooling team expected to grow more slowly than the company it served. It needed other teams to build their own integrations. The resulting division of labor is concrete: the platform team maintains a gateway; other teams build servers. Internal uses include Slack summaries and asking Claude questions about employee survey results.

Anthropic’s deployment workflow launches a server into a Kubernetes cluster with a command. The broader enterprise recommendation is to let developers implement a stdio server, then have a gateway expose it over HTTP with streaming and integrated authentication. Centralize deployment and identity work so integration authors do not repeat it. FastMCP Cloud and LiteLLM illustrate related hosting and gateway approaches; Anthropic built its infrastructure internally for security reasons.

Discovery requires a trusted catalog

The official MCP registry grew out of a proliferation of separate catalogs. It provides a common publishing destination and interface, analogous to npm or PyPI. The desired workflow goes further than browsing packages: a model identifies a missing capability, selects a server, installs it, and uses it. That remained a goal at recording time.

Publication does not establish trust. Open registries inherit package ecosystems’ supply-chain problems. The proposed architecture separates publishing from approval: - Public registry: a common place to publish server entries. - Curated sub-registry: a filtered selection whose operator decides what to trust. - Enterprise registry: approved public entries plus internal servers, exposed through the same API so clients can use the company’s catalog. Autonomous selection and installation should operate against a curated, trusted registry. That curation ecosystem was still developing.

One tentative idea was to attach signatures from model providers that had scanned a server’s tool descriptions, letting consumers choose whose attestations to accept. Private registries offered a nearer-term place to experiment within an existing trust boundary. The internal infrastructure described in the conversation already registered servers when they launched.

Community meetings exposed another kind of trust requirement: clients may have obligations after receiving data. A financial-data license can require third-party attribution whenever the client displays the data. A Bloomberg-led financial-services interest group was being formed to work through such requirements. Other encounters showed the ecosystem’s breadth: Turkish Airlines had built a server for flight search.

Sampling depends on where the server runs

Sampling lets a server use the client’s configured model. A recent revision allowed tools scoped specifically to a sampling call, addressing a missing capability. Its usefulness nevertheless depends on deployment: - Remote servers can call a model SDK directly: operators control deployment, API keys, and potentially billing. - Locally distributed servers can benefit from sampling: their authors may not know which model or host application a user will configure. Sampling had seen limited uptake, and missing client support remained a barrier even where the local pattern was useful.

Tasks give long-running work an explicit lifecycle

Context retrieval still accounted for most MCP usage in the interview’s qualitative assessment. Deep research supplied a recurring reason to go further: an operation might take an hour or remain unfinished after a day. Ordinary tools act as a remote procedure call (RPC) interface, but stretching them into long-running work leaves the model managing follow-up retrieval. Tasks make that asynchronous work a protocol primitive.

A task is a container for asynchronous work, created by a tool call carrying specified metadata. This avoids duplicating tools with slightly different semantics. Its initial lifecycle is: 1. Create the task through the tool call. 2. Poll for completion at the client’s chosen interval. 3. Retrieve the completed result. Server-initiated completion notifications, potentially through webhooks, were planned as an optimization; polling would remain the core interface. Keeping an HTTP connection open for an operation lasting days was considered a poor fit.

The design’s litmus test was exposing a coding agent as an MCP server. Eventually, such an agent should return intermediate results and an account of the tools and inputs that produced its outcome. The initial task primitive did not yet provide that richer history; its structure left room for it. SDKs were intended to hide the abstraction behind an asynchronous call, but support had only just landed there and still needed to reach clients.

A participant recalled inventing a similar mechanism for Cognition’s Devin API, illustrating the recurring need around agent invocation. The guiding principle was to standardize work people already needed, while keeping MCP small enough to avoid prescribing speculative future workflows.

The application owns context retention and tool design

MCP obtains context; the application decides what to retain. Long-running work does not require keeping every tool result in model context forever. Some agents were already discarding results after a few rounds. Further possibilities included dropping intermediate task details when the final result arrived or asking a smaller model such as Haiku what to preserve. These were proposed strategies, not evaluated results; compaction was treated as an initial step, not a final answer.

Switching to a REST API does not remove these design responsibilities. REST does not prescribe authentication, and loading an OpenAPI specification into context can also cause bloat. Mapping API operations one-to-one into tools can create ambiguous choices: search-by-name, search-by-ID, and similar operations may look too alike for the model to select reliably. MCP still needs understandable tool interfaces.

For ordinary users, the ambition is simpler: ask for an outcome and have the application connect to the right services. MCP should become an invisible implementation detail. Developer uses remain valuable—the Playwright MCP server receives particular appreciation—but some local workflows are better served by a command-line interface.

MCP Apps: some choices need a visual interface

A list of available airplane seats does not show where they are. Theater bookings pose the same problem. MCP Apps brings richer interfaces into AI applications, allowing both a person and a model to interact with an application. Shopping adds another motivation: familiar interfaces and brand presentation matter. Work on a common standard with OpenAI aimed to make an app usable across implementing clients such as ChatGPT, Claude, and Goose; that interoperability was still an aspiration.

An MCP resource supplies HTML, the client renders it in an iframe, and the embedded app exchanges messages with its host through a specified interface. Supplying HTML directly permits advance security analysis, while the iframe is intended to bound communication. The initial direction favored HTML without external references, although the precise loading restrictions were still tentative.

Isolation leaves host styling unresolved. An embedded app should fit its surroundings, but an iframe does not simply inherit the host’s appearance. Inline styles, a tool supplying a stylesheet, and a standard for passing styles were discussed without an agreed solution. Rendering HTML was also optional: command-line agents could remain MCP clients without implementing the UI capability.

Possible industry extensions would require guarantees beyond authentication: - Financial-data attribution: a server might require signed evidence that a client respects attribution contracts before allowing a connection. - Sensitive-data containment: a healthcare server might require the client to disable other connected servers during a session, preventing data from being sent elsewhere. These remained proposals. The concrete failure to avoid was healthcare data or a Social Security number accidentally appearing in Linear: permission to read data does not establish permission to redistribute it.

Neutral ownership needs active maintainers

David’s immediate request is to build better servers and use them day to day. Contributions also include feedback, design discussions, and SDK implementation. He sees progressive discovery and code mode opening room for a new generation of clients. On the foundation move, his assurance is explicit: Anthropic’s commitment, his lead-maintainer role, and the people doing the work remain in place. Neutral ownership is intended to give adopters confidence that MCP will stay open.

The wider panel adds Jim Zemlin, introducing himself as Linux Foundation CEO; Nick Cooper, OpenAI’s AAIF representative and an MCP core contributor; and Brad, a Block principal engineer and original author of [Goose](https://github.com/block/goose). David recounts that MCP was seeking a neutral home when Block approached about donating Goose. They then approached OpenAI, and several months of discussion produced a directed fund within the Linux Foundation. Cooper describes MCP’s developer traction as a reason for OpenAI to adopt and contribute to it.

Brad’s account explains the client-side incentive. Goose originally had a dedicated plugin ecosystem, but its developers questioned why anyone would build integrations for just one client. Reusable servers give every client a broader library of capabilities. Goose also provides a place to test what protocol extensions enable. Its team had opened an issue to explore MCP Apps integration that day; dashboards and enhanced chat were prospective uses, not completed functionality.

Protocol proposals need working clients and servers. A recurring committee test is whether the proposer has tried an idea and shown that it works. Reference implementations provide that feedback while leaving room for competing agents. Common conventions reduce needless incompatibility; diverse implementations can explore different product designs.

What the foundation funds—and who decides

AAIF did not have a lineup of future projects ready for admission. Its emerging selection principles emphasized composability, established use, and active maintenance. Components should work together into agents suited to different purposes. Choosing a winner too early could restrict innovation, while accepting every proposal would dilute the foundation. Experienced developers should curate projects on technical grounds, rather than vendors bargaining for roadmap positions.

The incentive for donation is shared engineering: organizations invest developers in a neutral project, improve it, build products, and return feedback and further contributions. That is an expected reinforcing cycle, not a measured outcome. Technical participation does not require foundation membership. A separate agent foundation provides focus for a community concerned with agent systems and how they connect, alongside distinct communities building models, serving inference, and deploying infrastructure.

Foundation funding supports several operational responsibilities: - Intellectual-property stewardship: managing assets, license compliance, and disputes. - Community organization: helping build consensus, attract contributors, and support developer outreach. - Convening: meetings and events where maintainers exchange ideas and make decisions. - Maintainer tooling: visibility into development activity, adoption indicators, and application-security practices.

Spending decisions are separated from technical governance. The stated purpose is to prevent financial support from buying control over the technology: funders support the market and community, while developers direct technical work. The discussion identifies spending categories without giving budget amounts or allocation percentages.

Commercial pressure still tests that boundary. One participant questions how open-source maintainers should respond to demands for influence; another recalls that Kubernetes also developed amid competing business interests. In that account, Google’s contribution supported its cloud ambitions, and later Microsoft and Amazon investment helped build consensus around a contested infrastructure choice. The lesson offered is that commercial incentives and useful shared infrastructure can coexist when developers retain authority over technical decisions.

The next test: agents whose results come together

The closing technical ambition is concrete: roughly twenty agents working asynchronously, with their results brought together so the user does not have to read every chat session. Concurrent work needs a useful result handoff. MCP was beginning to approach that problem, but reference implementations still needed to demonstrate the value. Frustration with constant approval prompts highlighted another unresolved part of that experience; the exchange supplied no authorization design.

The organizational test is sustained activity after the launch: further technical contributions, gatherings that turn interest into collaboration, and competitors learning to build shared infrastructure together. The desired evidence of success is practical—organizations using agents to improve their businesses, profitable MCP startups, and adopters returning useful feedback. Those were the panel’s hopes for the next year, with working systems and their users still to supply the results.