MCP: qué es y cómo montar tu servidor en 2026 (mi caso)

MCP es el enchufe estándar entre la IA y tus herramientas. El 28 de julio de 2026 cambió de arriba abajo y casi nadie lo ha contado en español. Aquí está lo que corre en mi Raspberry Pi 5, con medidas.

¿Qué es MCP? La respuesta en una frase

MCP, o Model Context Protocol, es un estándar abierto que define cómo una aplicación de IA se conecta a sistemas externos. Lo publicó Anthropic el 25 de noviembre de 2024 y hoy lo mantiene una fundación dentro de la Linux Foundation, con contribuidores como Microsoft y GitHub.

La comparación que usa la propia documentación es la más útil que he encontrado: MCP es el USB-C de las aplicaciones de IA. Antes de USB-C cada teléfono tenía su cargador. Antes de MCP, cada herramienta que querías darle a un modelo necesitaba una integración hecha a mano. Con el protocolo, la herramienta se expone una vez y cualquier cliente compatible la puede usar.

La frase que lo resume todo está en la introducción oficial, y merece la pena leerla despacio: no es un protocolo para que el modelo sepa cosas, es un protocolo para que el modelo haga cosas.

Modelo, cliente, servidor: quién es quién

Aquí se lía mucha gente, así que lo separo como lo entiendo yo después de tocarlo:

El servidor no habla con el modelo. Habla con el cliente, y el cliente decide qué le enseña al modelo. Esa separación es la que permite que el mismo servidor sirva para Claude, para ChatGPT o para un agente propio sin cambiar una línea.

Las tres cosas que un servidor puede ofrecer

Un servidor MCP puede exponer tres tipos de primitivas, y entender la diferencia ahorra meses de diseño equivocado, según la especificación:

• Herramientas (tools): funciones que el modelo puede ejecutar. Son lo que casi todo el mundo usa: buscar, publicar, consultar una base de datos. Se descubren con tools/list y se ejecutan con tools/call.
• Recursos (resources): datos que se le pasan al modelo como contexto. El ejemplo clásico es el esquema de una base de datos: no es una acción, es información.
• Plantillas (prompts): instrucciones reutilizables que el usuario invoca a propósito. Sirven para convertir un flujo que repites cada semana en un comando.

Y hay una cuarta pieza que va en dirección contraria, del servidor hacia ti. Se llama elicitation y permite que el servidor pida un dato extra al usuario —una confirmación, un parámetro que falta— en mitad de la operación. En la revisión 2026-07-28 esta conversación ya no ocurre por un canal bidireccional permanente, sino por el patrón de peticiones multi-vuelta del que hablo más abajo.

🎬 Vídeo: MCP desde cero: Conecta tu IA a cualquier dato — MoureDev by Brais Moure. Es la explicación más clara que he encontrado en español, aunque es anterior al cambio de julio de 2026: sirve para entender las piezas, no el protocolo de hoy.

Cómo funciona por dentro: lo medí en mi máquina

Aquí es donde la mayoría de artículos se quedan en el dibujo. Yo lancé el protocolo a mano contra mi propio servidor para ver qué contesta de verdad. No es difícil: un servidor por entrada estándar come líneas JSON y escupe líneas JSON.

Le mandé tres mensajes —initialize, la notificación de inicializado y tools/list— y esto es lo que respondió, sin tocar nada:

Tres conclusiones que no esperaba ver tan claras:

1. Tarda menos de un segundo. 0,90 s entre arrancar el proceso, negociar y listar once herramientas. El protocolo no es el cuello de botella de nada.
2. Mi servidor habla la versión vieja. Contesta 2025-06-18, que es la revisión de hace un año. No es un error: es que el SDK que tengo instalado la implementa.
3. El desfase es de una versión mayor. Mi SDK de Python instalado es el 1.28.1 y en el repositorio oficial ya está el 2.2.0, que es el que acompaña a la especificación nueva.

Y esa es la parte incómoda: mi sistema funciona hoy, pero funciona sobre una versión que ya tiene fecha de caducidad formal. Lo cuento en el apartado de deprecaciones.

Qué tengo corriendo ahora mismo en la Raspberry Pi 5

Mi caso no es académico. Tengo una Raspberry Pi 5 de 8 GB sirviendo la web, con el sistema operativo y los datos en un SSD NVMe de 1 TB, y encima de eso corre todo el pipeline editorial más los servidores MCP. Medido hoy, esto es lo que hay:

Fíjate en la diferencia entre los dos primeros, porque enseña algo del protocolo que no está en la documentación: listar 30 herramientas puede tardar 18 veces más que listar 11. No es culpa de MCP, es que el segundo servidor se arranca con uvx, que resuelve y descarga dependencias de Python antes de saludar. Si tu cliente hace esta llamada al abrir cada conversación, acabas de añadir dieciséis segundos a cada chat sin darte cuenta.

Dos cosas que aprendí midiendo esto y que ahora aplico siempre. La primera es que el coste de un servidor MCP no está en ejecutar la herramienta, está en descubrirla. La segunda es que el registro de herramientas se puede cachear, y la revisión de julio de 2026 lo hace explícito: las respuestas de listado llevan ya pistas de caché y un orden determinista. Justo esto era el problema de antes, y por eso me alegro de que lo hayan metido en el estándar.

Lo que cambió el 28 de julio de 2026 (y te va a romper el setup)

Este apartado es el motivo por el que escribo este artículo y no otro. Todas las guías en español que he encontrado sobre MCP son de antes de julio de 2026 y describen un protocolo que ya no es el de hoy. Si sigues una de esas para montar algo nuevo, vas a programar un apretón de manos que ya no existe.

El resumen oficial está en la entrada de publicación de la especificación 2026-07-28 y en el registro de cambios. Lo que importa de verdad:

1. El protocolo deja de tener estado

Desaparece el initialize con su notificación de inicializado y desaparece la cabecera de sesión. Cada petición pasa a ser autosuficiente: lleva su versión del protocolo y sus capacidades. La razón está en la propuesta SEP-2575, y es muy poco glamurosa: con sesión, poner el servidor detrás de un balanceador normal es un infierno, porque la sesión queda pegada a la instancia que guarda el estado.

Esto, para alguien como yo que sirve todo desde una máquina, suena a problema de empresas grandes. No lo es: significa que cualquier petición puede caer en cualquier instancia y que el servidor ya no puede guardar cosas en memoria entre llamadas. Si tu servidor MCP mantenía un contador, un login o un cursor en memoria, eso se rompe. La solución que propone el estándar es interesante: el estado pasa a ser un identificador que una herramienta te devuelve y que el modelo arrastra como argumento en la siguiente llamada, a la vista.

2. Aparece server/discover

Si un cliente quiere saber qué versiones y capacidades soporta el servidor antes de hacer nada, llama a este método. No es obligatorio, es una comodidad: permite elegir versión de antemano o actuar de sonda de compatibilidad en conexiones por entrada estándar. Y devuelve también la identidad del servidor.

3. Las peticiones del servidor al cliente cambian de forma

Todo lo que antes hacía el servidor pidiendo algo al cliente —raíces, generación de texto, pedir datos al usuario— se reconvierte al patrón de peticiones multi-vuelta. El servidor no envía una petición y espera; devuelve un resultado de tipo input_required con lo que necesita, y el cliente reintenta la operación original con las respuestas incluidas. Más vueltas, menos conexiones abiertas para siempre.

4. Enrutado por cabeceras y listados cacheables

El método y el nombre de la herramienta viajan ahora en cabeceras HTTP. Eso permite que una pasarela enrute y autorice sin deserializar el cuerpo, y que los catálogos de herramientas se puedan cachear sin que se te caiga la caché del prompt cada vez que alguien reconecta.

5. Refuerzo de autorización

Se añade validación del emisor en OAuth y se abandona el registro dinámico de clientes en favor de documentos de metadatos. Traducido: la forma de dar permisos a un servidor MCP remoto deja de ser "que se registre solo" y pasa a ser "que se identifique con un documento verificable".

Qué está deprecado y cuándo desaparece

La revisión de julio estrena también una política formal de ciclo de vida con un mínimo de doce meses antes de retirar nada. Y publica el registro de funciones deprecadas, que es lo que deberías mirar antes de empezar cualquier proyecto nuevo:

Dos de ellas me afectan directamente y conviene decirlo sin adornos. La primera: si tienes un servidor que registra por el protocolo, eso está en la lista. La segunda y más gorda: el registro dinámico de clientes se va, y quien tenga montada autorización remota a la antigua tendrá que migrarla antes de mediados de 2027.

En mi caso el hallazgo concreto fue el de la versión del SDK: 1.28.1 instalado, 2.2.0 publicado. No es urgente hoy, pero es exactamente el tipo de deuda que se paga sola cuando pasa un año y ya nadie recuerda por qué había que tocar ese fichero. Prefiero tenerlo anotado.

El registro oficial: cómo encontrar servidores sin adivinar

Durante 2025, encontrar un servidor MCP decente consistía en buscar en listas de GitHub hechas por voluntarios, con enlaces rotos y claves filtradas. Eso se acabó con el registro oficial, que está en vista previa y respaldan Anthropic, GitHub, Microsoft y PulseMCP.

Lo importante del registro no es que tenga servidores, es cómo evita el suplantamiento: los nombres van en formato de dominio invertido (io.github.usuario/servidor) y para publicar hay que demostrar que controlas ese dominio o esa cuenta de GitHub. Si el nombre dice de quién es, el nombre sirve como aval.

Se puede consumir por interfaz de programación. Lo he probado y responde:

Un detalle que me parece más honesto que el de muchas tiendas: el registro no acepta servidores privados. Si tu servidor solo está accesible en tu red interna, este registro no es tu sitio y el propio proyecto te dice que montes el tuyo. Lejos de ser un fallo, eso evita que un catálogo público se llene de cosas que nadie más puede usar.

Las extensiones: Apps, Tasks y autorización de empresa

La otra novedad estructural de julio es que las funciones que no son núcleo salen del núcleo y pasan a ser extensiones oficiales, con identificador propio y negociación explícita. Las tres que existen:

• MCP Apps: permiten que un servidor devuelva una interfaz interactiva —un formulario, un gráfico, un reproductor— que se dibuja dentro de la conversación. Según su documentación, corren en un marco aislado y no pueden tocar la página que las contiene. Es lo que te ahorra montar una web aparte solo para enseñar un panel.
• Tasks: para operaciones largas. En vez de tener la conexión abierta esperando, el servidor devuelve un identificador duradero y el cliente consulta el estado. Los estados son trabajo en curso, entrada requerida, completada, fallida y cancelada, y sobrevive a que el cliente se reinicie.
• Autorización gestionada por la empresa: pensada para organizaciones que necesitan control de acceso centralizado.

Lo que me interesa de este diseño es la degradación ordenada. Si tu cliente no soporta una extensión, el servidor debe seguir devolviendo una respuesta de texto útil. Eso se llama compatibilidad hacia atrás y es justo lo que le faltaba al ecosistema hace un año.

Cómo montar tu propio servidor MCP, paso a paso

Ahora la parte práctica. Yo monto servidores MCP en Python y el esqueleto completo de un servidor con herramientas es este, recortado de mi servidor de Twitter:

Y para probarlo sin depender de ningún cliente gráfico, el truco que uso es lanzarle el protocolo a mano por entrada estándar, como hice al principio del artículo. Es la forma más rápida de saber si tu servidor es correcto: si responde a tools/list con tus herramientas, el transporte funciona. Los pasos concretos son tres.

1. Declara la herramienta con un nombre que se entienda. El modelo decide qué llamar leyendo el nombre y la descripción. Un nombre vago es una herramienta que nunca se usa.
2. Tipa los parámetros. El esquema lo genera el SDK a partir de los tipos de Python y es lo que el modelo ve. Un parámetro sin tipo es una llamada con argumentos inventados.
3. Devuelve texto, no objetos. El resultado tiene que ser algo que el modelo pueda leer. Serializar bien te ahorra depuraciones largas.

Y un consejo que sale de mis medidas, no de la documentación: evita dependencias que haya que resolver en el arranque. Mi servidor de análisis de código se arranca con uvx y tarda 16,1 s en listar sus treinta herramientas. Funciona, pero duele. Si vas a escribir el tuyo, cuantas menos piezas móviles en el arranque, mejor.

Lo que casi nadie te cuenta: la seguridad

Este es el apartado que más me ha hecho cambiar de idea. La descripción de una herramienta MCP es texto que el modelo lee y trata como instrucciones. Y ese texto lo escribe el servidor, que puede ser de cualquiera. El protocolo no obliga a validarlo ni a firmarlo.

Eso no es teoría. La nota de investigación de la Cloud Security Alliance publicada el 1 de julio de 2026 recoge las cifras del banco de pruebas MCPTox: 45 servidores MCP reales contra 20 modelos, con un 36,5% de éxito medio en ataques de envenenamiento de herramientas. El peor caso contra un solo modelo llegó al 72,8%. Y el vector no es que el servidor ejecute algo que el host no autorizó: es que el servidor controla texto que el modelo trata como autorizado.

Los otros datos que me hicieron revisar mi configuración:

• Los entornos de desarrollo con más usuarios —Cursor, Claude Code, Gemini CLI, GitHub Copilot y Amazon Q— ejecutan servidores definidos por el proyecto con privilegios del usuario y sin aislamiento de proceso.
• Existe una variante llamada MCPoison, con identificador CVE-2025-54136, que compromete a todo un equipo desde un solo fichero de configuración versionado. Como los ficheros de configuración de MCP se suben con el código, el ataque pasa por revisión de código sin que nadie lo vea como lo que es.
• El gusano Miasma propagó configuraciones comprometidas hasta 73 objetivos sin que el atacante hiciera nada más.
• Desde junio de 2026, Microsoft clasifica las descripciones de herramientas MCP como activos de cadena de suministro, con el mismo rigor de revisión que el código de producción. Y OWASP puso el envenenamiento de herramientas en el tercer puesto de su lista MCP Top 10.

¿Qué hago yo con esto? Tres cosas que me costaron poco y que puedes copiar:

1. Lista cerrada de servidores. No instalo uno nuevo sin mirar quién lo publica y qué herramientas expone. Nada de probar servidores al azar.
2. Lo que publica mi web no lleva mis claves. La automatización que publica vive en un proceso aparte; el servidor MCP que lee notificaciones usa su propia sesión. Si un servidor se compromete, no arrastra todo lo demás.
3. Sin secretos en el repositorio. Las credenciales van en fichero de entorno fuera del árbol de código. El incidente de MCPoison se basa justo en una configuración versionada que apunta a un servidor ajeno.

Lo que nadie te dijo

Tres cosas que he aprendido con esto funcionando y que no aparecen en ninguna guía de MCP que haya leído.

La primera: el coste real está en el descubrimiento, no en la ejecución. Dieciséis segundos en listar treinta herramientas es demasiado caro para hacerlo cada vez. Si tu cliente lo llama en cada conversación, has construido una lentitud que nadie va a saber atribuir a su causa.

La segunda: un protocolo que mejora te deja deuda. Mi servidor funciona perfectamente. Y aun así tiene una fecha de caducidad formal porque implementa la versión 2025-06-18 con un SDK 1.28.1, mientras el estándar va por la 2026-07-28 y el SDK por el 2.2.0. Nadie te avisa de esto: no hay errores, no hay avisos, simplemente un día el registro dinámico de clientes ya no está y tu autorización remota deja de funcionar.

La tercera y más incómoda: el mismo texto que hace útil a MCP es su agujero. MCP funciona porque el modelo lee descripciones en lenguaje natural escritas por terceros y decide en función de ellas. Es exactamente la razón por la que es tan fácil de extender y tan fácil de envenenar. Con un 36,5% de éxito medio en los ataques medidos, no es un riesgo teórico que puedas dejar para más adelante.

Preguntas frecuentes

¿Qué es MCP en palabras sencillas?

Un estándar abierto que define cómo una aplicación de IA se conecta a herramientas y datos externos. En lugar de hacer una integración distinta para cada servicio, el servicio se expone una vez como servidor MCP y cualquier cliente compatible lo puede usar. Lo publicó Anthropic en noviembre de 2024.

¿MCP es lo mismo que function calling?

No. Function calling es el formato que un modelo concreto entiende para invocar una función. MCP es la capa de debajo: describe el transporte, el descubrimiento de herramientas y la negociación de capacidades, y no depende del modelo ni del proveedor.

¿Cuánto cuesta usar MCP?

El protocolo y los SDK oficiales son gratuitos. Lo que cuesta es el modelo de IA que hay detrás y, si tu servidor llama a una interfaz de pago, esas llamadas. Mi caso: los servidores corren en una Raspberry Pi que ya tenía encendida.

¿Necesito saber programar para usar MCP?

Para usarlo, no: instalar un servidor existente es configuración. Para escribir el tuyo, sí, aunque el esqueleto es tan corto como el ejemplo de arriba. El trabajo real está en decidir qué herramienta merece existir y cómo describirla.

¿Qué versión de MCP debería implementar si empiezo hoy?

La 2026-07-28, la vigente desde el 28 de julio de 2026. Si sigues un tutorial anterior a esa fecha, vas a programar un apretón de manos de inicialización que ya no forma parte del núcleo del protocolo.

¿Es peligroso instalar servidores MCP de terceros?

Tiene riesgo real y medido. El experimento MCPTox encontró un 36,5% de éxito medio en ataques de envenenamiento de herramientas sobre 45 servidores y 20 modelos. Trátalos como dependencias de producción: mira quién los publica, qué exponen y qué permisos les das.