Hola, soy Lena. Algo se sentía un poco extraño la primera vez que intenté explicar MCP a alguien.
Seguí diciendo "conecta tu IA con herramientas" — y eso es técnicamente cierto, pero no capturaba lo que realmente estaba pasando por debajo. La persona con la que hablaba asintió, luego preguntó: "¿entonces es como un plugin?" Y yo hice una pausa. Porque tampoco es exactamente eso.
Ese vacío — entre "sé que funciona" y "entiendo cómo funciona" — es con lo que quiero quedarme aquí. No como un desglose técnico formal, sino como un paseo lento a través de lo que he observado sobre cómo los servidores MCP realmente se comportan.
El Problema que MCP Fue Construido para Resolver
Por qué cada integración modelo-herramienta solía ser personalizada
Antes de que existiera MCP, conectar un modelo de lenguaje a una herramienta externa significaba escribir una integración personalizada cada vez. GitHub tenía su propio formato. Las bases de datos tenían el suyo. Cada API era un proyecto separado.
No es que alguna integración individual fuera difícil. Era la acumulación — el hecho de que ninguna de ellas podía comunicarse entre sí, y el modelo no tenía una forma estándar de preguntar "¿qué puedo hacer aquí?" Cada conexión estaba hecha a mano.
Model Context Protocol es la respuesta de Anthropic a eso. Lanzado como código abierto en noviembre de 2024, introdujo un lenguaje compartido — un protocolo cliente-servidor estandarizado para que cualquier aplicación de IA pudiera conectarse a cualquier proveedor de herramientas sin cableado personalizado. A mediados de 2025, OpenAI y Google DeepMind lo habían adoptado. Desde entonces, ha pasado a estar bajo la Agentic AI Foundation, un proyecto de la Linux Foundation.
Ese movimiento importa un poco. Dejó de ser el estándar de una sola empresa y empezó a convertirse en algo más compartido. Aún no estoy completamente segura de qué cambia eso en la práctica, pero sigo notándolo.
Arquitectura MCP: Las Tres Partes Móviles
Cuando la gente pregunta cómo funcionan los servidores MCP, creo que el punto de inicio más claro es la estructura de tres partes. Cada pieza tiene un trabajo distinto, y la confusión generalmente viene de colapsarlas juntas.
Host MCP (la aplicación de IA)
El host es la aplicación que realmente estás usando — Cursor, Claude Desktop, VS Code con una extensión de IA. Es lo que el usuario ve e interactúa.
El host es un corredor de seguridad. Gestiona la ventana de contexto del modelo, decide qué herramientas están disponibles y controla lo que se envía de vuelta al LLM. No ejecuta llamadas a herramientas por sí mismo; solo regula el acceso. La mayoría de los desarrolladores nunca escriben la lógica del host a menos que estén construyendo una plataforma de agentes personalizada, pero entenderlo es importante porque el host es quien decide a qué puede y no puede acceder el modelo.
Cliente MCP (integrado en el host)
El cliente es creado por el host. Se sitúa entre el host y cada servidor MCP, gestionando la conexión. Normalmente hay un cliente MCP por cada servidor MCP, y cada uno mantiene su propia sesión dedicada.
El cliente maneja la negociación de capacidades, enruta los mensajes de ida y vuelta y abstrae los detalles del transporte. El host no necesita saber si un servidor funciona sobre stdio o HTTP. Eso es trabajo del cliente.
Servidor MCP (el proveedor de herramientas)
El servidor es donde se encuentran las capacidades reales. Expone herramientas, recursos y prompts, lo que haya sido construido para proporcionar. Un servidor GitHub MCP expone operaciones de repositorio. Un servidor de Postgres expone funciones de consulta. Cada servidor normalmente se enfoca en un dominio de integración.
Lo que me sorprendió al examinar esto más de cerca: un servidor es solo un programa. Puede ejecutarse localmente en la misma máquina que el host o de manera remota en algún lugar de Internet. El protocolo no cambia; solo cambia el transporte.
Cómo ocurre realmente una llamada a una herramienta
Esta es la parte que no entendía completamente hasta que la mapeé paso a paso.
Paso 1: El servidor anuncia las herramientas disponibles
Cuando el cliente se conecta por primera vez a un servidor, hay un handshake. El cliente envía una solicitud initialize. El servidor responde con su versión de protocolo y una lista de sus capacidades: qué herramientas ofrece, sus nombres, esquemas de entrada y descripciones. Esto se llama negociación de capacidades.
Luego, el cliente incorpora esas definiciones de herramientas en el prompt del sistema del modelo. Así es como el LLM sabe qué está disponible. No es magia; es solo contexto estructurado.
Paso 2: El modelo decide usar una herramienta
Cuando el modelo está procesando una solicitud y determina que una llamada a herramienta es adecuada, emite una llamada estructurada: el nombre de la herramienta y los argumentos que desea pasar. El modelo no llama a la herramienta directamente. Genera una instrucción estructurada, y el host la interpreta.
Paso 3: El cliente envía la llamada al servidor
El cliente toma esa llamada estructurada y la reenvía al servidor correcto como una solicitud tools/call a través de JSON-RPC 2.0. Este es el formato en la red: un diccionario con un nombre de método, parámetros y un ID único para correlación.
Paso 4: El servidor ejecuta y devuelve el resultado
El servidor ejecuta la función real: una consulta de base de datos, una llamada a API, la lectura de un archivo, lo que sea para lo que haya sido construido. Devuelve una respuesta estructurada. Si algo sale mal, devuelve un error tipado, no una excepción cruda. Los servidores bien construidos devuelven mensajes de error que realmente ayudan al modelo a entender qué falló y por qué, lo cual es importante para la recuperación.
Paso 5: El modelo incorpora el resultado
El resultado fluye de regreso a través del cliente y el host hacia el contexto del modelo. El modelo lo lee como parte de la conversación y continúa desde ahí.
…bien, creo que entiendo lo que está haciendo. Cada paso está deliberadamente separado. El modelo nunca toca la herramienta directamente. Siempre hay una capa intermedia.
Capa de transporte: cómo hablan los servidores y clientes
stdio (local) vs. HTTP/SSE (remoto)
Transporte stdio utiliza flujos de entrada y salida estándar. Cuando el host inicia un servidor MCP local como un subproceso —como ejecutar npx my-mcp-server— el cliente y el servidor se comunican escribiendo y leyendo de esos flujos. No hay red involucrada. Sin sobrecarga de latencia. Es rápido porque es comunicación de proceso a proceso en la misma máquina.
Transporte HTTP con streaming (el estándar actual para servidores remotos, especificado en la actualización del protocolo de marzo de 2025) utiliza HTTP POST para mensajes de cliente a servidor, con Eventos Enviados por el Servidor opcionales para respuestas en streaming. Esto es lo que usan los servidores remotos — alojados en una plataforma como Cloudflare o Vercel, sirviendo a muchos clientes simultáneamente.
Hay un formato HTTP+SSE más antiguo (de la especificación de noviembre de 2024) que requería dos endpoints separados. La nueva especificación de HTTP con streaming consolidó eso en un solo endpoint. Vale la pena saberlo si estás leyendo documentación antigua: los patrones cambiaron.
Qué significa esto para latencia y seguridad
Los servidores locales stdio son más rápidos y tienen una superficie de ataque menor. El único proceso que puede comunicarse con ellos es el host. Los servidores remotos introducen latencia de red y requieren autenticación. Una investigación en julio de 2025 encontró que casi 2,000 servidores MCP expuestos a internet no tenían ninguna autenticación — cualquiera podía acceder a la lista de herramientas. La actualización de la especificación de junio de 2025 abordó parte de esto clasificando los servidores MCP como Servidores de Recursos OAuth, pero la implementación sigue siendo inconsistente.
Ese detalle se quedó conmigo. El protocolo puede definir patrones de seguridad, pero no puede hacerlos cumplir. La documentación oficial de seguridad de MCP cubre las prácticas recomendadas, y vale la pena leerla antes de implementar cualquier cosa que maneje datos sensibles.
La capa que la mayoría de los desarrolladores pasa por alto
Qué sucede con una llamada a herramienta exitosa
Aquí está la parte que me confundió durante un tiempo: una llamada a herramienta exitosa no persiste nada por sí misma.
El resultado regresa al contexto del modelo para esa sesión. El modelo lo utiliza, genera una respuesta y sigue adelante. Pero el hecho de que se haya llamado a la herramienta —la ruta específica que tomó el modelo, los inputs que eligió, el resultado que obtuvo— vive solo en la ventana de la conversación. Cuando la sesión termina, desaparece.
El servidor MCP no acumula conocimiento. No mejora sus respuestas basadas en sesiones pasadas. Cada nueva conexión comienza desde el mismo estado inicial: el saludo, la lista de capacidades, hoja en blanco.
Por qué conexión ≠ persistencia de capacidades
Esto es a lo que me refiero cuando digo "conexión no es persistencia de capacidades".
Conectarse a un servidor MCP le da al modelo acceso a una herramienta. No le da al modelo la memoria de cómo utilizó esa herramienta anteriormente, ni qué funcionó, ni qué falló. El servidor expone las mismas capacidades en cada sesión, independientemente de lo que haya sucedido en sesiones anteriores.
Sigo pensando en esto. No es exactamente un defecto; es solo un límite de diseño. El protocolo maneja la comunicación y la ejecución. Lo que sucede con el resultado de esa ejecución —si se almacena, se aprende de él, se lleva adelante— es otra capa completamente diferente.
…podría haber más aquí. Seguiré pensando en esto.
Preguntas frecuentes
- ¿Qué es exactamente un servidor MCP?
Un servidor MCP es un programa ligero que expone herramientas, recursos e indicaciones a agentes de IA a través del Protocolo de Contexto del Modelo. Traduce solicitudes estructuradas de modelos de lenguaje en operaciones reales —consultas de base de datos, llamadas a API, lecturas de archivos— y devuelve los resultados en un formato estandarizado. Puede ejecutarse localmente en la misma máquina que la aplicación de IA, o remotamente a través de HTTP.
- ¿Qué protocolos de transporte usa MCP?
MCP admite dos mecanismos de transporte. Stdio utiliza flujos de entrada/salida estándar para la comunicación local, en la misma máquina: rápido, sin sobrecarga de red. HTTP transmitible (el estándar actual para servidores remotos) utiliza HTTP POST con Eventos Enviados por el Servidor opcionales para transmisión en vivo. Todos los mensajes usan JSON-RPC 2.0 como formato subyacente, sin importar qué transporte se esté usando.
- ¿Puede un servidor MCP llamar a otro servidor MCP?
El protocolo lo permite. Un cliente MCP puede mantener conexiones simultáneas a múltiples servidores al mismo tiempo: uno para una base de datos, otro para acceso a archivos, un tercero para una API externa, todo en la misma sesión. Lo que es menos común, y menos claramente definido en las implementaciones actuales, es que un servidor actúe como cliente de otro servidor. Ese patrón existe, pero añade complejidad y los límites de seguridad son más difíciles de interpretar.
El protocolo todavía se está formando. La especificación ya ha cambiado significativamente entre la versión de noviembre de 2024, la actualización de marzo de 2025 y lo que se usa activamente ahora. Cómo será la arquitectura en otra versión o dos — sinceramente no lo sé. Pero aprenderé más al respecto.
