¿Qué es un servidor MCP? Cómo funcionan MCP y MCP UI en 2026

El 1 de abril de 2025, Invariant Labs publicó una herramienta llamada add. Recibía dos números y devolvía su suma. Su descripción también llevaba un bloque marcado como IMPORTANT, invisible en la interfaz del cliente, que ordenaba al modelo leer ~/.cursor/mcp.json y ~/.ssh/id_rsa y sacar ambos archivos por un parámetro sobrante. El modelo obedeció. El usuario vio una suma.

Esa demostración es la mejor introducción a los servidores MCP que conozco, porque muestra las dos mitades a la vez. El protocolo funcionó exactamente como estaba diseñado: un cliente de IA descubrió una herramienta, leyó su descripción y la llamó. El modelo de confianza era la parte que nadie había construido todavía.

Qué es un servidor MCP

Un servidor MCP es un programa que expone herramientas, datos y prompts a aplicaciones de IA a través del Model Context Protocol (MCP). La documentación oficial define MCP como «un estándar de código abierto para conectar aplicaciones de IA con sistemas externos». Un cliente de IA como Claude, ChatGPT, Visual Studio Code o Cursor se conecta al servidor, le pregunta qué ofrece y usa esas capacidades en nombre del usuario.

Anthropic anunció MCP el 25 de noviembre de 2024 con seis servidores ya preparados: Google Drive, Slack, GitHub, Git, Postgres y Puppeteer. OpenAI lo adoptó en marzo de 2025. Google DeepMind lo siguió en abril. En diciembre de 2025, Anthropic donó el protocolo a la Agentic AI Foundation, un fondo dirigido bajo el paraguas de la Linux Foundation y cofundado por Anthropic, Block y OpenAI.

El problema que resuelve es la multiplicación. Antes de MCP, cada aplicación de IA que quería acceder a GitHub escribía su propio conector, y cada proveedor creaba una conexión por aplicación de IA. Diez modelos y diez herramientas podían significar hasta cien integraciones. MCP reduce ese número a veinte: cada cliente implementa el protocolo una vez y cada sistema expone un servidor.

Piénsalo como el contenedor marítimo de las integraciones de IA. Antes de los contenedores, cada puerto cargaba cada mercancía a mano, con sus propias grúas y su propia cuadrilla. El contenedor estandarizó la caja, de modo que cualquier barco, grúa o camión podía mover cualquier carga. No estandarizó lo que iba dentro de la caja, y nunca inspeccionó el contenido. MCP hace el mismo trato. Quédate con la segunda mitad, porque vuelve en la sección de seguridad.

Cómo funciona un servidor MCP

La especificación actual, versión 2026-07-28, usa mensajes JSON-RPC 2.0 entre tres roles. Su propia descripción ocupa tres líneas: los hosts son «aplicaciones LLM que inician conexiones», los clientes son «conectores dentro de la aplicación host» y los servidores son «servicios que proporcionan contexto y capacidades».

Host, cliente, servidor

El host es la aplicación en la que escribes: Claude Desktop, un IDE, tu propio agente. Dentro de él se ejecuta un cliente por cada conexión con un servidor. El servidor está al otro lado y habla con el sistema real, ya sea una base de datos Postgres, la API de GitHub o una carpeta de tu disco. El host decide qué ve el modelo y qué debe aprobar el usuario. El servidor decide qué hará el sistema subyacente.

1. Host Claude Desktop · un IDE · tu propio agente

   muestra las herramientas al modelo y pide el consentimiento del usuario

2. Cliente uno por conexión con un servidor

   habla JSON-RPC sobre stdio o Streamable HTTP

3. Servidor MCP herramientas · recursos · prompts

   describe lo que ofrece y ejecuta las llamadas

4. Sistema subyacente base de datos · API SaaS · archivos locales

   hace el trabajo

Herramientas, recursos y prompts

Un servidor puede ofrecer tres tipos de cosas:

• Herramientas: funciones que el modelo puede ejecutar, como create_issue, query_orders o send_email. Cada una tiene un nombre, una descripción y un JSON Schema para sus entradas.
• Recursos: contexto y datos que el usuario o el modelo pueden leer, como un archivo, un esquema de base de datos o un registro.
• Prompts: mensajes y flujos de trabajo con plantilla que el usuario puede elegir, por ejemplo «resume esta pull request».

Las herramientas se llevan casi toda la atención porque actúan. Por eso mismo concentran casi todo el riesgo.

Una llamada a una herramienta, paso a paso

La revisión 2026-07-28 hizo que MCP no tuviera estado. Ya no existe el saludo inicial initialize: cada petición lleva su versión de protocolo y las capacidades del cliente en un campo _meta, y los servidores deben implementar un método server/discover para que un cliente pueda preguntar de antemano qué admiten. Una llamada a una herramienta funciona ahora así:

1. El usuario pide: crea un ticket para este bug

2. Paso 1

   Descubrir

   • El cliente puede llamar a server/discover para conocer versiones y capacidades
3. Paso 2

   Listar herramientas

   • tools/list devuelve nombres, descripciones y esquemas de entrada
4. Paso 3

   El modelo elige una herramienta

   • El host pasa las definiciones de las herramientas al modelo
5. Paso 4

   Consentimiento del usuario

   • La especificación dice que los hosts deben obtener consentimiento explícito antes de invocar cualquier herramienta
6. Paso 5

   Llamada

   • tools/call con argumentos, versión de protocolo en _meta

7. ¿Falta información? El servidor devuelve input_required; el cliente reintenta con las respuestas

   Paso 6

   Resultado

8. El resultado vuelve al modelo como contexto

El paso 6 es nuevo en esta revisión. Un servidor que necesita más información ya no envía su propia petición de vuelta al cliente. Devuelve un resultado marcado como input_required, el cliente recoge la respuesta y reintenta la llamada original. La especificación llama a esto el patrón Multi Round-Trip Request.

Transportes: stdio y Streamable HTTP

La especificación define dos transportes estándar:

• stdio: el cliente lanza el servidor como subproceso e intercambia JSON-RPC delimitado por saltos de línea a través de la entrada y la salida estándar. Así funcionan la mayoría de los servidores locales, y significa que el servidor se ejecuta en tu máquina con tus privilegios.
• Streamable HTTP: cada mensaje es un HTTP POST a un único endpoint, y las respuestas vuelven como un objeto JSON o como un flujo de eventos limitado a esa petición. Así funcionan los servidores remotos alojados.

El antiguo transporte HTTP+SSE está oficialmente obsoleto. La revisión 2026-07-28 también eliminó las sesiones a nivel de protocolo y la cabecera Mcp-Session-Id. Un servidor que necesita mantener estado entre llamadas ahora genera su propio identificador y lo recibe de vuelta como un argumento normal de la herramienta.

Autorización

La autorización en MCP es opcional y solo se aplica a HTTP. Con stdio, la especificación dice que los servidores deben tomar las credenciales del entorno. Con HTTP, un servidor MCP protegido actúa como servidor de recursos OAuth 2.1. Debe publicar OAuth Protected Resource Metadata (RFC 9728) para que los clientes encuentren su servidor de autorización. Los clientes deben indicar el servidor exacto al que va destinado un token (indicadores de recurso de RFC 8707). Los servidores deben rechazar cualquier token que no se haya emitido para ellos, y la guía de seguridad declara explícitamente prohibido el “token passthrough”, es decir, reenviar sin cambios el token de un cliente a una API posterior.

Esa última regla importa más de lo que parece. Un servidor que reenvía cualquier token que recibe se convierte en un proxy para quien tenga uno.

Qué añade MCP UI: servidores que devuelven una interfaz

Las respuestas en texto dejan de servir en cuanto un usuario necesita comparar cuarenta filas, ajustar un formulario de doce campos o aprobar un lote de cambios uno por uno. “MCP UI” es el nombre con el que la gente busca la solución: un servidor devuelve una interfaz interactiva que se muestra dentro del cliente de IA, junto a la conversación.

Conviene precisar el estado del proyecto. La idea nació con MCP-UI, un proyecto comunitario. OpenAI incorporó un mecanismo parecido a su Apps SDK. El proyecto MCP propuso un estándar compartido con ambas iniciativas el 21 de noviembre de 2025 y publicó MCP Apps el 26 de enero de 2026 como primera extensión oficial de MCP. Los paquetes de MCP-UI ahora implementan ese estándar y siguen sirviendo para experimentar con mejoras futuras.

Así que hoy MCP UI significa MCP Apps. Es oficial, y es una extensión, no el núcleo del protocolo. Las extensiones son opcionales: tanto el cliente como el servidor deben admitirlas, y la documentación dice con claridad que «el soporte de los hosts varía según el cliente». La documentación de MCP Apps enumera Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam y Archestra.AI como hosts compatibles. Un servidor cuyas herramientas devuelven interfaz tiene que seguir funcionando con un cliente que solo muestra texto.

A nivel mecánico, reutiliza las propias piezas de MCP:

1. La descripción de una herramienta incluye un _meta.ui.resourceUri que apunta a un recurso ui://.
2. El host obtiene ese recurso, una página HTML con sus scripts, y puede precargarlo antes de que se llame a la herramienta.
3. El host lo muestra en un iframe aislado (sandbox) que no puede leer la página principal, sus cookies ni su almacenamiento.
4. La app y el host se comunican por postMessage en un dialecto JSON-RPC de MCP. La app puede solicitar llamadas a herramientas, y el host decide cuáles permite.

El coste es real. Ahora estás entregando un front-end web dentro de la aplicación de otro, con una política de seguridad de contenido que debes declarar, reglas de renderizado que no controlas y una alternativa en texto para cada host que la ignore. La ganancia es que el trabajo de aprobación deja de ser una transcripción de chat. La lista de buenos casos de uso de la documentación termina con «aprobar informes de gastos, revisar cambios de código o clasificar incidencias», y ese es el centro honesto del asunto: MCP UI brilla en las decisiones, no en la decoración.

Un ejemplo de Tajo de solo lectura

La interfaz Alto MCP de Tajo incluye query_contacts, que busca contactos guardados en el espacio conectado. Busca un contacto existente por correo y revisa el identificador devuelto, su estado de consentimiento por correo y la fecha de la última observación. La herramienta independiente get_contact_topic_status lee sus suscripciones por tema.

Son lecturas del espacio. No recuperan una copia actualizada del proveedor, no inician una sincronización ni envían mensajes. Tampoco demuestran que todos los conectores estén activos. Investiga en el origen los datos ausentes o desactualizados. Un resultado vacío no demuestra que la persona no exista en Brevo.

Usa la documentación MCP de Tajo para conectar un cliente compatible e inspeccionar las herramientas que realmente expone a tu espacio autorizado. Un panel interactivo puede facilitar la revisión si el anfitrión admite MCP Apps; el resultado textual también debe explicar lo ocurrido.

Una llamada a una herramienta no es una sincronización persistente

Una sincronización recurrente necesita además un horario, identidades estables, progreso guardado, decisiones de reintento y un registro de escrituras terminadas. Esas responsabilidades pertenecen a la aplicación que ejecuta el trabajo. MCP normaliza el acceso a herramientas; incluir una herramienta en una lista no aporta esas reglas de negocio.

Tras un tiempo de espera agotado, normalmente puedes repetir una lectura. Un envío o un pago podría haberse completado ya. Conserva el registro de ejecución y concilia el resultado antes de intentarlo otra vez. La confianza del modelo no autoriza la acción ni hace segura su repetición.

Para la escritura de destino de un recorrido concreto de contactos, consulta la guía de la API de Brevo. Para decidir cuándo los campos calculados necesitan una sincronización propia mantenida, consulta ETL inverso.

La factura de seguridad viene con el protocolo

La objeción merece plantearse completa: «MCP le da a un modelo probabilístico una lista de funciones que pueden borrar datos y enviar emails, y luego confía en textos escritos por desconocidos para describirlas. Eso no es un estándar de integración. Es un ataque a la cadena de suministro con especificación». Casi todo es cierto. La especificación comparte la premisa. Su sección de seguridad dice que las herramientas «representan ejecución de código arbitrario y deben tratarse con la debida precaución», que las descripciones de las herramientas «deben considerarse no fiables, salvo que procedan de un servidor de confianza», y que MCP «no puede hacer cumplir estos principios de seguridad a nivel de protocolo».

Este es el historial hasta ahora:

• Envenenamiento de herramientas (tool poisoning). La divulgación de Invariant Labs de abril de 2025, la herramienta add de arriba. El mismo artículo describía los rug pulls (literalmente, quitarte la alfombra), en los que un servidor cambia la descripción de una herramienta después de que la aprobaras, y el shadowing (suplantación en la sombra), en el que un servidor malicioso reescribe el comportamiento del modelo frente a otro servidor de confianza.
• Compromiso de servidores locales. En julio de 2025, JFrog divulgó CVE-2025-6514 en mcp-remote, versiones 0.0.5 a 0.1.15, que permitía a un servidor malicioso ejecutar comandos en la máquina del usuario. Ese mismo verano, CVE-2025-49596 afectó al propio MCP Inspector de Anthropic, que se distribuía sin autenticación por defecto.
• Inflación de scopes. Las buenas prácticas de seguridad oficiales describen el patrón: tokens que reciben files:* o admin:* desde el principio porque un servidor listó todos los scopes y el cliente los pidió todos.
• Preocupación oficial. En mayo de 2026, la National Security Agency de Estados Unidos afirmó que la «rápida proliferación» de MCP «ha superado el desarrollo de su modelo de seguridad».

Donde la objeción se equivoca es en la conclusión. La solución nunca fue dejar de conectar modelos a sistemas; los equipos ya lo hacían con claves de API en bruto pegadas en prompts y scripts, sin ningún rastro de auditoría. La solución es tratar un servidor MCP como cualquier otra dependencia privilegiada:

• Instala servidores solo de fuentes a las que confiarías las mismas credenciales fuera de MCP.
• Prefiere servidores remotos con OAuth y scopes acotados antes que binarios locales con claves de larga duración.
• Exige aprobación humana para cada escritura y registra quién aprobó qué.
• Fija las versiones de los servidores y vuelve a revisarlas cuando cambie la descripción de una herramienta.
• Expón herramientas pensadas para la tarea, no una API completa. Un modelo no puede abusar de un endpoint de borrado que nunca se expuso.

El protocolo estandarizó la caja. Inspeccionar la carga sigue siendo tu trabajo.

Crear un servidor MCP o usar uno existente

Directorios públicos como mcp.so catalogan servidores creados por la comunidad, y muchos proveedores SaaS publican los suyos. Brevo, por ejemplo, ofrece un servidor MCP que también está dividido en servidores individuales, de modo que se puede dar a un agente acceso a los contactos sin darle las campañas. La decisión tiene menos que ver con el esfuerzo que con quién debe decidir la forma de las herramientas.

¿Qué servidor MCP debería usar tu agente?

1. El proveedor publica un servidor que cubre la tarea

   Usa el servidor del proveedor

   Sigue la evolución de la API y el proveedor lo mantiene.

2. Un solo sistema, pero necesitas menos acciones o acciones más seguras

   Úsalo, con alcance reducido

   Concede scopes mínimos y expón solo los grupos de herramientas que el agente necesita.

3. Datos internos o un sistema sin servidor

   Crea un servidor pequeño

   Unas pocas herramientas pensadas para la tarea sobre tu propia API, con tu propia autenticación.

4. La tarea abarca dos o más sistemas

   Crea o adopta una capa gobernada

   Un único conjunto de herramientas, reglas de consentimiento e historial de auditoría para todos ellos.

Crear un servidor básico es la parte fácil. Con un SDK oficial, un servidor stdio funcional con una herramienta es trabajo de una tarde. El coste llega después: OAuth para la versión HTTP, las funciones obsoletas (la revisión 2026-07-28 declaró obsoletos Roots, Sampling y Logging, además de Dynamic Client Registration) y la tarea continua de escribir descripciones de herramientas que un modelo lea correctamente. Envolver una API con una herramienta por endpoint es el error más común. Cada descripción de herramienta es texto que el modelo tiene que leer y sopesar, así que una lista corta de herramientas pensadas para la tarea gana a toda la superficie de la API.

MCP, API, integraciones e iPaaS

MCP no sustituye a las API. Casi todos los servidores MCP envuelven una. La API sigue siendo donde ocurre el trabajo, con sus propios límites de peticiones, su modelo de datos y sus rarezas. MCP cambia quién puede llamarla: un modelo, en tiempo de ejecución, que elige la llamada a partir de una descripción en lugar de que un desarrollador la deje programada de antemano.

Esa distinción traza una línea clara frente a las otras dos cosas con las que se confunde:

• Las integraciones y el iPaaS (aquí se comparan las principales plataformas) mueven datos según un horario o un disparador, de forma determinista, haya o no alguien en un chat. Una sincronización nocturna de 40.000 pedidos hacia un CRM no debería depender de que un modelo decida hacer 40.000 llamadas a herramientas.
• El reverse ETL lleva datos modelados desde un data warehouse de vuelta a las herramientas operativas. Qué es el reverse ETL y cuándo encaja es un tema aparte, y es un pipeline, no una conversación.
• MCP es para los momentos en que una persona o un agente necesita preguntar, inspeccionar o actuar a través de esos sistemas, bajo demanda.

El error va en las dos direcciones. Hay equipos que crean servidores MCP para hacer sincronizaciones masivas y obtienen pipelines lentos, caros e irrepetibles. Otros construyen integraciones cuidadosas y luego le dan a su asistente de IA una clave de API en bruto para consultarlas, y obtienen una puerta trasera sin gobierno.

En una integración compatible, el trabajo persistente y las herramientas para inspeccionarlo deben compartir un límite explícito de permisos. Comprueba el conector, las acciones permitidas y los resultados registrados para ese flujo. La documentación de integraciones distingue las instrucciones de configuración de los recorridos aún pendientes de pruebas en producción. MCP puede exponer herramientas aprobadas por separado; enumerarlas no demuestra que una sincronización recurrente o todos los controles necesarios estén activos.

En 22 meses, MCP pasó de seis servidores de referencia a ser un proyecto de la Linux Foundation que hablan Claude, ChatGPT, VS Code y Cursor. Conectar un modelo a un sistema es ahora la parte barata. Decidir qué puede hacer allí es el trabajo.