MCP six months in — what the Model Context Protocol actually delivers in 2026

The Model Context Protocol (MCP) was open-sourced by Anthropic in November 2024. The pitch was clean: a standard way for AI tools to discover and interact with external systems — databases, APIs, file systems, anything that can be modelled as a tool. One protocol, many servers, any client.

Eighteen months later, MCP is real. It is not hype. It is also not a solved problem. We have built four MCP servers for internal and client use, integrated MCP clients into our agent workflows, and watched the ecosystem mature. This is the honest assessment.

What MCP gets right

The tool-centric model is correct. MCP models everything as a tool: a named function with a JSON Schema input, a JSON output, and optional resource and prompt abstractions for read-heavy interactions. This is not a novel abstraction — it is the same model that OpenAI's function calling and Anthropic's tool use already used. MCP's contribution is making it protocol-standard rather than provider-specific.

The benefit is real. Write a server once. Any MCP-compatible client — Claude Code, Cursor, Zed, Continue, the Hermes agent, our own internal tools — can discover and use it. No per-client integration work. No provider lock-in.

The transport layer is pragmatic. MCP supports two transports: stdio (subprocess with JSON-RPC over stdin/stdout) and HTTP with SSE (for remote servers). Stdio is the right default for local tools — zero network configuration, zero auth, just spawn the process. HTTP+SSE is the right default for remote tools — a standard web protocol with well-understood security properties.

The stdio transport in particular makes MCP trivially deployable:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-postgres", "--dsn", "postgresql://..."]
    }
  }
}

Four lines of JSON and the AI tool can query your database. This is the right level of simplicity for the default case.

The ecosystem grew faster than expected. As of May 2026, the MCP ecosystem includes:

• Official Anthropic servers for Postgres, SQLite, Brave Search, GitHub, Google Maps, Puppeteer, and Filesystem
• A substantial community server ecosystem (mcp.so lists over 1,200 servers)
• Client integrations in Claude Code, Cursor, Zed, Continue, Sourcegraph Cody, Hermes, and most AI-assisted coding tools
• Server SDKs in TypeScript, Python, and Kotlin (official), plus community SDKs in Go, Rust, and Elixir
• MCP Registry (launched March 2026) — a discoverability layer with verified publishers, version pinning, and security scanning

The 2024 concern that MCP would be an Anthropic-only protocol with no ecosystem was disproven within the first six months.

What MCP still struggles with

Stateful interactions. MCP's tool model is request-response. Tool A is called, returns a result, and the client sends that result as context to tool B. But many real-world interactions don't fit this pattern. A database migration tool wants to start a transaction, run several DDL statements, and commit or rollback. A browser tool wants to navigate, observe, click, and observe again. MCP's request-response model forces the client to maintain the session state, which bloats the context window and adds latency.

The workaround is to build session-aware tools — a tool that accepts a session_id parameter and manages state server-side. But this is a pattern, not a protocol feature. The protocol itself is stateless and that limits the class of interactions that are natural to express.

Tool discovery at scale. When a client connects to ten MCP servers, each exposing 20 tools, the AI gets a prompt listing 200 tools with their schemas. The model can handle it — Claude Sonnet 4.6 can reason about 200 tools without significant degradation — but the prompt is large and the cost-per-turn adds up. More importantly, the flat tool list gives the model no structure: "these 50 tools are for the database, these 30 are for the browser, these 20 are for file operations." The model has to infer intent from tool names.

MCP 1.3 (February 2026) introduced tool grouping via the group metadata field, which helps clients organise the tool list. It is a start, not a solution.

Authentication in HTTP transport. Stdio MCP servers inherit the user's ambient credentials — the Postgres server connects with the user's local socket or connection string. Remote MCP servers (HTTP+SSE) need explicit authentication, and MCP's auth story is still evolving. OAuth 2.0 with device flow was added in MCP 1.2 (November 2025). API key auth is supported via custom headers. But there is no standard for fine-grained tool-level permissions ("this API key can use the read_file tool but not the write_file tool"). Server implementors build their own.

Security model for tool execution. MCP does not define what a tool is allowed to do. The Postgres server can run DROP TABLE. The Filesystem server can rm -rf. The onus is on the server implementor to scope the tool's capabilities, and on the client to present the right warnings. A malicious or buggy tool server can do real damage, and the protocol provides no security boundary — it provides a communication boundary.

What we built on MCP

The studio has built four MCP servers:

1. Tally MCP server. Wraps Tally's XML-based API (TDL), exposing tools for invoice creation, ledger query, stock status, and GST filing. Used by our internal agents for client ERP automation.

2. Odoo MCP server. Wraps Odoo 18 JSON-RPC, exposing read/write/search tools across all Odoo models with ACL-aware scoping. The agent can query manufacturing orders, create deliveries, and fetch inventory levels.

3. n8n MCP server. Exposes n8n workflow management — list workflows, trigger execution, check execution status. Used for agent-initiated workflow runs.

4. Hermes Agent MCP server. Exposes Hermes' own tool surface (file read/write, terminal, search) via MCP so other AI clients can use Hermes as a remote tool runtime. Dogfood.

The consistent lesson: building an MCP server is easy if the underlying API is clean. The Tally server took three weeks — two weeks on the XML wrapper, one week on the MCP layer. The Odoo server took four days. The MCP protocol itself is not the bottleneck; the quality of the wrapped API is.

Where MCP fits in the agent architecture

In our agent orchestration, MCP is the tool layer, not the agent layer. The agent framework (LangGraph, Hermes, or a custom loop) handles planning, memory, and multi-step reasoning. MCP provides the tools that the agent calls.

This separation is not accidental. MCP is a tool protocol, not an agent protocol. Agent-to-agent communication — delegation, task handoff, shared memory — is outside MCP's scope. A2A (Google's Agent-to-Agent protocol, May 2026) is the emerging standard for agent-to-agent communication, and we covered it in a previous post. MCP runs underneath, providing the individual capabilities. A2A runs above, coordinating the agents.

The ecosystem is settling into a sensible layering: LLM call → agent framework (planning, memory) → MCP (tool access) → external system. Each layer has a defined scope and a defined interface. This is healthier than the 2024 pattern where every agent framework implemented its own tool calling protocol.

What to watch

Three things we are tracking:

• MCP 2.0 drafts (expected late 2026). Stateful sessions, streaming responses, and bidirectional communication are all being discussed. Any one of these would expand the class of interactions that MCP handles natively.

• OpenAI's MCP adoption. OpenAI has not formally adopted MCP. They have their own function-calling protocol, and the GPT tool ecosystem uses it. If OpenAI adopts MCP, the protocol becomes effectively universal. If they don't, the ecosystem bifurcates — Anthropic/GitHub/Cursor on MCP, OpenAI on their own protocol — and bridge servers become a cottage industry.

• Enterprise MCP gateways. As MCP adoption grows in enterprise settings, a new category of middleware is emerging: MCP gateways that sit between clients and servers, handling auth, rate limiting, audit logging, and tool-level access control. This is where the security gaps get addressed at the infrastructure layer.

The honest summary

MCP delivers on its core promise: a standard way for AI tools to discover and use external systems. It is not a silver bullet. It does not solve agent-to-agent communication, stateful interactions, or the security model for tool execution. But it solves the problem it set out to solve — tool protocol standardisation — and it has done so well enough that every AI-assisted coding tool now speaks it.

For a studio building vertical SaaS with AI features, MCP is infrastructure, not product. We build MCP servers to provide tools to our agents. The protocol is not the interesting part. The tools are. MCP makes the tools portable, and portability is worth the protocol overhead.

MCP solved the right problem at the right time. The gaps are real but well-understood. The ecosystem is growing in the right direction. That's more than can be said for most 2024-vintage AI infrastructure bets.