El Model Context Protocol[1], propuesto por Anthropic en noviembre de 2024, ha atravesado el ciclo completo: experimento → adopción múltiple → estándar de facto. Ya documenté ese primer año de recorrido en Model Context Protocol en 2025: del anuncio al ecosistema.

En diciembre de 2025 Anthropic cedió la gobernanza de MCP a la Agentic AI Foundation, un fondo dirigido bajo la Linux Foundation. Anthropic lo cofundó junto con OpenAI y Block, y lo respaldan Google, Microsoft, AWS, Cloudflare y Bloomberg. Para entonces MCP acumulaba más de 10.000 servidores activos y soporte de primera clase en ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot y VS Code. En 2026, con ese respaldo multi-vendor formalizado, los patrones operativos están maduros.

Puntos clave

  • El patrón probado combina servidores MCP comunitarios genéricos con servidores propios para lógica de dominio.

  • Las políticas explícitas en la capa del agente definen qué operaciones requieren confirmación humana.

  • Las credenciales nunca viajan al modelo: el servidor las tiene localmente y ejecuta en su nombre.

  • La composición con prefijos por servidor (fs:read_file, db:query) evita colisión de nombres.

  • Servidores MCP sin tests de contrato rompen silenciosamente en cada upgrade.

Separación clara: herramientas genéricas vs específicas

El patrón habitual en 2026 es combinar:

  • Servidores MCP comunitarios para capacidades genéricas: sistema de ficheros, bash, web fetch, búsqueda. Se instalan desde npx, uvx o marketplaces de MCP.

  • Servidores propios para la lógica de dominio. Se desarrollan con el SDK oficial y se versionan junto al producto.

El propio SDK de Agents de OpenAI documenta este mismo patrón[2]: reutilizar servidores MCP existentes para lo genérico y construir los propios para conectores a medida. Es la prueba de que el patrón no es una preferencia de Anthropic sino una convención cruzada entre proveedores.

No mezclar. Modificar el servidor MCP genérico localmente es un bug esperando a pasar: el próximo update sobrescribe los cambios. Capacidades custom van en servidor propio.

Políticas explícitas por servidor

Cada servidor MCP declara qué herramientas expone y con qué parámetros. La parte que se gestiona en la capa del agente es la política. Ejemplo típico con el servidor de ficheros:

  • read_file: permitido libremente.

  • write_file: requiere confirmación si está fuera de un directorio específico.

  • delete_file: nunca ejecuta sin validación explícita.

Predefinir las operaciones permitidas es más fiable que dejar al modelo decidir qué operaciones ejecutar sin restricciones.

Autenticación y credenciales fuera del modelo

Las credenciales no viajan al modelo:

  • El servidor MCP las tiene localmente.

  • El modelo pide operaciones por nombre y parámetros.

  • El servidor ejecuta con sus credenciales.

Esto reduce drásticamente el vector de prompt injection buscando exfiltrar tokens, aunque no lo elimina del todo: cubrí las defensas que de verdad funcionan contra ese vector en defensa frente a prompt injection. El patrón es:

  • Variables de entorno al arrancar el servidor.

  • Jamás en el prompt del agente.

  • Rotación de credenciales sin redeployar el agente.

Composición de servidores

Un agente maduro habla con más de un servidor MCP a la vez. Las herramientas se presentan al modelo con prefijos por servidor:

  • fs:read_file

  • db:query

  • web:fetch

Esto evita colisión de nombres. El orquestador decide a qué servidor va cada operación; el modelo no lo elige explícitamente. VS Code adoptó exactamente este esquema de composición cuando su soporte de MCP llegó a disponibilidad general en julio de 2025[3], con Copilot mediando entre más de un servidor a la vez.

Antipatrones evitados tras un año de experiencia

Tres errores que se ven con menos frecuencia pero siguen apareciendo:

  • Exponer herramientas peligrosas sin política: delete, rm -rf, db query sin filtro.

  • Servidores MCP custom sin tests: romper contrato en un upgrade tumba el agente sin aviso claro.

  • Memoria compartida entre servidores MCP que debería ser aislada: permite inyecciones cruzadas.

Conclusión

MCP en 2026 es estándar probado. Los patrones de despliegue están bien entendidos: genéricos comunitarios + propios de dominio, políticas explícitas, credenciales fuera del modelo, composición con prefijos, tests de contrato. Equipos que siguen esta pauta tienen agentes estables; los que improvisan lidian con rupturas silenciosas.

Lee también la versión en inglés: MCP as multi-vendor standard: patterns already mature.

Fuentes:

  1. Anthropic: Introducing the Model Context Protocol[4]
  2. Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation[5]
  3. OpenAI Agents SDK: soporte de Model Context Protocol[2]
  4. GitHub Changelog: soporte de MCP en VS Code, disponibilidad general[3]
  5. Linux Foundation: formación de la Agentic AI Foundation[6]

Preguntas frecuentes

¿Puedo modificar un servidor MCP comunitario para añadirle mi lógica de dominio?

No conviene: modificar localmente el servidor MCP genérico es un bug esperando a pasar, porque el próximo update sobrescribe los cambios. El patrón probado es combinar servidores comunitarios para capacidades genéricas (sistema de ficheros, bash, web fetch, búsqueda), instalados desde npx, uvx o marketplaces. A eso se suman servidores propios para la lógica de dominio, desarrollados con el SDK oficial y versionados junto al producto. El SDK de Agents de OpenAI documenta ese mismo reparto.

¿Cómo evito que las credenciales lleguen al modelo a través de MCP?

El servidor MCP guarda las credenciales localmente, el modelo pide operaciones por nombre y parámetros y el servidor las ejecuta con sus propias credenciales. En la práctica van en variables de entorno al arrancar el servidor, jamás en el prompt del agente, y se rotan sin redeployar el agente. Esto reduce drásticamente el vector de prompt injection que busca exfiltrar tokens, aunque no lo elimina del todo.

¿Qué pasa cuando un agente usa más de un servidor MCP con herramientas del mismo nombre?

Las herramientas se presentan al modelo con prefijos por servidor, como fs:read_file, db:query o web:fetch, lo que evita la colisión de nombres. El orquestador decide a qué servidor va cada operación; el modelo no lo elige explícitamente. VS Code adoptó este mismo esquema de composición cuando su soporte de MCP llegó a disponibilidad general en julio de 2025, con Copilot mediando entre más de un servidor a la vez. La memoria entre servidores debe permanecer aislada para evitar inyecciones cruzadas.

Fuentes

  1. Model Context Protocol
  2. SDK de Agents de OpenAI documenta este mismo patrón
  3. su soporte de MCP llegó a disponibilidad general en julio de 2025
  4. Anthropic: Introducing the Model Context Protocol
  5. Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation
  6. Linux Foundation: formación de la Agentic AI Foundation