The Model Context Protocol[1], proposed by Anthropic in November 2024, has completed the full cycle: experiment → multi-adoption → de facto standard. I already covered that first year of progress in Model Context Protocol in 2025: from announcement to ecosystem.

In December 2025 Anthropic handed MCP’s governance to the Agentic AI Foundation, a directed fund under the Linux Foundation. Anthropic co-founded it with OpenAI and Block, and Google, Microsoft, AWS, Cloudflare, and Bloomberg back it. By then MCP had over 10,000 active servers and first-class support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code. In 2026, with that multi-vendor backing formalized, operational patterns are mature.

Key takeaways

  • The proven pattern combines community generic MCP servers with custom servers for domain logic.

  • Explicit policies at the agent layer define which operations require human confirmation.

  • Credentials never travel to the model: the server holds them locally and executes on its behalf.

  • Composition with per-server prefixes (fs:read_file, db:query) avoids name collisions.

  • MCP servers without contract tests break silently on every upgrade.

Clear separation: generic vs domain-specific tools

The usual 2026 pattern combines:

  • Community MCP servers for generic capabilities: file system, bash, web fetch, search. They install via npx, uvx, or MCP marketplaces.

  • Custom servers for domain logic. Built with the official SDK and versioned alongside the product.

OpenAI’s own Agents SDK documents this same pattern[2]: reuse existing MCP servers for the generic parts and build your own for custom connectors. That is proof the pattern is not an Anthropic preference but a convention shared across vendors.

Don’t mix. Locally modifying the generic MCP server is a bug waiting to happen: the next update overwrites changes. Custom capabilities go in your own server.

Explicit per-server policies

Each MCP server declares which tools it exposes and with what parameters. The part managed at the agent layer is policy. Typical example with the filesystem server:

  • read_file: allowed freely.

  • write_file: requires confirmation outside a specific directory.

  • delete_file: never executes without explicit validation.

Predefining the permitted operations is more reliable than letting the model decide which operations to execute without restrictions.

Authentication and credentials outside the model

Credentials don’t travel to the model:

  • The MCP server holds them locally.

  • The model requests operations by name and parameters.

  • The server executes with its credentials.

This dramatically reduces the prompt injection attack vector seeking to exfiltrate tokens, though it does not eliminate it entirely. I covered the defenses that actually work against that vector in prompt injection defense: what actually works. The pattern:

  • Environment variables at server startup.

  • Never in the agent’s prompt.

  • Credential rotation without agent redeploy.

Server composition

A mature agent speaks with more than one MCP server at once. Tools are presented to the model with per-server prefixes:

  • fs:read_file

  • db:query

  • web:fetch

This avoids name collisions. The orchestrator decides which server each operation goes to; the model doesn’t choose explicitly. VS Code adopted exactly this composition scheme when its MCP support reached general availability in July 2025[3], with Copilot mediating between more than one server at once.

Antipatterns avoided after a year’s experience

Three errors, now less common but still appearing:

  • Exposing dangerous tools without policy: delete, rm -rf, unfiltered db query.

  • Custom MCP servers without tests: breaking contract on upgrade drops the agent without clear warning.

  • Shared memory between MCP servers that should be isolated: enables cross-injection.

Conclusion

MCP in 2026 is a proven standard. Deployment patterns are well understood: community generics + domain-specific custom, explicit policies, credentials outside the model, prefixed composition, contract tests. Teams following this blueprint have stable agents; those improvising fight silent breakages.

This article is also available in Spanish: MCP como estándar multi-vendor: patrones ya maduros.

Frequently asked questions

Can I modify a community MCP server to add my domain logic?

Better not: locally modifying the generic MCP server is a bug waiting to happen, because the next update overwrites your changes. The proven pattern combines community servers for generic capabilities (file system, bash, web fetch, search), installed via npx, uvx, or MCP marketplaces. It adds custom servers for domain logic, built with the official SDK and versioned alongside the product. OpenAI's Agents SDK documents that same split.

How do I keep credentials from reaching the model through MCP?

The MCP server holds the credentials locally, the model requests operations by name and parameters, and the server executes them with its own credentials. In practice they go in environment variables at server startup, never in the agent's prompt, and are rotated without redeploying the agent. This dramatically reduces the prompt injection vector seeking to exfiltrate tokens, though it does not eliminate it entirely.

What happens when an agent uses more than one MCP server with tools of the same name?

Tools are presented to the model with per-server prefixes, such as fs:read_file, db:query, or web:fetch, which avoids name collisions. The orchestrator decides which server each operation goes to; the model does not choose explicitly. VS Code adopted exactly this composition scheme when its MCP support reached general availability in July 2025, with Copilot mediating between more than one server at once. Memory between servers should stay isolated to prevent cross-injection.

Sources

  1. Model Context Protocol
  2. OpenAI’s own Agents SDK documents this same pattern
  3. its MCP support reached general availability in July 2025