MCP explicado para empresas: qué es y cómo adoptarlo con seguridad

Qué es MCP, en términos simples

Un enchufe estándar entre las aplicaciones de IA y los sistemas que usan.

El Model Context Protocol es un protocolo abierto que Anthropic publicó el 25 de noviembre de 2024, con SDK y servidores de referencia para Google Drive, Slack, GitHub, Git, Postgres y Puppeteer. Antes, cada pareja de aplicación de IA y sistema necesitaba su propia integración; con MCP, un sistema expone un servidor y cualquier cliente compatible puede usarlo.

Hay tres roles. El anfitrión (host) es la aplicación donde trabaja el usuario: un asistente de chat, un IDE o tu propio agente. Dentro de él, un cliente MCP se conecta con cada servidor, que envuelve un sistema como una base de datos o una API SaaS. Los servidores corren en local, lanzados por el anfitrión, o en remoto sobre HTTP, el caso habitual en empresas.

Un servidor ofrece herramientas (acciones que el modelo puede llamar, con argumentos descritos en un esquema JSON), recursos (datos que la aplicación puede leer y poner en contexto) y prompts (plantillas reutilizables que elige el usuario). Las herramientas concentran casi todo el valor y casi todo el riesgo, porque es el modelo quien decide cuándo llamarlas.

Dos años de especificación: qué cambió y cuándo

Las versiones de MCP son fechas. Cinco revisiones importan para una empresa.

La revisión 2026-07-28 es la mayor desde el lanzamiento y rompe compatibilidad: elimina las sesiones del protocolo y el handshake de inicio, depreca Roots, Sampling y Logging, depreca formalmente el viejo transporte HTTP+SSE y fija una ventana mínima de 12 meses para cada deprecación. Los cuatro SDK de nivel 1 (TypeScript, Python, Go y C#) la soportaron el día del lanzamiento. Los servidores construidos sobre IDs de sesión necesitan un plan de migración.

Lo que cambia rápido llega ahora como extensiones oficiales: MCP Apps (interfaces interactivas en iframes aislados, enero de 2026), Tasks (aportada por AWS) y Enterprise Managed Authorization.

Gobernanza, registro y adopción de los grandes proveedores

MCP ya no es el protocolo de un solo proveedor.

El 9 de diciembre de 2025, Anthropic cedió MCP a la Agentic AI Foundation (AAIF), un fondo dirigido de la Linux Foundation cofundado por Anthropic, Block y OpenAI, con MCP, goose y AGENTS.md como proyectos fundadores. Sus miembros platino son AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft y OpenAI. MCP conserva sus propios mantenedores y su proceso de propuestas.

La adopción llegó antes. OpenAI anunció soporte de MCP en su Agents SDK en marzo de 2025 y en la Responses API en mayo; Google DeepMind dijo en abril de 2025 que Gemini lo soportaría, y Microsoft lo presentó en mayo como base de los agentes de Windows 11. Al momento de la cesión, MCP sumaba más de 97 millones de descargas mensuales de SDK y 10.000 servidores activos; en julio de 2026 sus SDK principales rondaban los 500 millones de descargas al mes. Google abrió además en vista previa pública, en diciembre de 2025, servidores MCP gestionados para Maps, BigQuery, Compute Engine y GKE.

El registro oficial de MCP abrió en vista previa el 8 de septiembre de 2025. Los nombres de servidor usan espacios de nombres ligados a cuentas de GitHub o dominios verificados, la moderación comunitaria puede bloquear servidores maliciosos o que suplantan a otros, y en noviembre de 2025 tenía cerca de 2.000 entradas. Figurar en él no equivale a una revisión de seguridad: necesitas tu propia lista permitida.

MCP, A2A, API, Agent Skills y AGENTS.md

Capas complementarias, no competidoras.

En la práctica se apilan: un agente de soporte puede seguir una skill que describe tu procedimiento de reembolsos, consultar el CRM por un servidor MCP y pasar una verificación de fraude al agente de otro equipo por A2A. Para una sola aplicación con un solo modelo, una API propia sigue siendo la respuesta correcta; MCP compensa cuando varios clientes de IA deben llegar a los mismos sistemas con los mismos controles.

Riesgos de seguridad: lo que ya salió mal

Cada servidor MCP es código o un servicio al que confías el contexto de tu modelo y, a menudo, credenciales.

La exposición es amplia: un preprint de un solo autor (julio de 2026, sin revisión por pares) encontró más de 21.000 servidores MCP expuestos a internet, y el 91,8 % de los 414 que auditó no tenía OAuth. En septiembre de 2026, el grupo de inteligencia de amenazas de Google reportó además copias troyanizadas de servidores MCP legítimos en PyPI. Más en inyección de prompts y agentes y cadena de suministro de IA.

Un diputado confundido (confused deputy) es un servidor que usa sus propios privilegios para un usuario que no debería tenerlos, o que reenvía un token a un servicio al que no estaba destinado. La especificación ata cada token a un servidor con los indicadores de recurso RFC 8707 (junio de 2025) y las credenciales a su emisor (julio de 2026); verificar cada llamada contra los derechos del usuario final sigue siendo tarea tuya.

Los controles que recomendamos

Ninguno es exótico; juntos contienen la mayoría de los casos anteriores.

• Servidores en lista permitida. Solo servidores aprobados por seguridad, publicados en un registro privado; nada instalado desde un enlace en un chat.
• Versiones fijadas. Fija cada servidor y revisa los cambios en nombres y descripciones de herramientas antes de actualizar.
• OAuth acotado. Tokens delegados por usuario, permisos estrechos, vida corta y sin reenviar tokens.
• Reglas de salida. Servidores y agentes solo llegan a los hosts que necesitan; los servidores locales corren en contenedores sin internet por defecto.
• Confirmación humana. Las herramientas destructivas (escribir, enviar, borrar, pagar) exigen aprobación. Las anotaciones de herramientas ayudan, pero un servidor malicioso puede etiquetar mal las suyas: confía en ellas solo si el servidor es tuyo.
• Registro. Cada llamada queda registrada con usuario, servidor, herramienta, argumentos y resultado, en logs de solo anexar, con una retención acorde a la ley de datos personales.
• Un gateway. Un único punto de entrada que autentica, autoriza por herramienta, limita el tráfico y registra; desde julio de 2026, las cabeceras Mcp-Method y Mcp-Name le permiten hacerlo sin leer el cuerpo de las peticiones.

El diseño de Microsoft para Windows (mayo de 2025) es una buena referencia: un registro central limitado a servidores que cumplen una línea base de seguridad, llamadas mediadas por un proxy de confianza y aprobación del usuario para cada par de cliente y herramienta.

Plan de adopción para una empresa, paso a paso

De un primer servidor de solo lectura a una plataforma gobernada.

1. Elige dos o tres casos de uso sobre todo de consulta, con responsable y métrica: buscar un cliente en el CRM, el estado de un pedido en el ERP, la documentación interna.
2. Revisa lo que ya publican tus proveedores. Los servidores oficiales de tus proveedores SaaS y cloud suelen superar a los comunitarios, previa revisión.
3. Construye servidores internos delgados. El servidor MCP llama a la API que ya tiene tu CRM o ERP, que conserva las reglas de negocio, la validación y la autorización; lectura y escritura van en herramientas separadas.
4. Pon un gateway adelante, conectado a tu proveedor de identidad, con tokens por usuario, autorización por herramienta, límites de tráfico y logs.
5. Mantén una lista permitida y un registro privado con versiones fijadas y un responsable por servidor.
6. Evalúa y ataca antes de lanzar: precisión al elegir herramientas en tareas reales y casos de inyección escondidos en documentos y resultados (ver evaluación de LLM).
7. Abre las escrituras de forma gradual, cada una con confirmación, claves de idempotencia y un camino de reversión.
8. Gobiérnalo como una plataforma de API: revisión trimestral de servidores y permisos, una política de deprecación (la especificación usa 12 meses) y un plan de respuesta a incidentes.

En Colombia y en Europa, los logs de llamadas a herramientas suelen contener datos personales sujetos a la Ley 1581 de 2012 y al RGPD: aloja los servidores internos y sus logs donde lo pida tu análisis de protección de datos y fija plazos de retención. Para sistemas regulados, prefiere servidores que corran en tu propia nube a servidores remotos de terceros que no puedes auditar.

Es la secuencia que recomendamos en nuestros proyectos de agentes de IA y de software a la medida; el resto de la arquitectura está en agentes de IA en producción.