$ el problema antes de la solución

Antes de MCP, si querías que un modelo de IA hablara con tu base de datos, con tu sistema de archivos, con una API interna o con cualquier herramienta externa, tenías que escribir esa integración a medida. Cada combinación de modelo y herramienta era su propio código pegamento. Multiplica eso por N modelos y M herramientas, y tienes N×M integraciones que mantener.

MCP —Model Context Protocol— es un estándar abierto, publicado por Anthropic, que intenta reducir ese problema a N+M: cada herramienta implementa el protocolo una vez, cada cliente (un editor, un agente, una app) implementa el protocolo una vez, y a partir de ahí se entienden entre sí sin código pegamento específico para cada par.

Eso es todo lo que es. No es más que eso, y no es menos.

Qué resuelve de verdad

Estandariza la conexión, no la inteligencia. MCP define cómo un cliente descubre qué puede hacer un servidor —qué datos puede leer, qué acciones puede ejecutar, qué prompts predefinidos ofrece— y cómo se comunican. Es la parte de "cableado", no la parte de "razonamiento".

Reutilización real. Un servidor MCP para, por ejemplo, tu sistema de tickets, lo puedes usar desde Claude Code, desde Cursor, o desde cualquier otro cliente que hable el protocolo, sin reescribirlo para cada uno. Eso es la ganancia concreta frente a integraciones a medida.

Separación de responsabilidades. Quien mantiene la herramienta (la base de datos, la API, el sistema de archivos) no necesita saber nada del modelo que la va a usar. Quien construye el cliente no necesita saber los detalles internos de cada herramienta. El protocolo es el contrato entre los dos.

Qué NO resuelve

No mejora la calidad del razonamiento del modelo. Darle a un agente acceso a diez herramientas vía MCP no lo hace más inteligente al decidir cuándo usar cada una. Si el modelo elige mal la herramienta o interpreta mal el resultado, MCP no arregla eso: solo transportó los datos correctamente.

No resuelve seguridad ni permisos por sí solo. Que un servidor MCP exponga una acción no significa que esa acción deba estar disponible sin control. Qué herramientas conectas, con qué alcance y con qué credenciales sigue siendo una decisión tuya, no algo que el protocolo decide por ti. Conectar un servidor MCP con permisos de escritura sobre algo sensible sin pensarlo es un error de quien lo configura, no del protocolo.

No resuelve el problema de descubrimiento y curación. A medida que existen más servidores MCP disponibles, elegir cuáles instalar, cuáles confiar y cuáles mantener no es algo que el protocolo automatice. Sigue siendo trabajo humano de criterio.

No sustituye una buena arquitectura. Si tu sistema interno es un desastre de acoplamientos, exponerlo vía MCP no lo ordena. Simplemente le añade una puerta de entrada más sobre el mismo desastre.

Cuándo merece la pena usarlo

Tiene sentido cuando de verdad necesitas que un agente hable con algo externo de forma repetible: tu propio sistema, una API interna, una fuente de datos que consultas a menudo. No tiene mucho sentido montar un servidor MCP para una tarea puntual que puedes resolver pegando el dato directamente en el contexto.

Como con cualquier estándar, el valor no está en adoptarlo porque existe. Está en el número de veces que te ahorra reescribir la misma integración.