MCP: por qué su próxima integración con IA no será una API a medida

Durante dos años, conectar un asistente de IA con un sistema interno significó escribir una integración a medida por cada pareja: este modelo con aquel ERP, ese asistente con este CRM. El Model Context Protocol convirtió ese trabajo en un conector reutilizable.

Qué es, en una frase

MCP es un estándar abierto que define cómo un asistente descubre y usa herramientas externas — bases de datos, APIs, sistemas de ficheros — sin que haya que programar esa conexión para cada modelo. Se escribe el servidor una vez y sirve para cualquier cliente que hable el protocolo.

La adopción no es teórica: el SDK supera los 400 millones de descargas mensuales, cuatro veces más que hace un año. Cuando un estándar crece así, la pregunta deja de ser si adoptarlo.

Lo que cambió en la revisión de 2026

La versión del 28 de julio de 2026 movió el protocolo de un modelo con estado a uno de petición y respuesta sin estado. Suena técnico y tiene una consecuencia muy práctica: un servidor sin estado escala como cualquier servicio web normal. Se pone detrás de un balanceador, se replica y se reinicia sin ceremonia.

Si evaluó MCP hace un año y lo descartó por complejidad operativa, la evaluación está vencida.

La parte que casi nadie planifica

Un servidor MCP es una puerta a un sistema interno. Que sea estándar no lo hace seguro, igual que HTTP no hace segura una web. Antes de abrirlo en producción:

• Autenticación centralizada. Quién usa el servidor y con qué identidad, gestionado donde ya gestiona el resto — Entra ID en una casa Microsoft — no con una clave en un fichero de configuración.
• Rastro de auditoría. Qué herramienta se invocó, con qué parámetros, en nombre de quién. Sin esto, el día que alguien pregunte qué consultó el agente no habrá respuesta.
• Permisos por herramienta, no por servidor. Que un agente pueda leer pedidos no significa que deba poder anularlos. La granularidad se diseña antes, no después del susto.
• Límites de uso. Un agente en bucle puede lanzar miles de llamadas en minutos. Su sistema interno no está dimensionado para eso.

Un servidor MCP local, en el portátil de un desarrollador, es un experimento. Uno en producción es una interfaz más de su sistema, y merece el mismo gobierno que cualquier API que publique.

Por dónde empezar

No empiece exponiendo su ERP. Empiece por algo de solo lectura y con valor evidente: consultar el estado de un pedido, buscar en la documentación técnica, leer indicadores. Con eso se aprende el patrón de autenticación y auditoría sin arriesgar nada. Escribir vino después.

Y una recomendación de arquitectura: no construya un servidor MCP gigante que lo haga todo. Construya varios pequeños por dominio. Se versionan, se despliegan y se retiran por separado, que es exactamente lo que va a querer dentro de un año.