Si encontró esto buscando "qué es MCP" o "model context protocol JSON-RPC", probablemente se encuentre en una de dos situaciones. O ha leído cuatro artículos sobre MCP y aún no puede explicar en una frase qué hace realmente, o algo en su cadena de herramientas de IA se está comportando de forma extraña y alguien mencionó MCP como la causa. Ambas situaciones lo traen aquí.
MCP se describe como muchas cosas: un marco de trabajo, una plataforma, un conector de IA, una forma de dar herramientas a los LLM. La mayoría de estas descripciones son técnicamente cercanas a la verdad, pero no explican en absoluto el mecanismo. MCP es una especificación de protocolo de comunicación: un conjunto definido de reglas sobre cómo se comunican entre sí una aplicación de IA y un servidor que proporciona herramientas. Funciona sobre JSON-RPC 2.0. Eso es todo. Todo lo demás es lo que usted construye sobre él.
La afirmación verificable que defiende este artículo: MCP resuelve el problema de integración NxM al ofrecer a los LLM una forma estandarizada e independiente del transporte de acceder a herramientas y datos externos mediante un protocolo base definido construido sobre JSON-RPC 2.0; y funciona precisamente porque no reinventó la capa de mensajería desde cero.
Lo que la mayoría de las explicaciones omite por completo
- MCP es una especificación de protocolo construida sobre JSON-RPC 2.0, no una plataforma; entender esta diferencia cambia cómo se implementa.
- JSON Schema permite a los LLM saber qué argumentos acepta una herramienta antes de invocarla; si omite el esquema, tendrá confusión en tiempo de ejecución, no un error de compilación.
- La división cliente/servidor en MCP no es igual que en REST: ambas partes pueden iniciar solicitudes, algo que desconcierta a la mayoría de los desarrolladores la primera vez.
El problema que resuelve MCP: aislamiento de los LLM y el infierno de integración NxM
Antes de MCP, conectar un modelo de IA a una herramienta externa implicaba escribir una integración personalizada. Cada vez. Si tenía tres modelos de IA y cinco herramientas, potencialmente debía crear, mantener y actualizar 15 conectores distintos cada vez que algo cambiaba en cualquiera de los extremos. Ese es el problema NxM: N modelos multiplicados por M herramientas, y la matriz crece rápido.
Sigo viendo este patrón en soporte: los equipos ya habían integrado la misma lógica de lectura de archivos o consultas a bases de datos en tres agentes de IA diferentes porque no existía una forma estándar de compartirla. Un equipo tenía un conector en Python, otro tenía un envoltorio de TypeScript y un tercero usaba una solución alternativa basada en curl. Bases de código distintas, mismo resultado. Nadie reutilizaba nada porque nada se había diseñado para reutilizarse. El desarrollo y la depuración se realizaban de forma aislada en cada implementación.
La API de llamadas a funciones de OpenAI ayudó a reducir este problema específicamente para ChatGPT. Pero era propietaria: una solución para un host, no una especificación que otros modelos de IA pudieran adoptar. El ecosistema más amplio necesitaba algo diferente: un estándar que cualquier host pudiera implementar, que cualquier servidor de herramientas pudiera usar y que no exigiera código personalizado para cada emparejamiento.
MCP es la respuesta de Anthropic a eso. Publicado como una especificación abierta con SDK públicos, define una interfaz común: una interfaz de chat puede conectarse a un servidor MCP del mismo modo que lo hace cualquier otro host, siguiendo el mismo protocolo. Los modelos de IA de un lado y las herramientas del otro hablan un lenguaje compartido en lugar de uno hecho a medida. La matriz NxM se reduce a N+M.
Qué es el protocolo base en MCP y por qué JSON-RPC lo impulsa
Aquí es donde la mayoría de las explicaciones sobre MCP pierde a la gente. Describen lo que MCP permite hacer —dar herramientas a los LLM, leer recursos, usar plantillas de prompts—, pero omiten qué es mecánicamente. La especificación de MCP lo expresa de forma directa: todos los mensajes entre clientes y servidores MCP deben seguir la especificación JSON-RPC 2.0, utilizando los tipos de mensajes de solicitud, respuesta y notificación de JSON-RPC 2.0 como protocolo base.
No es un detalle. Es la arquitectura. MCP no es un nuevo formato de mensajería. Es un conjunto de reglas construido sobre uno existente y bien entendido. La especificación JSON-RPC 2.0 define un protocolo RPC sin estado, ligero e independiente del transporte que utiliza JSON como formato de datos. «Independiente del transporte» es la parte importante: a JSON-RPC no le importa si los mensajes se mueven mediante stdio, HTTP, WebSockets u otra cosa. MCP hereda directamente esa flexibilidad, por lo que el mismo servidor MCP puede comunicarse con un IDE local mediante stdin/stdout y con un servicio remoto en la nube mediante HTTP sin cambiar el formato de los mensajes.
MCP tampoco es un formato de herramientas propietario de Anthropic. El análisis de despliegues empresariales de Synvestable de 2026 estimó la adopción de MCP entre empresas del Fortune 500 en aproximadamente un 28 % dentro de los 18 meses posteriores a su disponibilidad; es una cifra indicativa más que exacta dada la divulgación parcial de datos, pero la señal direccional es clara: esta especificación está entrando en producción en organizaciones que no se estandarizan en nada específico de Anthropic. La razón es que la interoperabilidad basada en JSON-RPC es real, no lenguaje de marketing.
Piénselo así: MCP proporciona la especificación al ecosistema. JSON-RPC proporciona a MCP su gramática de mensajería. JSON Schema proporciona a cada llamada de herramienta su vocabulario. Estas tres capas son distintas, y confundirlas es donde comienza la mayor parte de la confusión de implementación.
Por qué JSON-RPC 2.0 y no REST o GraphQL
La respuesta honesta a esta pregunta suele ser «porque encaja mejor», lo cual no resulta satisfactorio hasta que entiende qué significa «encaja» en este contexto.
REST está orientado a recursos. Usted modela el mundo como sustantivos (endpoints) y verbos (métodos HTTP). Esto funciona bien para operaciones CRUD, pero resulta incómodo para algo como «invoque esta función con estos parámetros y devuélvame un resultado». JSON-RPC está orientado a acciones. Toda la API es un único endpoint y lo que se invoca es un método con nombre. Esto se ajusta perfectamente a «llame a esta herramienta con esta carga útil».
GraphQL resuelve un problema diferente: obtener datos estructurados de un grafo. Es potente para ese caso de uso. Aquí es excesivo.
Lo que hace especialmente útil a JSON-RPC 2.0 para MCP es el tipo de notificación. Una notificación es un mensaje JSON-RPC unidireccional: no requiere respuesta. MCP utiliza notificaciones para elementos como actualizaciones de progreso y señales de capacidades, donde el remitente no necesita esperar. JSON-RPC también admite enviar varias solicitudes en un lote, lo cual importa cuando un agente de IA necesita distribuir eficientemente varias llamadas a herramientas. REST no tiene equivalentes nativos para ninguno de estos patrones. JSON gestiona las cargas útiles en todo momento, manteniendo el formato coherente y analizable por cualquier lenguaje con una biblioteca JSON.
Cómo se integra JSON Schema en el protocolo
Este es el detalle que la mayoría de las explicaciones omite, y en realidad es la parte que hace que las herramientas MCP sean legibles por máquinas en lugar de simplemente accesibles por máquinas.
Cuando un servidor MCP expone una herramienta, no solo registra un nombre. Proporciona un esquema —concretamente, una definición JSON Schema— que describe qué entradas acepta la herramienta y qué forma deben tener. La especificación de MCP exige JSON Schema 2020-12 como dialecto predeterminado.
¿Por qué importa esto? Porque un LLM que llama a una herramienta no adivina los argumentos. Lee el esquema. El esquema es el contrato entre el servidor de herramientas y el LLM: «esta herramienta acepta un objeto con un campo obligatorio llamado query de tipo cadena, y un campo opcional llamado limit de tipo entero». El LLM puede construir una llamada válida automáticamente a partir de esa descripción. Sin el esquema, las herramientas disponibles son opacas: hay que indicarle a la IA cómo llamarlas mediante prompts en lugar de permitirle descubrirlo a través del protocolo.
Desde la perspectiva de soporte: los fallos de invocación de herramientas más comunes que veo son discrepancias de esquema en las que el LLM envía un objeto params que no coincide con lo declarado por el servidor. El error suele ser opaco porque la validación ocurre en el servidor y la respuesta solo dice «parámetros no válidos». Compruebe primero el esquema. Eso resuelve la ambigüedad antes de que comience la espiral de depuración.
Componentes principales de MCP: hosts, clientes y servidores
La terminología aquí desconcierta a la gente, incluso a quienes entienden bien REST y RPC. MCP usa las palabras «cliente» y «servidor» de formas relacionadas con sus significados habituales, pero no idénticas. Entender esto mal genera un modelo mental en el que el LLM es el cliente, lo que lleva a suposiciones incorrectas sobre dónde fallan las cosas cuando fallan.
Hay tres roles estructurales en MCP:
El host es la aplicación que el usuario está ejecutando realmente. Claude Desktop es un host. Cursor es un host. Una aplicación de IA personalizada que su equipo creó y que llama a un LLM es un host. El host es responsable de la experiencia del usuario y de gestionar el LLM. Contiene un cliente MCP.
El cliente MCP reside dentro del host. Es el gestor del protocolo: el componente que sabe hablar MCP y JSON-RPC, administra conexiones con uno o más servidores MCP, enruta solicitudes y entrega respuestas de vuelta al LLM. El error común es tratar el cliente MCP como pasivo, como un cliente HTTP simple que dispara solicitudes. No lo es. El cliente MCP gestiona el descubrimiento de capacidades y mantiene el estado de la sesión. El propio LLM no conoce los detalles del protocolo; ese es el trabajo del cliente.
El servidor MCP expone herramientas, recursos y prompts. No tiene que ser un servidor web en el sentido tradicional. Es un proceso que sabe recibir mensajes MCP JSON-RPC y responder a ellos. El servidor puede ser un subproceso local que se comunica mediante stdio o un servicio remoto detrás de un endpoint HTTP. Desde la perspectiva del cliente, el protocolo tiene el mismo aspecto en ambos casos.
La confusión que veo en soporte suele ser así: un desarrollador crea un servidor MCP, lo conecta a una aplicación de IA y luego se pregunta por qué el «cliente» —que ha identificado como la aplicación orientada al usuario— parece enviar solicitudes que el servidor no espera. La respuesta suele ser que el cliente MCP dentro del host es la contraparte real, y tiene su propia secuencia de inicialización y negociación de capacidades que debe ejecutarse antes de poder llamar a cualquier herramienta.
Ahí es donde suele empezar el ticket.
Qué expone realmente un servidor MCP
Un servidor MCP habla mediante tres primitivas. Solo tres. Ese es todo el vocabulario.
Las herramientas son funciones ejecutables. Reciben entradas, realizan una acción y devuelven resultados. «Busque en esta base de datos», «envíe este correo electrónico», «ejecute esta consulta»: todas son herramientas. El LLM las llama cuando necesita realizar una acción u obtener resultados calculados. Las herramientas definidas con JSON Schema se pueden descubrir automáticamente.
Los recursos son datos legibles. Archivos, registros de bases de datos, respuestas de API, valores de configuración: cualquier cosa que el LLM necesite leer pero que no necesite invocar como función. Los recursos son las fuentes de datos externas y las herramientas que proporcionan contexto sin requerir ejecución de funciones.
Los prompts son patrones de interacción con plantillas. Un prompt en MCP es una forma predefinida de estructurar una interacción: plantillas de prompts reutilizables que el host puede seleccionar y el LLM puede usar con parámetros específicos. Piense en ellos como iniciadores de conversación con nombre y espacios para variables. Un prompt podría ser «resuma este documento» con un parámetro de documento, expuesto por el servidor para que el host pueda ofrecerlo como una opción seleccionable por el usuario.
Ese es el conjunto completo. Todo servidor MCP que encuentre expone alguna combinación de estos tres elementos. Antes de crear o depurar un servidor MCP, la primera pregunta siempre es: ¿qué primitivas proporciona realmente y están declaradas correctamente?
De qué son responsables los clientes MCP
Los clientes MCP no son pasivos. Este es el detalle de implementación que afecta a la mayoría de los desarrolladores que crean su primera aplicación conectada a MCP.
El cliente reside dentro del host y administra la conexión con uno o más servidores MCP. Gestiona el proceso de descubrimiento de capacidades: durante la inicialización, el cliente pregunta al servidor qué admite, y el servidor responde con su lista de herramientas, recursos y prompts disponibles. A partir de ese momento, el cliente sabe a qué puede llamar el LLM. El propio LLM no interroga directamente al servidor; el cliente mantiene ese estado en su nombre.
Los clientes también son responsables de la gestión del ciclo de vida: establecer la conexión, mantener la sesión y manejar la desconexión. Si el servidor se cae a mitad de sesión, el cliente debe decidir qué hacer: mostrar un error, intentar reconectarse o fallar de forma controlada mediante el manejo de errores del host. La mayoría de las implementaciones iniciales de MCP omiten la lógica de ciclo de vida y descubren esta carencia la primera vez que un proceso de servidor finaliza inesperadamente.
Otra responsabilidad del cliente que a menudo no se menciona: en MCP, el servidor también puede enviar solicitudes al cliente. Este es uno de los puntos en los que MCP difiere de un modelo mental REST simple. La negociación de capacidades es bidireccional. El cliente debe implementarse para recibir, no solo para enviar. A nivel arquitectónico, esto añade una complejidad que los desarrolladores de REST no esperan la primera vez que leen la especificación.
Cómo encaja la autenticación en la conexión MCP
Respuesta corta: MCP no gestiona la autenticación por usted. El protocolo base la delega por completo a la capa de transporte o de aplicación.
Esta es la suposición que provoca más brechas de seguridad en los despliegues de MCP. Los equipos leen la especificación de MCP, implementan un servidor, conectan un cliente y siguen adelante, sin añadir realmente autenticación. El protocolo funciona correctamente. El servidor queda silenciosamente abierto a cualquier proceso que pueda alcanzarlo.
Lo que MCP indica es que los servidores son de código abierto y que la autenticación debe gestionarse mediante la implementación, no mediante el protocolo en sí. Para conexiones stdio locales, a menudo no se requiere autenticación porque solo los procesos locales pueden alcanzar el servidor de todos modos. Para servidores MCP remotos mediante HTTP, la autenticación normalmente implica OAuth en la capa de transporte o validación de claves API en el manejo HTTP del servidor. Nada de esto es automático. Ambos requieren una implementación explícita.
Si está exponiendo un servidor MCP mediante HTTP y no ha configurado explícitamente la autenticación, considere que ese servidor es público hasta que lo haga.
Mecanismos de transporte: cómo se mueven realmente los mensajes MCP
MCP especifica el formato de los mensajes —JSON-RPC sobre JSON—, pero no impone cómo viajan esos mensajes entre cliente y servidor. De eso se encarga la capa de transporte. Hay dos opciones principales, y elegir la incorrecta para su configuración es uno de los errores más comunes de una primera implementación.
La elección no es arbitraria. Depende de si su cliente y servidor se ejecutan en la misma máquina, en la misma red o en algún punto a través de internet. Depende de la configuración de sus proxies y balanceadores de carga. También depende de cuánta latencia puede tolerar. La mayoría de las guías no menciona este último aspecto, razón por la cual los equipos usan HTTP para todo y luego se preguntan por qué las llamadas locales a herramientas resultan lentas.
MCP y su capa de mensajería JSON-RPC funcionan de la misma manera independientemente del transporte. Una llamada a herramienta tiene un formato de mensaje idéntico, tanto si viaja por stdin como por HTTP. El transporte es simplemente la tubería. Lo que cambia es qué tuberías están disponibles y qué falla cuando están mal configuradas.
🤔 Espere.
¿Qué sucede con las solicitudes MCP en curso cuando la conexión de transporte se interrumpe a mitad de sesión? La mayoría de las explicaciones de MCP describe la inicialización y las llamadas a herramientas en la ruta ideal, pero una interrupción de conexión durante una ejecución de agente de varios pasos es un escenario operativo real. MCP no define por sí mismo la semántica de reconexión: eso corresponde a la implementación. Si su cliente MCP no gestiona explícitamente la reconexión, las conexiones interrumpidas generan fallos silenciosos: el LLM deja de recibir resultados de herramientas, el host puede no mostrar un error y el usuario ve una respuesta bloqueada o incompleta sin una señal clara del motivo.
Transporte stdio: cuándo tiene sentido la comunicación entre procesos locales
Stdio es el camino más sencillo. El cliente MCP inicia el servidor como un subproceso y se comunica mediante stdin y stdout usando mensajes JSON-RPC. El cliente escribe en stdin del servidor. El servidor escribe las respuestas en stdout. Esa es toda la capa de transporte.
Esta configuración tiene menor latencia que HTTP para llamadas a herramientas locales porque no interviene ninguna pila de red ni sobrecarga de handshake más allá de la inicialización MCP. Es el valor predeterminado para herramientas como Claude Desktop y Cursor, donde el servidor MCP reside en la misma máquina que la aplicación host.
La limitación práctica es obvia: stdio solo funciona cuando cliente y servidor se ejecutan en la misma máquina. Sin excepciones. Si su servidor MCP debe compartirse entre varios hosts o reside en una máquina remota, stdio no es una opción. Esto cubre de forma eficaz la mayoría de los casos de IDE locales y asistentes de escritorio, que es exactamente para lo que fue diseñado.
Transporte HTTP más SSE: qué aporta y dónde falla
HTTP con SSE (eventos enviados por el servidor) es el transporte apto para conexiones remotas. El servidor expone un endpoint HTTP. El cliente abre un flujo SSE para mensajes de servidor a cliente. Las solicitudes HTTP POST gestionan las llamadas de cliente a servidor. Esta combinación proporciona comunicación bidireccional sobre infraestructura HTTP estándar, lo que necesita cualquier servidor MCP que no se ejecute localmente.
La variante más reciente de «HTTP transmisible» consolida parte de esto, pero se mantiene el patrón principal: una dirección mediante SSE y la otra mediante POST.
La fricción real es la compatibilidad con SSE. No todos los proxies, balanceadores de carga y gateways de API manejan correctamente SSE. Algunos terminan conexiones de larga duración. Algunos almacenan en búfer las respuestas y rompen la semántica de transmisión que SSE requiere. En entornos de producción con Nginx, AWS API Gateway o proxies corporativos en la cadena, esto provoca fallos silenciosos: la conexión SSE del cliente se interrumpe, la cola de mensajes de servidor a cliente se acumula y nada en los registros de la aplicación indica la causa. Desde el lado del LLM se observa una llamada a herramienta bloqueada y desde el lado de la infraestructura no se aprecia nada evidente.
Si su servidor MCP HTTP+SSE funciona localmente pero falla en staging, compruebe la configuración del proxy y del balanceador de carga antes de depurar la implementación de MCP. Eso resuelve la mayoría de estos casos más rápido que cualquier otra cosa.
Cómo es el ciclo de vida de MCP en la práctica
Leer la especificación de MCP como un documento estático omite algo importante: MCP describe una sesión activa con una secuencia definida de pasos. Dos sistemas deben realizar un handshake, negociar y establecer un entendimiento mutuo antes de llamar a cualquier herramienta. Comprender esa secuencia es lo que separa «he leído sobre MCP» de «puedo crear soluciones con MCP».
El flujo desde la primera conexión hasta el primer resultado de herramienta tiene tres fases reales: inicialización y negociación de capacidades, luego la llamada a herramienta propiamente dicha —o lectura de recurso, u obtención de prompt— y después el manejo de la respuesta. Los sistemas de IA construidos sobre MCP dependen de que esta secuencia se ejecute correctamente. Si la negociación de capacidades produce una discrepancia, la llamada a la herramienta nunca llega a intentarse. Si la llamada a herramienta produce un objeto params malformado, el servidor lo rechaza antes de que se ejecute cualquier lógica de negocio. Las aplicaciones de IA conscientes del contexto necesitan que las tres fases funcionen correctamente.
Negociación de capacidades durante la inicialización
Cuando un cliente MCP se conecta a un servidor por primera vez, después de establecerse la conexión de transporte, ambas partes intercambian un handshake. El cliente envía una solicitud initialize que incluye la versión de protocolo que admite y sus propias capacidades. El servidor responde con la versión de protocolo que admite y sus capacidades. Si las versiones coinciden —o se acuerda una versión negociada aceptable—, la sesión continúa. Si no coinciden, aquí es donde aparece la discrepancia: no a mitad del flujo, ni dentro de una llamada a herramienta, sino aquí mismo durante la inicialización.
En realidad, esto es útil. Que las discrepancias de versión aparezcan en el momento del handshake en lugar de durante la ejecución significa que usted sabe inmediatamente cuándo un servidor ejecuta una versión de protocolo obsoleta que su cliente no admite. La respuesta initialize también incluye el identificador de las herramientas, recursos y prompts disponibles en el servidor. El cliente construye su conocimiento de las capacidades del servidor a partir de esta respuesta antes de emitir una llamada a herramienta.
Si configura mal la secuencia de inicialización, todo lo posterior falla silenciosamente o con errores confusos. Es lo primero que reviso cuando alguien me dice que su integración MCP «no funciona».
Cómo se mueve una llamada a herramienta por el protocolo
Después de una inicialización correcta, una invocación de herramienta es un único ciclo de solicitud/respuesta JSON-RPC. El cliente envía una solicitud con un nombre de método correspondiente a la herramienta, un ID de solicitud único y un objeto params con la estructura definida por la declaración JSON Schema de la herramienta. El servidor valida los params contra el esquema, ejecuta la herramienta y devuelve un resultado JSON estructurado con el mismo ID de solicitud.
El paso de validación de params es fundamental. Un objeto params malformado —un campo obligatorio ausente, un tipo incorrecto, una clave inesperada que el esquema no define— devuelve un error JSON-RPC antes de ejecutar cualquier lógica de negocio. Desde la perspectiva del servidor, ese es el comportamiento correcto. Desde la perspectiva del LLM, recibir un código de error donde esperaba contexto adicional produce confusión que se manifiesta como respuestas alucinadas o incompletas más adelante.
Este es exactamente el escenario del trabajo de ingeniería de Latenode: cuando los ingenieros conectan servidores MCP a sistemas internos y encuentran errores opacos de validación JSON-RPC, el problema suele ser una discrepancia de esquema: el agente de IA construye un objeto params que no coincide con lo declarado por el servidor. En un flujo de Latenode, un nodo JavaScript puede gestionar la estructuración de parámetros en línea antes de que la solicitud llegue al servidor, mientras que el RAG integrado permite a un nodo de IA leer la especificación oficial de MCP para validar la estructura de la carga útil. La corrección ocurre a nivel del lienzo, no en un seguimiento de pila a las 23:00. Se aplican los códigos de error estándar: -32600 es solicitud no válida, -32601 es método no encontrado y -32602 son params no válidos. Estos tres cubren la mayoría de los fallos de llamadas a herramientas.
Consideraciones de seguridad que la mayoría de las configuraciones MCP gestiona mal
La seguridad en MCP no depende de si el protocolo es seguro en sí mismo. El protocolo está bien especificado y la capa JSON-RPC es bien conocida. Los riesgos provienen de cómo se configura la exposición de herramientas, a qué pueden acceder esas herramientas y qué sucede cuando un componente comprometido o malicioso entra en la sesión.
Inyección de prompts mediante respuestas de herramientas
Un LLM que llama a una herramienta MCP confía en la respuesta de la herramienta como contexto adicional. Si hay una fuente de datos no confiable en algún lugar de la cadena —un resultado de búsqueda web, un archivo cargado por el usuario, una API de terceros—, una respuesta maliciosa puede inyectar instrucciones que redirijan el comportamiento del LLM. La mitigación consiste en sanitizar las salidas en la capa de herramientas y separar claramente los prompts de sistema confiables de los datos devueltos por herramientas. Trate las respuestas de herramientas como entradas no confiables, no como contexto privilegiado.
Exposición excesivamente permisiva de herramientas del servidor
Un servidor MCP que expone todas las funciones disponibles de forma predeterminada otorga al usuario final —y al LLM— acceso a todo lo que el servidor puede alcanzar. La mayoría de los equipos expone lo que es conveniente, no lo que es necesario. Se aplica el principio de exposición mínima de herramientas: cada herramienta registrada debe tener un alcance definido, y las herramientas que acceden a sistemas sensibles deben requerir contexto explícito antes de poder invocarse. El aislamiento a nivel de herramienta —limitar qué puede leer, escribir o ejecutar una herramienta determinada— no es opcional en producción.
Ausencia de autenticación en servidores MCP remotos
Como se cubrió en la sección de transporte: MCP mediante HTTP sin capa de autenticación es un servidor abierto. Las API a las que se accede mediante esas herramientas quedan entonces disponibles para cualquiera que pueda alcanzar el endpoint. Exija autenticación en la capa de transporte o aplicación antes de que cualquier servidor MCP salga del desarrollo local. OAuth o validación de claves API mediante HTTP+SSE son opciones razonables. Ninguna es automática.
Falta de cifrado en la capa de transporte para HTTP+SSE
SSE mediante HTTP sin cifrar implica que todos los mensajes MCP —incluidas las llamadas a herramientas, los datos devueltos por recursos y cualquier metadato de sesión— viajan en texto claro. En entornos LAN esto puede ser aceptable. En cualquier entorno con tráfico externo, TLS es obligatorio. La especificación de MCP no lo exige. Su infraestructura debe hacerlo.
Envenenamiento de herramientas desde un servidor comprometido
Este es el modelo de amenaza en el que la mayoría de los equipos no piensa hasta que ocurre un incidente. Si uno de los servidores MCP registrados en una sesión se ve comprometido, el LLM no puede distinguir sus respuestas de las legítimas. Un servidor envenenado puede inyectar instrucciones en las respuestas de herramientas que influyan en el comportamiento del LLM durante toda la sesión, no solo en las llamadas realizadas a ese servidor. Cada servidor MCP registrado forma parte de la superficie de confianza del LLM. La pregunta no es «¿es segura esta herramienta?». Es «¿son seguros todos los servidores registrados?».
💡 La parte contraintuitiva:
La superficie de confianza de MCP no se limita a las herramientas que el usuario llama intencionadamente: se extiende a cada servidor registrado en la sesión. Un usuario que activa una llamada a herramienta está confiando implícitamente en los permisos y las salidas de todos los servidores MCP conectados, incluso de aquellos con los que nunca ha interactuado directamente. Esto replantea por completo la seguridad de MCP: no se trata de «¿es seguro este protocolo?», sino de «¿he auditado cada servidor al que puede acceder esta sesión?». La mayoría de los equipos no lo ha hecho.
MCP en la práctica: ecosistemas reales y hacia dónde va esto
La especificación importa más cuando se observa lo que se está construyendo sobre ella. GitHub ya cuenta con servidores MCP para operaciones de repositorio. Docker ha publicado herramientas MCP. El ecosistema de OpenAI está comenzando a converger con el estándar. Existen SDK de TypeScript y Python que el proyecto MCP mantiene activamente. Los desarrolladores que antes habrían escrito un conector personalizado para cada modelo de IA ahora pueden escribir un servidor MCP y exponerlo a cualquier host compatible.
Esa es la prueba práctica de si una especificación realmente resolvió el problema NxM: ¿las implementaciones se reutilizan entre proveedores de modelos y hosts, o los equipos siguen escribiendo código personalizado para cada emparejamiento? La evidencia de los primeros despliegues empresariales —por imprecisa que sea la cifra del 28 % del análisis de Synvestable— sugiere que la reutilización está ocurriendo a una escala significativa, lo que significa que la especificación está cumpliendo su función.
Para los equipos que trabajan con Latenode, MCP Server Builder permite exponer un flujo de Latenode como un servidor MCP, invocable desde Claude Desktop, Cursor o cualquier otro host compatible con MCP. Los flujos detrás de ese servidor pueden utilizar más de 5.500 integraciones, ejecutar IA sobre documentos cargados mediante RAG integrado o ejecutar lógica personalizada en un nodo JavaScript. Los detalles del protocolo permanecen invisibles para quien llame a la herramienta. Desde el lado del llamador, es simplemente una herramienta que descubrió durante la negociación de capacidades. Desde su lado, es un flujo de automatización completo.
La especificación MCP define la interfaz. Lo que usted coloque al otro lado de esa interfaz depende de usted.
Si está creando algo que necesita seguir funcionando cuando las cosas salen mal: implemente primero el manejo del ciclo de vida, no las herramientas. Añada registros en la capa de transporte. Valide sus declaraciones JSON Schema con cargas útiles de prueba reales antes de conectar un LLM. Y recuerde que cada servidor MCP que registre forma parte de su superficie de confianza desde el momento en que se completa el handshake.
El protocolo es limpio. La parte difícil, como de costumbre, es todo lo que lo rodea.
