El Model Context Protocol (MCP) es un estándar abierto —publicado por Anthropic a finales de 2024 y adoptado después por buena parte del ecosistema de IA— que define una forma común de conectar modelos de lenguaje con herramientas, datos y servicios externos. Dicho en una frase: MCP es a los agentes de IA lo que USB-C es a los periféricos. En lugar de programar una integración a medida por cada herramienta y cada modelo, expones un servidor MCP y cualquier cliente compatible puede usarlo.

Suena bien sobre el papel. La pregunta que nos hacen los equipos técnicos no es "qué es MCP", sino "¿lo monto en producción o todavía no?". Esta guía responde a eso sin hype: qué resuelve, cómo funciona, en qué estado está el estándar en 2026 y, sobre todo, cuándo no deberías usarlo.

Qué problema resuelve MCP (y cuál no)

Antes de MCP, conectar un LLM a tus sistemas significaba escribir function calling específico para cada proveedor. Cambiabas de modelo y reescribías las integraciones. Añadías una herramienta nueva y tocabas el cliente. El resultado era el clásico problema M×N: M modelos por N herramientas, todo acoplado.

MCP convierte ese M×N en M+N. Defines una herramienta una vez, como servidor MCP, y la consumen todos los clientes compatibles. Eso es lo que resuelve: la interoperabilidad y el desacoplamiento entre el modelo y tus capacidades.

Lo que MCP no resuelve: no hace tu agente más inteligente, no decide cuándo llamar a una herramienta (eso sigue siendo el modelo más tu orquestación) y no sustituye a una buena API. Si tu integración con la IA es un único endpoint que llamas desde tu backend, MCP probablemente te sobra.

Cómo funciona: hosts, clientes y servidores

El protocolo define tres piezas:

  • Host: la aplicación donde vive el modelo (un IDE, un asistente, tu propia app).
  • Cliente: el componente dentro del host que abre una conexión con un servidor.
  • Servidor: el proceso que expone capacidades. Hay tres tipos: tools (acciones que el modelo puede ejecutar), resources (datos que puede leer) y prompts (plantillas reutilizables).

Un servidor MCP mínimo que expone una herramienta se declara más o menos así:

@mcp.tool()
def buscar_pedido(pedido_id: str) -> dict:
    """Devuelve el estado de un pedido a partir de su ID."""
    return db.get_order(pedido_id)

El modelo recibe el esquema de buscar_pedido, decide si la invoca y el servidor ejecuta la lógica. La clave está en el esquema y en la descripción: son el contrato que el modelo lee para decidir. Un buen servidor MCP se diseña pensando en el agente que lo va a leer, no en replicar tu API interna.

El estado del estándar en 2026

MCP ya no es un experimento, pero tampoco está "terminado". El roadmap 2026 del proyecto prioriza precisamente los puntos que duelen al llevarlo a producción:

  • Escalado horizontal sin estado: las sesiones con estado (stateful) chocan con los balanceadores de carga. El trabajo apunta a que un servidor pueda escalar horizontalmente sin retener estado.
  • Descubrimiento vía .well-known: un formato de metadatos para que un registro o un cliente sepa qué hace un servidor sin abrir una conexión viva.
  • Comunicación entre agentes: semánticas de reintento y expiración para la primitiva Tasks.
  • Madurez empresarial: trazas de auditoría, autenticación integrada con SSO, comportamiento de gateways y portabilidad de configuración.

Traducción honesta: si vas a exponer un servidor MCP remoto a escala, en 2026 todavía estás construyendo sobre terreno que se está pavimentando. Para uso interno y herramientas acotadas, está perfectamente listo.

Diseñar un servidor MCP que aguante producción

Los errores que más vemos no son de protocolo, son de diseño:

  1. No envuelvas tu API entera. Un servidor MCP no es un proxy de tu OpenAPI. Pocas herramientas bien pensadas y orientadas a un objetivo rinden mejor que cincuenta endpoints granulados, sobre todo con ventanas de contexto y latencia ajustadas.
  2. Descripciones que el modelo entienda. La descripción de la herramienta es prompt, no documentación. Sé explícito sobre cuándo usarla y qué devuelve.
  3. Valida en el servidor. Nunca confíes en que el modelo mande argumentos válidos. Esquemas estrictos y validación del lado del servidor, siempre.
  4. Servidores pequeños y con permisos acotados. Varios servidores con alcance reducido se auditan y se aseguran mejor que un monolito todopoderoso.
  5. Observabilidad desde el día uno. Necesitas saber qué herramienta se llamó, con qué argumentos y con qué resultado. Esto enlaza directamente con cómo planteamos la observabilidad en aplicaciones.

Seguridad: el punto que más se subestima

MCP da a un modelo la capacidad de ejecutar acciones. Eso es potente y peligroso a la vez. Para servidores locales con transporte stdio, el proceso hereda los privilegios de su padre: confía en el aislamiento del sistema operativo. Para servidores remotos, autenticación seria (SSO/OAuth), nada de invocaciones sin firmar sobre HTTP, credenciales en variables de entorno —nunca en el esquema de la herramienta ni en el payload— y validación estricta de todas las entradas.

El vector nuevo es la inyección de prompts a través de datos: si una herramienta devuelve contenido que el modelo va a leer, ese contenido puede contener instrucciones maliciosas. Trata toda salida de herramienta como entrada no confiable.

Cuándo NO deberías montar un MCP

Por coherencia con cómo trabajamos, lo decimos claro. No uses MCP si:

  • Tu integración con la IA es una sola llamada a una API desde tu backend. El function calling nativo es más simple y suficiente.
  • No tienes más de un cliente ni planeas tenerlo. El beneficio de MCP es la interoperabilidad; sin ella, añades una capa sin retorno.
  • Necesitas latencia extrema y control total del flujo. Una integración directa te dará menos saltos.
  • Tu equipo aún no tiene observabilidad ni control de costes sobre las llamadas al LLM. Resuelve eso antes.

MCP brilla cuando tienes varias herramientas, varios consumidores y quieres desacoplarlos del modelo. Ese es el caso, no "porque está de moda".

Cómo lo abordamos en Dribba

En Dribba llevamos desde 2011 construyendo producto digital con equipo senior 100% in-house, y la IA aplicada es hoy una de nuestras áreas de trabajo junto con Flutter y backend en Go. Cuando un cliente quiere agentes o integraciones de IA, empezamos por la pregunta incómoda: ¿esto necesita un agente, o es un flujo determinista con una llamada a un LLM? Solo cuando MCP aporta desacoplamiento real lo introducimos, con servidores acotados, validación estricta y observabilidad desde el principio. Si vienes de integrar IA generativa, quizá te interese antes nuestra guía sobre RAG y LLMs en apps empresariales y el backend en Go sobre el que solemos desplegarlos.

Conclusión

MCP es un estándar sólido para el problema correcto: desacoplar modelos de herramientas cuando tienes varias de cada. No te hace el agente más listo ni sustituye una buena arquitectura. En 2026 está listo para uso interno y acotado, y madurando rápido para despliegues remotos a escala. La decisión no es "MCP sí o no", sino "¿tengo el problema que MCP resuelve?".

¿Estás valorando agentes o integraciones de IA en tu producto y no tienes claro el alcance? Hablemos con nuestro equipo antes de escribir una línea de código.