Model Context Protocol in 2025: from announcement to ecosystem

Actualizado: 2026-05-03

Ten months ago, when Anthropic announced Model Context Protocol on November 25, 2024, many of us received it with the usual skepticism toward a standard proposed by a single vendor. In September 2025, with hundreds of servers published, an active official registry, and support built into clients outside Anthropic, it is time to look at MCP with fresh eyes and separate what has worked from what is still a promise.

Key takeaways

• MCP has moved from announcement to infrastructure: Cursor, VS Code, Zed, Claude Desktop, OpenAI Agents SDK, Gemini CLI, and Microsoft’s VS Code Copilot now implement it natively.
• Cross-vendor adoption — OpenAI, Google, Microsoft — is what distinguishes a real standard from an attempted one.
• MCP is a session protocol (state, resources, notifications, permissions), not just a stateless function calling interface — this structural difference is what enabled the ecosystem.
• The four categories with the biggest impact: code system integrations (GitHub, Gitea, GitLab), filesystem and local execution, databases and search, and user SaaS services (Slack, Notion, Linear).
• Three points still weak in 2025: security (incomplete permissions model), uneven documentation, and performance on long sessions (memory leaks in auxiliary processes).

From announcement to real infrastructure

The first relevant data point is that MCP has moved from announcement to infrastructure. Among the three main client categories that have added support:

• Code editors: Cursor, VS Code with its official extension, and Zed.
• Assistant applications: Claude Desktop and Claude Code.
• Agent platforms: Cline, Continue.

Each has implemented MCP not as an add-on but as the primary mechanism for connecting to external tools.

The most interesting point is that adoption has crossed vendor lines. OpenAI, historically reluctant toward standards it does not control, announced MCP support in the Agents SDK in March 2025. Google integrated MCP into Gemini CLI and other components over the summer. Microsoft has native support in VS Code Copilot and in Azure AI Foundry. This cross-vendor adoption is what distinguishes a real standard from an attempted one.

The other milestone was the opening of the public MCP server registry. In September 2025 there are several hundred listed servers, from integrations with GitHub, Gitea, and Jira to bridges for databases, filesystems, payment APIs, and browser assistants.

What MCP solves that function calling did not

At this point there is enough perspective to understand why MCP took off where traditional function calling had not generated a similar ecosystem.

Function calling is an interface: you hand the model a list of functions with their schemas and the model picks which to call. That works well when functions are few and stable.

MCP is a session protocol, not just an interface. An MCP server is not a stateless endpoint returning JSON: it is a process that keeps a connection with the client, can expose tools, resources, and prompts, and can emit notifications and manage permissions explicitly. That structural difference enables things function calling did with difficulty:

• Servers that discover capabilities dynamically
• Tools that consume user-system resources with explicit permission
• Flows with delegated authentication

The other key element is the separation between client and server. With function calling, the model provider defines the interface and users adapt their tools. With MCP, users can install servers independent from the model provider. That independence is what has enabled a developer on Claude Desktop to install an MCP server built for Cursor and have it work.

Servers that have set trends

Reviewing the registry and what I see the community actually using, there are four categories where MCP has had the biggest impact:

Code-system integrations: servers for GitHub, Gitea, and GitLab let an agent create pull requests, review code, approve changes, and navigate issues, all within an editor session. In my own day-to-day, the Gitea MCP server I keep connected lets me close issues from an agent without leaving context.

Filesystem and local execution: there are servers for filesystem, shell, Docker, and Kubernetes that give agents controlled access to user resources with explicit permissions. The pattern of accepting command executions one at a time from the client, with the option to approve in batch or by pattern, has proven to be a reasonable security interface, if imperfect.

Databases and search: servers for PostgreSQL, SQLite, Elasticsearch, and several vector stores let an agent query user-specific data without being trained on it. This is key for lightweight RAG cases where spinning up dedicated infrastructure is not worth it.

User SaaS service integrations: servers for Slack, Notion, Linear, Jira, or Calendar let you delegate management tasks to an agent directly from the editor or assistant application.

What is still weak

Not everything has matured at the same pace. Three areas where MCP still carries weaknesses:

Security: MCP’s permissions model is better than improvised function calling, but it remains the client’s responsibility to implement it well. There have already been several public incidents of MCP servers running code with more privileges than the user understood.

Documentation and capability discoverability: many public servers are small projects with summary docs, making it hard to know exactly what they do without reading the code.

Performance on long sessions: MCP keeps state between calls, which is useful but also opens the door to memory leaks or uncontrolled context growth during multi-hour sessions. On marathon debugging sessions with multiple active servers, I have seen crashes from resource exhaustion that had nothing to do with the model but with auxiliary processes.

When not to use it

Having said all the good, MCP is not the answer for everything:

• If your use case is synthetic and isolated, like a single-step agent hitting a public API, plain function calling is still lighter and easier to maintain.
• If your environment is embedded or low-latency, the overhead of a session protocol may not be worth it.
• If your team values vendor independence as top priority, verify that the MCP client implementation you pick does not introduce indirect dependencies.

My read

Model Context Protocol has passed the curiosity phase and is in full consolidation. For anyone building agents or integrating LLMs with external tools, it is more sensible today to lean on MCP than to invent your own integration layer. The entry cost is low, the community is with you, and the ecosystem rewards early movers.

The more interesting read is that MCP has changed how we think about integrating models with the world. A year ago we talked about function calling as the frontier. Today we talk about ecosystems of servers interchangeable across vendors. That is an architectural leap, not an incremental improvement, and it deserves to be recognized as such.

My reasoned prediction is that the next twelve months will see capability consolidation more than radical design changes. A v2 of the spec, if it comes, will probably be refinement of security, discoverability, and performance, not a rethink. MCP is already part of the landscape.