Model Context Protocol (MCP)

Para qué sirve MCP

Antes de que existiera un protocolo común, cada combinación de asistente y herramienta era una integración propia, escrita dos veces y mantenida para siempre: cinco asistentes y veinte herramientas significaban cien conexiones a medida. MCP convierte eso en una suma en vez de una multiplicación. Quien crea una herramienta escribe un servidor, quien crea una aplicación escribe un cliente, y cualquier cosa de un lado puede hablar con cualquier cosa del otro. Anthropic lo publicó como estándar abierto a finales de 2024 y desde entonces se ha adoptado mucho más allá. Se parece más a una interfaz de controladores de dispositivo que a una API de producto: el valor no está en lo que puede hacer, sino en que todos acordaron la forma.

El esquema es cliente-servidor. La aplicación que aloja el modelo es el cliente; cada capacidad que quieras exponer corre como un servidor que describe lo que ofrece de forma legible por máquina, para que el modelo vea las opciones y elija. Es independiente del transporte — un servidor puede ser un proceso local en la misma máquina o algo accesible por HTTP —, y por eso la misma integración funciona en un asistente de escritorio, en un agente de IA que corre en un servidor y en una herramienta de programación sin reescribirse para cada uno.

Qué expone un servidor

Un servidor ofrece tres tipos de cosas, y la distinción importa cuando construyes uno:

• Herramientas — acciones que el modelo puede invocar: enviar un mensaje, consultar una tabla, crear un registro. Son las que tienen consecuencias y con las que conviene tener cuidado.
• Recursos — datos que el cliente puede traer al contexto: un archivo, un documento, una fila, el contenido de una página. Material de solo lectura que se le entrega al modelo, no algo que él hace.
• Prompts — instrucciones reutilizables y parametrizadas que una persona elige de forma deliberada, en lugar de algo a lo que el modelo recurre por su cuenta.

Lo que el protocolo no resuelve

Un estándar de conexión elimina la fontanería y deja intacto todo lo difícil. Lo primero que aparece en la práctica es que tener herramientas no es gratis. Cada capacidad que un modelo puede llamar hay que describírsela, y esas descripciones ocupan el mismo contexto limitado que el propio trabajo, así que un catálogo grande compite en silencio con la tarea. Nos topamos exactamente con esto construyendo agentes para clientes en AgentCeres — el Director de Crecimiento con IA en agentceres.com: pasado cierto número de capacidades disponibles, el catálogo hay que resumirlo para que quepa, lo que significa que cada integración adicional cuesta algo aunque nadie la use. La disciplina de ingeniería acaba siendo decidir a qué *no* debería poder llegar un agente.

La segunda carencia es la autoridad. El protocolo describe cómo llamar a una herramienta; no dice nada sobre si este agente, actuando para este cliente y ahora mismo, debería poder hacerlo. Una herramienta que lee una hoja de cálculo y otra que publica en la cuenta social de una empresa son idénticas para el protocolo y completamente distintas para el negocio. Esa frontera pertenece a tu propio producto, y por eso todo lo que tiene consecuencias públicas en nuestro caso espera detrás de una puerta de aprobación con una persona al mando, sin importar cómo se conectó la capacidad.