¿Qué es MCP (Model Context Protocol)? Guía completa

Tienes un agente de IA que atiende a clientes. Genial. Ahora quieres que ese agente pueda consultar el CRM cuando un cliente pregunta por su pedido, abrir un ticket en tu herramienta de soporte cuando no sabe resolver algo, y buscar en tu base de conocimiento antes de contestar cualquier duda de producto. Tres herramientas. Tres conectores a medida. Tres integraciones que mantener cada vez que alguna de esas APIs cambia algo mínimo. Y eso con solo tres herramientas — porque cuando llegas a cinco, a ocho, a doce, te das cuenta de que estás construyendo fontanería en vez de IA.

Ese es exactamente el problema que resuelve el MCP (Model Context Protocol): un estándar abierto que actúa como capa universal entre los agentes de IA y cualquier herramienta, dato o servicio externo. No un framework más, no una librería propietaria: un protocolo de comunicación. Como HTTP para la web o USB-C para los periféricos.

En GuruSup llevamos meses integrando MCP en los agentes de atención al cliente que desplegamos para empresas, y lo que te cuento aquí no es teoría: es lo que vemos que funciona, lo que no, y por qué MCP va a ser tan estructural en la IA como lo fue REST en las APIs. Anticipamos que en dos años hablar de conectar un agente sin MCP va a sonar igual que hablar de montar una web sin HTTP.

¿Por qué integrar tu agente con cada herramienta era un infierno antes de MCP?

Antes de que existiera MCP, conectar un LLM con herramientas externas se hacía de una sola manera: function calling. El desarrollador describía cada función disponible —nombre, parámetros, qué devuelve—, el modelo decidía cuándo llamarla, y el código ejecutaba esa llamada y devolvía el resultado al modelo. Funciona. Pero no escala.

El primer problema es el de mantenimiento: cada herramienta nueva requiere escribir su esquema de función desde cero. Cada cambio en la API del proveedor rompe ese esquema. El equipo técnico pasa a ser un departamento de fontanería de integraciones en lugar de construir valor real.

El segundo problema es la portabilidad: cada LLM tiene su propio formato para describir las funciones disponibles. La lógica que escribes para Claude no sirve para GPT ni para Gemini. Si decides cambiar de modelo de IA — algo cada vez más común a medida que el mercado madura — tienes que reescribir todas tus integraciones desde cero.

El tercer problema es la escala en sistemas multiagente: si montas un sistema multiagente donde varios agentes especializados tienen que compartir las mismas herramientas, tienes que replicar toda esa lógica en cada agente. El resultado es un laberinto de conectores a medida que nadie quiere tocar.

En la industria llaman a esto el problema N×M: si tienes N herramientas y M agentes (o modelos), necesitas N×M integraciones distintas. Con diez herramientas y cinco agentes, son cincuenta integraciones. MCP lo convierte en N+M — cada herramienta se integra una sola vez como MCP server, y cada agente se conecta una sola vez como MCP client. Quince en total.

¿Qué es MCP exactamente?

El Model Context Protocol (MCP) es un estándar abierto creado por Anthropic en noviembre de 2024 que define cómo los agentes de IA descubren herramientas externas, acceden a datos y ejecutan acciones de forma estandarizada. Es open-source, tiene SDKs oficiales en Python, TypeScript, Java y C#, y cualquier empresa puede implementar un MCP server para sus propios sistemas sin pagar licencias ni depender de ningún proveedor concreto.

La analogía más usada — y más acertada — en el ecosistema es esta: MCP es el USB-C de los agentes de IA. Antes del USB-C, cada fabricante tenía su conector propio: micro-USB, Lightning, mini-USB, propietarios varios. Llevabas tres cables de viaje para tres dispositivos. El USB-C estandarizó la interfaz para que cualquier dispositivo se conectara a cualquier periférico con un único cable. MCP hace lo mismo con las herramientas de IA: estandariza la interfaz para que cualquier agente se conecte a cualquier sistema sin código específico de integración.

Lo que MCP no es es igual de importante que lo que es. No es un framework de agentes como LangChain o LangGraph — no decide cuándo llamar a una herramienta ni con qué propósito. No reemplaza tu lógica de orquestación. No es una API más. Es la capa de fontanería estándar debajo de la que vive toda esa lógica: la que hace que los tubos encajen sin tener que soldarlos a mano cada vez.

¿Cómo funciona MCP por dentro?

La arquitectura: hosts, clients y servers

MCP organiza cada integración en tres componentes con roles bien delimitados que no se solapan.

El MCP host es la aplicación de IA que recibe las peticiones del usuario y decide qué herramientas necesita. Ejemplos concretos del ecosistema actual: Claude Desktop, Cursor (el IDE con IA), Windsurf, o un agente personalizado que hayas construido con LangGraph o crewAI. El host contiene la lógica de orquestación y puede conectar múltiples clients de forma simultánea, cada uno comunicándose con un server distinto.

El MCP client vive dentro del host y gestiona la comunicación con un servidor concreto. Convierte las intenciones del modelo en mensajes estructurados del protocolo, gestiona la sesión, maneja errores y reconexiones. Un host puede tener varios clients activos al mismo tiempo — uno para el CRM, otro para el sistema de ticketing, otro para la base de conocimiento — sin que interfieran entre sí. Cada client mantiene una relación uno a uno con su server.

El MCP server es el servicio externo que expone sus capacidades a través del protocolo. Puede ser un servidor que implementas tú mismo para tus sistemas internos, o uno de los cientos de servidores ya disponibles en el ecosistema open-source: Slack, GitHub, Google Drive, PostgreSQL, Jira, Notion, HubSpot. El server no sabe nada del agente que lo está llamando. Solo recibe peticiones MCP y responde. Esa independencia es exactamente lo que lo hace reutilizable.

Las tres primitivas: tools, resources y prompts

Un MCP server puede exponer tres tipos de capacidades. Entenderlas bien es la diferencia entre usar MCP de forma superficial y usarlo de verdad.

Tools son acciones que producen un efecto en el mundo: crear un ticket, enviar un mensaje a Slack, ejecutar una query SQL, llamar a una API de pago externa. Tienen efectos secundarios y requieren inputs definidos con su esquema JSON Schema. Cuando el agente invoca un tool, algo cambia en algún sistema real.

Resources son datos que el agente puede consultar sin modificar nada: el historial de conversaciones de un cliente, el contenido de un fichero, el estado de un sistema de monitorización. Los resources devuelven información pero no ejecutan cálculos ni acciones con consecuencias. Son el equivalente a un GET puro que no tiene efectos secundarios.

Prompts son plantillas e instrucciones reutilizables que el servidor pone a disposición del agente. Flujos de trabajo predefinidos, formatos de respuesta específicos para un dominio concreto, contextos de sistema complejos. Un agente puede descubrir qué prompts tiene disponibles en tiempo de ejecución y usarlos sin que el desarrollador los haya codificado de antemano. Esto permite que los equipos que construyen los servers — que conocen bien el dominio — preparen instrucciones de alta calidad sin necesidad de tocar el código del agente.

Esta separación en tres primitivas no es caprichosa. Que el modelo sepa distinguir entre "puedo consultar esto sin riesgo" (resource) y "puedo hacer esto con consecuencias reales" (tool) le permite un control mucho más fino sobre los permisos, las reversiones y el impacto de cada acción.

¿Cómo fluye la información?

La comunicación entre MCP clients y servers usa JSON-RPC 2.0 como formato de mensajería. Hay tres tipos de mensajes: peticiones que esperan respuesta, respuestas, y notificaciones que no requieren respuesta. Este formato permite enviar estructuras de datos arbitrarias con reglas de procesamiento claras y sin ambigüedad.

Para el transporte hay dos mecanismos principales. STDIO (entrada/salida estándar) funciona para integraciones locales: sistemas de ficheros, bases de datos locales, herramientas en la misma máquina. Es síncrono, simple y con latencia mínima. SSE (Server-Sent Events sobre HTTP) funciona para recursos remotos: llamadas a APIs externas, servicios cloud, cualquier cosa que requiera comunicación asíncrona o basada en eventos desde varios clientes simultáneos.

Lo que hace esta arquitectura especialmente potente para sistemas agénticos es la comunicación bidireccional: los servers no solo responden peticiones del client, también pueden enviar notificaciones al host cuando algo cambia en el sistema que monitorizan. Un agente que gestiona incidencias puede recibir alertas en tiempo real sin tener que hacer polling constante, y reaccionar inmediatamente.

¿Qué problema resuelve MCP en la práctica?

Volvamos al escenario concreto. Tu agente de atención al cliente necesita conectar con el CRM, el sistema de tickets y la base de conocimiento.

Sin MCP: escribes tres conectores a medida, tres esquemas de function calling con sus tipos y validaciones, lógica de gestión de errores y retry para cada uno, y vuelves a hacerlo todo si cambias de modelo de IA o si el proveedor del CRM actualiza su API. Cada nuevo agente que necesita esas mismas herramientas copia esa lógica o depende de la tuya.

Con MCP: implementas (o instalas del catálogo open-source) tres MCP servers — uno para cada sistema. Tu agente, como MCP client, los descubre en tiempo de ejecución, ve qué tools y resources expone cada uno, y los invoca cuando los necesita. Si mañana cambias el agente de Claude a GPT o a tu propio modelo open-source, los servers siguen siendo exactamente los mismos. No tocas nada.

Hay tres beneficios que vemos de forma consistente en producción:

Reutilización real. Un MCP server de Slack que construyes para el agente de ventas lo reutilizas en el agente de soporte sin tocar una línea. La integración se escribe una sola vez y sirve para todos los agentes que la necesiten ahora y en el futuro.

Descubrimiento dinámico. El agente no necesita saber de antemano qué herramientas están disponibles. Pregunta al servidor en tiempo de ejecución, recibe la lista de capabilities con sus esquemas, y decide. Esto permite construir agentes más adaptativos sin hardcodear cada caso de uso en el código del agente.

Gobernanza y control. Los servers MCP gestionan ellos mismos los permisos de acceso, la autenticación y el rate limiting. El agente no necesita gestionar credenciales ni entender los detalles de implementación de cada API. Eso reduce la superficie de ataque, simplifica la auditoría y separa la responsabilidad de seguridad al equipo que mejor conoce cada sistema.

MCP vs A2A: ¿cuál es la diferencia?

Cuando Anthropic publicó MCP en noviembre de 2024, Google respondió en abril de 2025 con A2A (Agent-to-Agent Protocol). Los dos son estándares abiertos de comunicación para IA, los dos tienen soporte de los principales actores del sector, y los dos son necesarios. Pero resuelven problemas distintos.

MCP está diseñado para la conexión entre un agente y sus herramientas o datos externos. Es la capa de integración vertical: modelo ↔ sistema. Su foco es que el agente pueda acceder a recursos externos y ejecutar acciones en sistemas existentes de forma estandarizada.

A2A está diseñado para la comunicación entre agentes distintos: delegación de tareas de un agente a otro, coordinación entre agentes especializados de diferentes empresas, paso de contexto entre agentes de diferentes proveedores de IA. Es la capa de integración horizontal: agente ↔ agente.

En un sistema multiagente real, los dos coexisten de forma natural. Un agente orquestador usa A2A para delegar subtareas a agentes especializados, y cada uno de esos agentes especializados usa MCP para acceder a las herramientas que necesita en su dominio. No tienes que elegir entre ellos — sirven para niveles diferentes del mismo sistema.

Lo que esto significa para las empresas que construyen soluciones con agentes de IA hoy: MCP es la pieza que conecta tus agentes con tus sistemas internos y externos. A2A es la que los hace colaborar entre sí. La arquitectura que gana es la que usa los dos en el nivel correcto.

MCP en atención al cliente: lo que cambia de verdad

Un agente de atención al cliente con IA tiene exactamente el problema de integración para el que MCP fue diseñado. Necesita acceder al historial del cliente (resource), crear un ticket cuando no puede resolver algo (tool), consultar el estado de un envío en tiempo real a través de una API de logística (tool), y buscar en la base de conocimiento antes de responder cualquier pregunta de producto (resource).

Antes de MCP, cada una de esas conexiones era un conector a medida mantenido por el equipo de desarrollo. Cuando el proveedor del CRM actualizaba su API, alguien tenía que actualizar el conector — con suerte antes de que el agente empezara a fallar en producción. Cuando cambiabas de CRM, reescribías todo. Cuando el agente fallaba en un caso concreto, depurar qué había salido mal requería entender la lógica interna de cada conector a la vez.

Con MCP, el servidor MCP del CRM gestiona su propia integración. El agente habla siempre el mismo protocolo. Si cambias de CRM, cambias el server — que puede ser mantenido por el propio equipo del CRM — no el agente. Si cambia la API de logística, el equipo que mantiene ese server actualiza su implementación sin que el equipo de IA tenga que tocar nada.

El resultado operativo es concreto: menos tiempo del equipo técnico en mantenimiento de integraciones y más tiempo construyendo la lógica de negocio que diferencia tu agente. Para una empresa que atiende miles de conversaciones al mes —incluyendo las que llegan por teléfono a través de un agente de voz con IA— eso se traduce en velocidad de iteración y en capacidad de añadir nuevas herramientas en días en lugar de semanas.

¿Qué ecosistema tiene MCP hoy?

En menos de dos años desde su lanzamiento, MCP ha acumulado un ecosistema de servidores impresionante para ser un protocolo tan joven. Anthropic mantiene un repositorio oficial con servers para los sistemas más usados en entornos empresariales: Google Drive, Slack, GitHub, Git, PostgreSQL, Jira y Puppeteer, entre otros.

Fuera del repositorio oficial, la comunidad open-source ha construido cientos de MCP servers adicionales para casi cualquier sistema imaginable: Notion, HubSpot, Salesforce, Airtable, Linear, bases de datos vectoriales, APIs de monitorización, sistemas de facturación. Si tu sistema tiene una API, probablemente ya existe un MCP server para él o puedes construir uno siguiendo la especificación pública en horas.

Los frameworks de agentes más usados han añadido soporte nativo para MCP. LangChain, LangGraph, LlamaIndex y crewAI ya permiten conectar MCP servers directamente en sus pipelines de orquestación. Esto significa que si ya tienes agentes construidos con alguno de estos frameworks, puedes empezar a usar MCP sin cambiar tu arquitectura de orquestación — solo añades los servers que necesitas.

La adopción más significativa de cara a la consolidación del estándar: en 2025, OpenAI anunció soporte para MCP en sus herramientas de desarrollo, y plataformas como Cursor, Windsurf, Microsoft Copilot Studio y Postman ya tienen soporte de MCP client. Cuando el principal competidor de Anthropic adopta tu protocolo, el debate sobre si es "el estándar" queda resuelto.

¿Cómo se implementa un MCP server?

Implementar un MCP server propio no requiere expertise de bajo nivel en protocolos de red. Los SDKs oficiales — Python y TypeScript son los más maduros — abstraen toda la complejidad del protocolo y te permiten definir tus tools y resources con decoradores o funciones simples.

La estructura básica de un server tiene tres partes: defines qué tools expones (nombre, descripción, parámetros de entrada y salida con JSON Schema), defines qué resources ofreces (URIs y tipo de contenido), e implementas la lógica que ejecuta cada tool cuando el agente la invoca. El SDK gestiona el transporte, la serialización, la gestión de errores y el protocolo de handshake.

Para empresas con sistemas internos sin MCP server disponible — un ERP propietario, una base de datos legacy, un sistema de tickets custom — el camino es implementar un servidor propio que envuelva esa API interna y la exponga con la interfaz MCP estándar. Una vez hecho, cualquier agente que hable MCP puede usarlo, independientemente del framework o el modelo de IA.

El coste de implementación de un server básico está en el orden de días, no semanas. Y como el server es completamente independiente del agente, el equipo que gestiona el CRM puede construir y mantener su propio MCP server sin necesidad de entender cómo funciona el agente que lo va a usar — ni el equipo de IA necesita entender el CRM para poder consumirlo.

Preguntas frecuentes sobre MCP

¿Quién creó MCP? Anthropic, la empresa detrás del modelo de IA Claude. Lo publicaron en noviembre de 2024 como open-source sin restricciones. Los autores principales son David Soria Parra y Justin Spahr-Summers. Hoy es un estándar abierto gestionado por la comunidad, no un producto propietario de Anthropic.

¿MCP funciona solo con Claude? No. MCP es un estándar agnóstico de modelo. Funciona con cualquier LLM que tenga soporte para MCP: GPT de OpenAI, Gemini de Google, modelos open-source como Llama o Mistral, y cualquier modelo que elijas usar en el futuro. Anthropic lo creó, pero no lo controla en exclusiva — y esa es precisamente su fortaleza.

¿MCP reemplaza las APIs REST? No. MCP es una capa que se construye encima de las APIs existentes, no un reemplazo. Un MCP server internamente puede llamar a cualquier API REST, GraphQL o sistema propietario. La diferencia es que el agente ve siempre una interfaz MCP estandarizada, no la API subyacente directamente.

¿Es lo mismo MCP que function calling? No exactamente. Function calling es el mecanismo por el que un LLM declara que quiere invocar una función. MCP estandariza cómo esas funciones se describen, se descubren y se ejecutan, independientemente del modelo que las use. MCP se apoya en function calling como mecanismo de invocación, pero añade la capa de descubrimiento dinámico, gestión de sesión y transporte que function calling no tiene.

¿MCP es seguro para datos sensibles? El protocolo incluye requisitos explícitos de seguridad: TLS obligatorio para transportes remotos, autenticación en cada server, permisos granulares por tool, validación de inputs con JSON Schema y logging de auditoría obligatorio. La seguridad real depende de cómo implementes cada server — el protocolo da las herramientas, pero el equipo tiene que usarlas correctamente en cada despliegue.

¿Qué diferencia hay entre MCP y RAG? Son complementarios, no alternativos. RAG (Retrieval-Augmented Generation) es una técnica para dar al modelo acceso a una base de conocimiento indexada mediante embeddings. MCP es un protocolo de integración que puede usarse para conectar el agente con un sistema RAG, pero también con CRMs, APIs, bases de datos transaccionales y cualquier otra herramienta. MCP puede ser el canal a través del cual el agente accede al sistema RAG — no un reemplazo de él.

MCP es infraestructura, no magia

La IA de los próximos años no va a ser solo modelos más grandes o más inteligentes. Va a ser modelos conectados a contexto real, en tiempo real, de forma segura y sin fricciones de integración. MCP es la infraestructura que hace posible ese escenario — la misma pieza que HTTP fue para la web o TCP/IP para internet.

Para las empresas que ya están explorando cómo los agentes de IA pueden transformar su atención al cliente, entender MCP no es opcional: es la diferencia entre construir sobre arena — conectores frágiles, deuda técnica de integración, dependencia de las decisiones de cada proveedor de API — y construir sobre una base que escala con el negocio.

El protocolo ya está adoptado por los principales actores del sector. Los servidores para los sistemas más usados ya existen y son mantenidos por la comunidad. El momento de empezar a construir con MCP es ahora, mientras el SERP en español todavía está prácticamente vacío y tu competencia aún no lo ha visto.

Si estás evaluando cómo integrar agentes de IA en tus procesos de negocio sin endeudarte técnicamente en el camino, hablemos.