Cada semana aparece una sigla nueva en IA y la mayoría no sobrevive seis meses. El MCP (Model Context Protocol) es una de las que vale la pena entender — no porque esté de moda, sino porque resuelve un problema real y molesto que quien construye agentes de IA conoce de memoria: conectar el modelo a las herramientas del mundo real da trabajo, y todos reinventan la rueda.
Esta es la guía directa. Qué es, qué resuelve, cuándo usarlo de verdad — y cuándo es solo complejidad de más.
El problema que el MCP resuelve
Un agente de IA que solo conversa es un chatbot mejorado. Un agente que actúa — consulta un pedido, genera una factura, abre un ticket — es software de verdad. Ya escribí sobre esto en la guía de function calling: la diferencia entre charla y producto son las herramientas que el modelo puede accionar.
El problema es que, históricamente, cada herramienta se conectaba de una forma. Escribes el código que describe la herramienta al modelo, el código que la ejecuta, el código que la valida — todo a medida, para ese agente, en ese proyecto. Después empiezas otro proyecto y haces todo de nuevo. ¿La integración con el mismo CRM que ya hiciste tres veces? De nuevo. Multiplica eso por decenas de herramientas y varios agentes y tienes un pantano de integraciones que nadie reutiliza.
El MCP ataca exactamente eso: estandarizar cómo un LLM descubre y usa herramientas externas, para que una integración hecha una vez sirva para cualquier agente compatible.
La analogía del USB-C
Antes del USB-C, cada aparato tenía su conector. El cargador de un celular no servía en el otro. El USB-C no hizo los aparatos más potentes — hizo que el acoplamiento fuera estándar, y de repente un solo cable sirve para todo.
El MCP es eso para los agentes de IA. Antes: cada "cliente" de IA (un agente, una app, un asistente) se conectaba a cada "servidor" de herramienta (tu CRM, tu base de datos, tu API) con cableado propio. Después: el cliente habla MCP, el servidor habla MCP, y se entienden sin código a medida.
En la práctica, el protocolo define dos extremos:
- Servidor MCP: expone capacidades — herramientas (acciones que el modelo puede ejecutar), recursos (datos que puede leer) y prompts (instrucciones reutilizables). Quien tiene un sistema (un ERP, una base de conocimiento) escribe un servidor MCP una sola vez.
- Cliente MCP: es el lado del agente/aplicación. Descubre lo que ofrece el servidor y lo pone a disposición del modelo, de forma estandarizada.
La ganancia es la composición: conecta un cliente a varios servidores, o varios clientes al mismo servidor, sin reescribir el pegamento cada vez.
El MCP no sustituye al function calling — lo organiza
Aquí vive la confusión más común. MCP y function calling no son competidores.
- Function calling es la habilidad del modelo de, en medio de la conversación, decir "quiero llamar a la herramienta
buscar_pedidocon este argumento". Es el razonamiento del modelo eligiendo actuar. - MCP es el estándar de cómo esa herramienta se describe, se descubre y se expone. Es el enchufe; function calling es la decisión de conectarse.
Sigues necesitando function calling. El MCP solo hace que la herramienta que el modelo llama venga de un lugar estandarizado, en vez de cableado a medida. Toda la disciplina que predico sobre las herramientas sigue valiendo — y vale la pena reforzarla:
El modelo no ejecuta nada. Él decide qué llamar; quien ejecuta, valida y confirma es tu código, de tu lado. El MCP estandariza el transporte, no la responsabilidad. Un servidor MCP que ejecuta una acción irreversible sin validación y confirmación es tan peligroso como un function calling mal hecho. El protocolo no te salva de una mala arquitectura.
Cuándo usar MCP (y cuándo no)
Soy pesado con esto porque ya vi proyectos morir de complejidad adoptada demasiado pronto. El MCP es una herramienta, no una religión.
Vale la pena cuando:
- Tienes muchas herramientas y quieres reutilizarlas entre agentes/proyectos sin reescribir el pegamento.
- Quieres conectar servidores listos de terceros (un servidor MCP que ya habla con determinado sistema) en vez de integrar desde cero.
- Estás montando una plataforma donde las herramientas entran y salen, y un estándar evita el caos de N integraciones ad-hoc.
- Quieres que el mismo conjunto de herramientas sirva a clientes diferentes (un asistente de escritorio, un agente en WhatsApp, una app interna).
Probablemente es overkill cuando:
- Tu agente es pequeño y enfocado, con tres o cuatro herramientas que solo él usa. La integración directa con function calling es más simple y no pagas el costo de infraestructura del protocolo.
- Tienes una sola integración y ningún plan de reutilizarla. Estandarizar un caso único es ceremonia sin retorno.
- El cuello de botella de tu proyecto no es la integración — es la definición del alcance, la calidad de la conversación o la decisión de negocio. El MCP no resuelve ninguno de esos.
La pregunta que me hago: ¿cuántas veces voy a reutilizar esta herramienta? Si la respuesta es "una", integración directa. Si es "muchas, en lugares diferentes", el estándar empieza a pagarse solo.
Lo que el MCP cambia en el día a día de quien construye
Menos pegamento, más reuso. Un servidor MCP bien hecho para tu ERP se convierte en un activo: el próximo agente que necesite hablar con el ERP ya tiene el enchufe listo. Eso acorta el camino entre la idea y el producto en el aire — que es, al final, lo que importa.
Pero hay un costo. Agregas una capa (cliente + servidor, transporte, descubrimiento) que hay que operar, versionar y monitorear como cualquier infraestructura. En producción, eso significa las mismas preguntas de siempre: ¿qué pasa si el servidor MCP se cae? ¿Cómo registras lo que hizo cada herramienta? ¿Cómo validas la acción antes de ejecutarla? El protocolo estandariza la cañería; la resiliencia sigue siendo trabajo tuyo — igual que lo que describí en la arquitectura de agentes que aguantan producción.
El resumen honesto
El MCP es un estándar útil que resuelve un problema real: el desorden de las integraciones a medida entre LLMs y herramientas. Es el USB-C de los agentes — estandariza el acoplamiento, no la inteligencia. No sustituye al function calling; organiza de dónde vienen las herramientas. Brilla en escala y reuso; es peso muerto en un agente pequeño y único.
Como toda tecnología nueva, el error no es ignorarla ni abrazarla a ciegas — es adoptarla sin preguntar qué problema mío resuelve esto hoy. Si tienes muchas herramientas para reutilizar, vale la pena estudiarla. Si todavía estás peleando para poner el primer agente en el aire, resuelve el primer agente. El estándar va a estar ahí cuando llegue la escala.
Construyo agentes de IA que actúan en producción — con o sin MCP, siempre con la integración real y la validación que exige el mundo de verdad. Si tienes herramientas y sistemas para conectar a un agente, conversemos.