Fundamentos de MCP: Anfitriones, clientes, servidores y el formato de transmisión JSON-RPC

Los modelos de lenguaje se volvieron realmente útiles para las empresas en el momento en que pudieron actuar, no solo responder. La parte difícil nunca ha sido el modelo en sí; ha sido conectarlo a las bases de datos, APIs y herramientas internas donde realmente se realiza el trabajo, y hacer esa conexión una sola vez en lugar de cada vez que se utiliza una aplicación o cada vez que se cambia el proveedor del modelo. El Protocolo de Contexto de Modelo (MCP) es un intento por estandarizar esa conexión. Este artículo explica el problema que resuelve MCP, las funciones de sus componentes, qué se transmite a través de la red y cómo difieren los dos métodos de transporte estándar, para que pueda determinar dónde encaja un servidor MCP en su propia arquitectura.

Dónde crean valor los LLM: al tomar acciones

Hasta hace poco, gran parte de la automatización estaba fuera del alcance simplemente porque el software no podía interpretar solicitudes con estructura flexible. Los modelos de lenguaje eliminan esa barrera, y una vez conectados a herramientas, pueden gestionar flujos de trabajo de múltiples pasos que anteriormente requerían que una persona se moviera entre sistemas.

Imaginemos a un asistente al que se le pide encontrar y reservar un tren de Casablanca a Rabat. Comprender la solicitud es solo el primer paso. El asistente debe buscar en un servicio de horarios, elegir una salida, llamar a una API de reservas y confirmar el resultado. Cada uno de esos pasos representa una llamada a una herramienta. Cuando las herramientas están expuestas a través de un servidor MCP, cualquier agente compatible puede llevar a cabo todo el proceso.

La lógica empresarial es clara: menos pasos manuales por tarea implica menores costos operativos y tiempos de respuesta más rápidos. También existe un argumento relacionado con la experiencia del usuario. Los empleados manejan habitualmente numerosos paneles e interfaces, cada uno con su propia lógica. Una interfaz de tipo conversacional conectada a esos sistemas backend puede ocultar gran parte de esa complejidad detrás de una sola interfaz.

El problema de integración que aborda MCP

El uso de herramientas no es algo nuevo. Cada SDK importante para LLMs lo soporta, pero cada uno lo hace con sus propias convenciones para declarar una herramienta, describir parámetros y devolver resultados. El resultado práctico es que la misma herramienta se implementa varias veces, una vez por cada proveedor de modelos. Cambiar de modelo o soportar dos al mismo tiempo implica reutilizar ese código de integración, lo que ralentiza a los equipos y dificulta la escalabilidad de los productos.

Omitir los SDKs no resuelve completamente este problema. Puede crear su propio nivel de integración que asocie las intenciones con acciones, llame a los puntos finales, recopile parámetros, maneje errores y registre datos analíticos. Eso añade complejidad, pero es manejable. El problema real radica en que dicho nivel de integración suele encontrarse dentro de una sola aplicación. Cuando otra aplicación necesita las mismas herramientas, el equipo debe volver a construir ese mismo nivel de integración. La lógica de integración queda vinculada al consumidor en lugar del sistema que posee la capacidad correspondiente.

Qué es MCP

MCP es un estándar abierto que proporciona a las aplicaciones de IA una forma común de conectarse a fuentes de datos y herramientas. No permite hacer algo que antes fuera estrictamente imposible; simplemente hace que esas conexiones sean más sencillas y consistentes. La documentación del protocolo en modelcontextprotocol.io es la referencia oficial.

El cambio clave radica en dónde reside la lógica de las herramientas. Con MCP, un servicio backend como una base de datos, una API o una herramienta interna publica sus capacidades a través de un servidor MCP. La analogía que se utiliza con frecuencia es un puerto USB-C: el servicio expone un socket estándar, y cualquier aplicación compatible puede conectarse a él. La aplicación de IA ya no contiene el conocimiento sobre cómo usar cada herramienta; solo necesita conocer el protocolo.

La arquitectura: hosts, clientes y servidores

MCP emplea una arquitectura cliente-servidor con tres roles que son fáciles de confundir:

• Host: la propia aplicación de IA, por ejemplo un asistente de chat, un IDE con un agente o su propio servicio de agente. Es con lo que interactúa el usuario, y se conecta al mundo exterior a través de uno o más servidores MCP.

Cliente: un componente dentro del anfitrión que establece y mantiene la conexión con un único servidor MCP. Este es el “conector” en la analogía USB-C.

Servidor: un programa que ofrece capacidades a los clientes de manera estandarizada.

El anfitrión nunca se comunica directamente con un servidor. Crea un cliente por cada servidor y delega toda la comunicación a él; además, cada cliente mantiene una conexión uno-a-uno dedicada. Esta separación es útil en la práctica: un anfitrión conectado a un servidor de sistema de archivos, un servidor de tickets y un servidor CRM ejecuta tres clientes independientes, de modo que una falla o restricción en una conexión no afecte a las demás.

Las tres primitivas de servidor

Las primitivas definen qué puede ofrecer cada lado. Un servidor expone tres tipos principales:

• Herramientas: operaciones que el modelo puede ejecutar, como llamar a una API o escribir un registro.
• Recursos: datos que el modelo puede leer y utilizar como contexto, como filas de base de datos o documentos.
• Prompts: plantillas de instrucciones predefinidas que guían al modelo, similares en esencia a los prompts reutilizables del sistema.

La distinción entre herramientas y recursos es importante para la seguridad y el diseño. Leer un recurso no debe tener efectos secundarios, mientras que invocar una herramienta puede cambiar el estado del sistema; por eso los hosts suelen aplicar reglas de aprobación diferentes para cada uno.

JSON y JSON-RPC: el formato de los mensajes

JSON (Notación de Objetos de JavaScript) representa datos estructurados como texto formado por pares clave-valor, arrays y objetos anidados. Dado que el formato es sencillo y está ampliamente soportado, un remitente y un receptor escritos en diferentes lenguajes pueden ponerse de acuerdo sobre el significado de un mensaje.

JSON-RPC se basa en esto al definir una estructura fija para las llamadas a procedimientos remotos. Una solicitud indica un método, incluye parámetros y contiene un identificador; si ambas partes respetan dicha estructura, el cliente puede pedir al servidor que ejecute un método y recibir el resultado, o un error, en un formato igualmente predecible. El ejemplo a continuación es una solicitud JSON-RPC 2.0 que pide al servidor realizar una búsqueda meteorológica para Casablanca. Observe los cuatro campos: la versión del protocolo, un id de solicitud utilizado para asociarlo con la respuesta, el nombre del methodo y el objeto params.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "get_weather",
  "params": {
     "city": "Casablanca"
   }
}

Este ejemplo ilustra JSON-RPC puro. En MCP, las herramientas no se invocan como métodos de nivel superior cuyo nombre corresponde al nombre de la herramienta. En su lugar, el cliente envía una solicitud con el método tools/call, colocando el nombre de la herramienta y sus argumentos dentro de params. Esa indirección es lo que permite a MCP definir un vocabulario fijo de métodos del protocolo, mientras que los servidores pueden exponer las herramientas que deseen.

El descubrimiento es la pieza que falta

JSON-RPC, por sí solo, deja un problema sin resolver: el cliente debe saber de antemano qué métodos ofrece el servidor. MCP cierra esa brecha al estandarizar la forma en que los clientes descubren las capacidades disponibles. Un cliente puede solicitar al servidor que enumere sus herramientas, recursos y comandos, recibiendo nombres, descripciones y esquemas de entrada, para luego pasar esas descripciones al modelo. MCP también especifica cómo se inicializa la conexión y qué mecanismos de transporte transportan los mensajes.

Mecanismos de transporte: cómo viajan los mensajes

JSON-RPC define el vocabulario; el transporte define cómo se transfieren los bytes entre el cliente y el servidor. En el momento de redactar este texto, MCP especifica dos mecanismos de transporte estándar. Consulte la especificación actual antes de confiar en los detalles, ya que el protocolo sigue evolucionando.

stdio para herramientas locales

Con el transporte stdio, el cliente inicia al servidor MCP como un proceso hijo. El servidor lee los mensajes entrantes desde su entrada estándar y escribe las respuestas en su salida estándar. Cada proceso recibe automáticamente estos canales del sistema operativo, por lo que no se requieren sockets de red ni puertos.

Esto hace que stdio sea una opción ideal para herramientas que se ejecutan en la misma máquina que el host, como por ejemplo un servidor que crea carpetas en el sistema de archivos local. Una ventaja adicional es la aislación: el servidor solo existe mientras el host lo mantiene en ejecución y no es accesible desde la red.

Streamable HTTP para servidores remotos compartidos

Con Streamable HTTP, el servidor es un proceso independiente que funciona como servicio HTTP y puede atender a muchos clientes al mismo tiempo. Los mensajes se intercambian mediante solicitudes HTTP habituales.

Este transporte permite la transmisión en flujo. En lugar de esperar una respuesta completa, el servidor puede enviar datos de forma progresiva, lo cual es útil para llamadas a herramientas que duran mucho tiempo. La transmisión en flujo se logra mediante Eventos Enviados por el Servidor (SSE), un canal unidireccional en el que una respuesta HTTP de larga duración contiene una secuencia de eventos enviados por el servidor. El tráfico en la dirección opuesta sigue saliendo como solicitudes HTTP normales desde el cliente. El comportamiento detallado depende de la implementación y de la versión HTTP utilizada.

Una regla práctica: elige stdio cuando la herramienta está en la máquina de un único usuario, y elige Streamable HTTP cuando se debe compartir una funcionalidad entre usuarios o equipos, con los controles de autenticación y red que requieren los servicios compartidos.

Por qué un protocolo es más importante que otro SDK

Existen protocolos para que los sistemas desarrollados por diferentes equipos, en lenguajes distintos y con horarios de lanzamiento variados, puedan seguir interactuando de manera predecible. Un protocolo es un conjunto acordado de reglas que determinan cómo se comunican los componentes independientes, interpretan sus mensajes mutuos y establecen confianza entre sí.

El valor de estandarizar el acceso a las herramientas es principalmente económico. Cuando el costo de integración de un nuevo modelo o aplicación se acerca a cero, experimentar se vuelve económico, y los experimentos económicos permiten iteraciones más rápidas. El equipo encargado de un sistema puede publicar un servidor MCP, y todas las aplicaciones de IA actuales y futuras de la organización pueden utilizarlo sin necesidad de código especializado. Para conocer cómo funciona esto dentro de un marco de agentes, consulte nuestro artículo sobre estandarizar la integración de herramientas en LangGraph con MCP.

Puntos clave

• Los LLMs brindan el mayor valor cuando pueden operar en sistemas reales, y el cuello de botella es la integración, no la inteligencia.
• Sin un estándar, la misma herramienta se implementa de nuevo para cada SDK del modelo y para cada aplicación; MCP traslada esa lógica a un servidor propiedad del sistema que proporciona la funcionalidad.
• Un host ejecuta un cliente por servidor, y cada cliente mantiene una conexión dedicada; los servidores ofrecen herramientas, recursos e instrucciones.
• JSON-RPC define la estructura de los mensajes, mientras que MCP agrega un vocabulario fijo de métodos, como tools/call, además de la capacidad de descubrimiento de funcionalidades.
• Utilice stdio para herramientas locales de un solo usuario y Streamable HTTP para servicios remotos compartidos, y verifique los detalles del transporte según la especificación actual.

Lecturas relacionadas

• MCP sin estado: Escalado de servidores sin sesiones ni interacciones — Cómo un protocolo de contexto de modelo sin estado elimina las sesiones y las interacciones, y cómo los _meta, las solicitudes de múltiples rondas, los encabezados de enrutamiento, el caché y las tareas mantienen su utilidad.
• AI agente explicada: De los modelos de lenguaje a los agentes autónomos — Una explicación estructurada de cómo los LLM se transforman en sistemas agentes a través de herramientas, memoria, planificación, arquitecturas multiagente e integración con MCP.