MCP Protocol Development and Agent AI Foundation Launch

anthropic_/openai/_goose · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Agent protocol design and governance

MCP needed to evolve from a local tool-connectivity protocol into production-grade agent infrastructure for remote servers, enterprise authentication, scalable transports, long-running operations, registries, and neutral industry governance.

Constraints:

Architecture

MCP evolved through spec releases: local standard-IO servers first, remote streamable HTTP and authentication next, enterprise OAuth/resource-server separation, and long-running task primitives. The ecosystem added progressive discovery, programmatic/code-mode use, registries and subregistries, internal gateways, and neutral governance through the Agent AI Foundation under the Linux Foundation with Anthropic, OpenAI, Block, and other industry participants.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  App["AI application"] --> Client["MCP client"]
  App --> Sandbox["Execution sandbox"]
  Sandbox --> Client
  Client --> Local["Local MCP server"]
  Client --> Remote["Remote MCP server"]
  Remote --> Auth["Authentication server"]
  Remote --> Task["Task primitive"]
  Client --> Registry["Registry"]
  Registry --> Subregistry["Subregistry"]
  Registry --> Gateway["Internal gateway"]
  Gateway --> Remote
  Foundation["Agent AI Foundation"] --> Registry
  Foundation --> Client
  Foundation --> Remote
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
AI application Host application that exposes MCP-connected tools and context to a model or agent. MCP client, Execution sandbox
MCP client Client-side protocol implementation that connects the AI application to local or remote MCP servers. AI application, Local MCP server, Remote MCP server, Registry
Local MCP server Standard-IO MCP server used for local integrations and desktop/CLI workflows. MCP client
Remote MCP server HTTP-streaming server that exposes tools, resources, and context over a networked transport. MCP client, Authentication server, Task primitive
Authentication server Enterprise identity provider or OAuth server that issues tokens separately from MCP resource serving. Remote MCP server
Registry Official, curated, or internal catalog that lets clients or models discover MCP servers through a common interface. MCP client, Subregistry, Internal gateway
Subregistry Curated registry layer that filters or augments the official registry for trust, enterprise approval, or authentication. Registry
Internal gateway Enterprise MCP gateway that handles deployment, IDP integration, authentication, and server launch for internal teams. MCP client, Registry, Remote MCP server
Task primitive Long-running operation container that supports asynchronous agent work beyond a single synchronous tool call. Remote MCP server, MCP client
Execution sandbox Optional programmatic MCP/code-mode environment where models compose multiple MCP calls in generated code. AI application, MCP client
Agent AI Foundation Neutral governance home for MCP and related agentic projects under the Linux Foundation. Registry, MCP client, Remote MCP server

Data flow

An AI application uses MCP clients to connect models to servers that expose tools, resources, context, and optional richer interfaces. Local deployments use standard IO; remote deployments use streamable HTTP with OAuth-based authentication. Registries help clients discover servers, enterprises can route MCP through gateways and private registries, and long-running tasks let clients create asynchronous operations, poll for completion, and eventually receive completion notifications instead of holding connections open.

3 supporting quotes
“we launched originally as like basically local only. Um you could like build local MCP servers for cloud desktop.”transcript, stated
“in March this year we moved into like how can you do remote MCP server so connect like really about like to a remote server and introduced like the first iteration of authentication”transcript, stated
“it's it's it's designed like a classic um operating system interface like you create a task, you pull it

until it's done”transcript, stated

Why this architecture

MCP keeps the protocol between AI applications and servers while leaving models free to consume tools directly, discover them progressively, or call them through generated code. The OAuth/resource-server split fits enterprise identity systems; streamable HTTP balances simple HTTP infrastructure with agent statefulness; registries create discoverability; and foundation governance reassures companies that the protocol remains neutral and open.

3 supporting quotes
“MCP is a is a protocol between the I application and like servers right? So the model is actually technically not involved in MCP.”transcript, stated
“the MCP server is a resource server, how you get the token from the authentication server. We have opinions on how you should do it, but it's kind of separated.”transcript, stated
“this is now owned by a neutral entity. It will always stay open. You can use the the the word MCP. nobody's going to sue you over it.”transcript, stated

Models used: tool-calling models · models trained for progressive discovery · agentic coding/research agents

Scale

That's a lot." — transcript, stated

Alternatives considered (roads not taken)

Keep MCP local-only

Rejected because: Remote MCP servers and authentication became necessary for production and enterprise use.

“we already knew actually in December and November that the next big thing will be like how can you do this over the over remote and authentication is quite important.”transcript, stated

Combine OAuth authentication server and resource server inside the MCP server

Rejected because: That design did not work for enterprises with central identity providers, so June separated the concerns.

“in the first iteration of our authentication spec, we combined them together into the MCP server”transcript, stated
“The reality in enterprises is you don't authentic, you authenticize with some central entity like you know you know you have some ID identity provider”transcript, stated

Use only a simple stateless REST-style transport

Rejected because: Agents need long-term, sometimes bidirectional communication with servers, but the transport also has to stay simple for basic servers.

“MCP should also enable agents and agents are inherently somewhat stateful and there's some form of like long-term communication going between like the client and the server.”transcript, stated
“what is the right middle ground between having something that can be used in the simplest form”transcript, stated

Represent long-running agent work as ordinary synchronous tool calls

Rejected because: Developers were awkwardly implementing polling inside tool calls, so tasks became a first-class primitive.

“people have like awkwardly tried to do this with our tools and you can because tools are effectively just an RPC interface”transcript, stated
“it gets very quickly awkward because now the model needs to understand, oh, I need to pull this”transcript, stated

Let MCP remain solely under Anthropic control

Rejected because: Neutral governance gives the industry confidence that MCP stays open and safe to adopt.

“we always knew that we wanted to find a neutral home for MCP to make sure that the uh that the industry understands that this is uh stays open”transcript, stated

Patterns

tool-use-orchestration (tooling)

MCP standardizes how AI applications connect models and agents to external tools, resources, and servers.

“MCP gives you the connectiveness of the actual actions that you can take with the outside world”transcript, stated

context-engineering (context_management)

Progressive discovery prevents context bloat by giving models high-level tool information and letting them request details only when needed.

“you that you can do something like progressive discovery and that's like a general principle thing of like you can give the model some information”transcript, stated
“if you naively take all the tools and throw them into the context window, you you just get a lot of bloat.”transcript, stated

safety-policy-enforcement (control)

MCP prescribes OAuth-style authentication and evolved to separate token issuance from MCP resource serving for enterprise IDP compatibility.

“MCP is very um very prescriptive in like each layer like other protocols are not like that for example like we like you want to do authentication”transcript, stated
“the MCP server is a resource server, how you get the token from the authentication server.”transcript, stated

durable-execution (runtime)

The tasks primitive supports long-running asynchronous agent work with creation, polling, and future completion notification patterns.

“people want to have a long running agents and that's like something we heard from so many areas”transcript, stated
“you create a task, you pull it

until it's done”transcript, stated

code-execution-sandbox (runtime)

Programmatic MCP/code mode lets a model compose multiple API-style calls in sandboxed code to reduce token and latency overhead.

“the model generates you know code and what you effectively doing is this composability that the the model would have done anyway”transcript, stated
“put them into a bunch of code that is just executed in a sandbox”transcript, stated

Tradeoffs

Choose streamable HTTP as remote transport

Chose Standard HTTP with streaming properties over Pure REST or full WebSocket/gRPC-style streaming only.

Rationale: The protocol needed a middle ground that works for simple servers but can upgrade toward bidirectional agent communication.

“what is the right middle ground between having something that can be used in the simplest form”transcript, stated
“then is able to be upgraded to like a full birectional stream if you need it because you really have like complex agents”transcript, stated

Use tasks rather than async tool calls alone

Chose A generic task container for long-running operations over Only adding asynchronous semantics to tools.

Rationale: Tasks can eventually expose intermediate results, tool chains, and metadata for long-running agent work.

“a pure asynchronous tool call would just not do this you want some form of operation that can return for example intermediate results in the long term.”transcript, stated
“the task itself is just the concept of like a container that can something”transcript, stated

Pair public and private registry models

Chose Official registry plus curated subregistries and enterprise internal registries over A single uncurated registry as the only discovery mechanism.

Rationale: Public discovery encourages ecosystem growth, while enterprise and curated registries preserve trust and approval boundaries.

“you as an as a company uh can have an internal registry that is secured form of the the the official one plus maybe you own ones.”transcript, stated
“with a public registry you should probably not do this because it's a dump it's a dumping ground for everybody.”transcript, stated

Move MCP to neutral foundation governance

Chose Agent AI Foundation under the Linux Foundation over Keeping MCP governed only by Anthropic.

Rationale: Neutral governance makes major competitors and enterprises more comfortable adopting and contributing to agent protocols.

“we wanted to find a neutral home for MCP to make sure that the uh that the industry understands that this is uh stays open”transcript, stated
“that's where the Linux foundation comes in as is um I think the biggest uh foundation of its kind”transcript, stated

Gotchas (what bit them)

Enterprise OAuth assumptions broke the first remote-authentication design.

Root cause: The first spec combined authentication and resource-server roles inside MCP, but enterprises authenticate through central IDPs.

Resolution: The June spec split MCP into a resource-server role and separate token acquisition through authentication servers.

“in the first iteration of our authentication spec, we combined them together into the MCP server”transcript, stated
“that's what happened then in the June spec where we separated this out”transcript, stated

Optional bidirectional transport features tend not to be implemented.

Root cause: Clients implement the minimum viable product when return streams are optional.

Resolution: The maintainers are revisiting transport design with major vendors to preserve streaming capabilities while improving scalability.

“we made a lot of things optional for the clients to do. Um like you can the client can connect and open this return stream from the server but it doesn't have to.”transcript, stated
“And the reality is is no client does it because it's optional.”transcript, stated

Stateful transports are awkward to scale horizontally.

Root cause: Related calls may hit different pods, requiring shared state such as Redis or memcache.

Resolution: The team is designing an iteration that keeps simple servers simple while allowing bidirectional streaming and scalability.

“the moment you scale this horizontally across multiple pods and a like in containers or something like that.”transcript, stated
“you effectively need some form of shared like reddis memcache whatever you want”transcript, stated

Public MCP registries inherit package-registry trust problems.

Root cause: Anyone can publish to the official registry, so supply-chain attacks and trust ambiguity remain fundamental risks.

Resolution: The ecosystem is adding subregistries and internal registries that curate or filter the official registry through a common API.

“the official registry where everybody can put their MCP server but this is the equivalent to an MPM which has the exact same problems”transcript, stated
“that's why we have this concept of subregistries which then like the Smitheries and others hopefully can do where they can filter and curate”transcript, stated

Evaluation

MCP changes are validated through production dogfooding, community adoption, major-company feedback, GitHub issues, collaborator implementations, and maintainers asking whether proposals have been tried in real clients and servers.

Metrics: four spec releases in one year · millions of requests at Google/Microsoft-scale deployments · internal Anthropic MCP gateway usage · major adoption by Microsoft, Google, and OpenAI · requirements from GitHub issues and large-company users · foundation acceptance criteria around adoption and maintenance

3 supporting quotes
“we had this like crazy adoption over the last year now”transcript, stated
“the Googles of the world the Microsoft of the world they're doing MCP at a scale that I can't tell you the numbers but it's like in the million of requests”transcript, stated
“it needs to be like really well maintained.”transcript, stated

Outcomes

The transcript describes one year of MCP growth, four spec releases, adoption by Microsoft, Google, and OpenAI, millions of production requests at large companies, Anthropic internal gateway deployments, and the Agent AI Foundation launch under the Linux Foundation.

3 supporting quotes
“we have really solid foundations. We have like one more big primitive we want to have.”transcript, stated
“this will stay forever open that this cannot be taken away.”transcript, stated
“MCP gained such very large developer traction and we at OpenAI were very excited to like use and then contribute and actively participate”transcript, stated