Las tres cosas que un servidor puede exponer
Las herramientas son operaciones que el modelo puede invocar, cada una descrita por un nombre, un esquema para sus argumentos y lo que devuelve: «listar quién llama a esta función», «abrir una solicitud de cambio». Como es el modelo quien elige cuándo usarlas, un cliente bien gestionado pregunta a la persona antes de ejecutar algo con consecuencias.
Los recursos son contenidos identificados por una URI, como un archivo, un registro o un informe que generó el servidor, que la aplicación trae al contexto cuando es pertinente. Sirven para leer; cambiar algo es trabajo de una herramienta.
Los prompts son plantillas con nombre y parámetros que una persona invoca a propósito. Permiten al equipo dueño de un sistema publicar la forma probada de hacer una tarea justo al lado de las herramientas que la hacen.
Dónde se ubica
La especificación nombra tres partes. El anfitrión es el programa frente a la persona: un IDE, una aplicación de chat de escritorio, un agente de terminal. El anfitrión ejecuta un cliente por cada servidor al que está conectado, y ese cliente es el que se autentica e intercambia mensajes. El servidor es el programa del otro lado. El modelo de lenguaje trabaja a través del anfitrión: ve la descripción de cada herramienta y propone las llamadas.
Lo que llega al servidor es la solicitud, no el chat que la rodea. Eso limita lo que un servidor puede saber de una persona, y también significa que no puede saber de dónde vino un argumento: un valor que el modelo copió del documento de un atacante llega con el mismo aspecto que uno que escribió la persona. Cada argumento debe validarse como entrada hostil.
La regla que más importa
La especificación prohíbe el reenvío de tokens: un servidor solo puede aceptar tokens emitidos para él, y no puede pasar el token de una persona a otro sistema. Verificado en cada solicitud, es lo que mantiene cada acción atribuible a la persona que la pidió, y no a una cuenta de servicio compartida que ve más que ella.
Qué cambió en la especificación 2026-07-28
El protocolo pasó a ser sin estado. No hay saludo inicial ni identificador de sesión: cada solicitud lleva su propia versión del protocolo y sus capacidades, de modo que cualquier solicitud puede llegar a cualquier instancia del servidor detrás de un balanceador común. Un servidor que necesita estado entre llamadas devuelve un identificador explícito y verifica, en cada llamada, que pertenece a la persona que lo presenta.
El transporte anterior de HTTP con eventos enviados por el servidor queda obsoleto, con un plazo de doce meses para migrar. Los clientes ahora se identifican con un documento de metadatos en una URL que controlan, y el registro dinámico de clientes está de salida. El trabajo de larga duración y las interfaces dentro del chat pasaron a ser extensiones oficiales. Un servidor construido en 2025 sigue funcionando hoy, pero tiene una migración pendiente.
Cuándo se necesita uno, y cuándo no
Una persona que automatiza su propio trabajo en su propia máquina suele estar mejor servida por una herramienta de línea de comandos o una habilidad empaquetada, que le cuesta menos contexto al modelo. El acceso al almacén de datos puede estar cubierto ya por el servidor gestionado de la propia plataforma. Un servidor MCP se gana su lugar cuando muchas personas necesitan la misma capacidad, cuando cada llamada debe poder atribuirse a una persona, y cuando el sistema detrás es uno que ningún asistente alcanza por sí solo.
La pregunta que hacerle a cualquier servidor MCP
¿Con la identidad de quién se ejecuta esta llamada? Si la respuesta es una cuenta de servicio, toda persona que alcance el servidor puede ver lo que esa cuenta ve, y el registro de auditoría nombra una máquina en lugar de una persona. Si la respuesta es «la persona que la pidió, verificada en cada solicitud», el servidor está haciendo su trabajo.