Glosario de MCP: 50 términos del Model Context Protocol explicados

Este glosario de MCP reúne en una página los 50 términos que más vas a encontrar al leer la especificación del Model Context Protocol, la documentación de los SDK o el código de un servidor. Cada entrada da una definición corta, dice cómo se llama en inglés cuando la especificación lo usa así y enlaza a la lección o al artículo que lo trata.

Todas las definiciones siguen la versión vigente de la especificación, la 2026-07-28, que convirtió MCP en un protocolo sin estado. Lo que esa versión marca como deprecado aparece señalado: sigue funcionando, pero no conviene usarlo en un servidor nuevo. Si empiezas desde cero, lee antes Qué es MCP y vuelve aquí cuando un término te frene.

Los términos del protocolo se quedan en inglés, como en el resto del curso: es como aparecen en la especificación, en los SDK y en los mensajes.

Arquitectura: quién habla con quién

Host. La aplicación que el usuario tiene delante y que contiene o invoca al modelo: un chat de escritorio, un IDE o la consola de soporte de una empresa. Es quien decide si una llamada que propone el modelo se ejecuta. → Arquitectura

Cliente MCP (client). El componente del host que habla el protocolo con un servidor concreto. Un host conectado a tres servidores mantiene tres clientes. → Arquitectura

Servidor MCP (server). El programa que expone las capacidades de un sistema (tools, resources y prompts) a cualquier cliente que hable MCP. Responde a las peticiones del cliente, pero no inicia peticiones por su cuenta. → Arquitectura

JSON-RPC 2.0. El formato de todos los mensajes de MCP. Hay tres tipos. Las peticiones llevan id y method. Las respuestas llevan result o error y el mismo id. Las notificaciones no llevan id ni tienen respuesta. → Arquitectura

stdio. El transporte de los servidores locales. Es uno de los dos que define la especificación; el otro es Streamable HTTP, con la misma semántica. El cliente lanza el servidor como subproceso y los dos se comunican por la entrada y la salida estándar, un mensaje JSON-RPC por línea. El servidor no puede escribir en stdout nada que no sea un mensaje MCP. Sus logs van a stderr. → Arquitectura

Streamable HTTP. El transporte remoto: un único endpoint que recibe cada mensaje del cliente como un POST nuevo y responde con un objeto JSON o con un stream SSE. El servidor debe validar la cabecera Origin y, en local, debería escuchar solo en 127.0.0.1. → Arquitectura

HTTP+SSE (deprecado). El transporte HTTP de la revisión 2024-11-05. Está deprecado desde la revisión 2025-03-26 y su sustituto es Streamable HTTP. No sigue la ventana general de doce meses: puede retirarse tres meses después de que SEP-2596 llegue a Final. → Estado actual y evolución

El protocolo sin estado

Protocolo sin estado (stateless). Desde 2026-07-28, toda la información para procesar una petición viaja en la propia petición. No hay handshake initialize ni sesiones con la cabecera Mcp-Session-Id. Una conexión abierta, como un proceso stdio, no es una sesión. El cambio completo está en MCP 2026-07-28: el protocolo pasa a ser sin estado. → Cómo viaja una petición

_meta. El objeto de metadatos que lleva cada petición en params. Son obligatorias io.modelcontextprotocol/protocolVersion y io.modelcontextprotocol/clientCapabilities. Si falta alguna, el servidor rechaza la petición con -32602 (y 400 en HTTP). → Cómo viaja una petición

Versión del protocolo (protocol version). Una fecha que identifica la revisión de la especificación, como 2026-07-28. Cada petición declara la suya y el servidor la acepta o responde UnsupportedProtocolVersionError (-32022) con la lista de versiones que soporta. → Cómo viaja una petición

Capacidades (capabilities). Lo que cada parte declara que sabe hacer. El cliente las envía en cada petición; el servidor, en server/discover. Si una petición necesita una capacidad que el cliente no declaró, el servidor devuelve -32021. → Cómo viaja una petición

server/discover. El método que todo servidor debe implementar para anunciar las versiones que soporta, sus capacidades y su identidad. El cliente puede llamarlo o no. En stdio sirve también como sonda para saber si el servidor habla la versión actual. → Cómo viaja una petición

resultType. El campo que todo resultado debe llevar para decir de qué tipo es: "complete" si es el resultado final e "input_required" si al servidor le falta información. Las extensiones pueden añadir valores, como "task". → Cómo viaja una petición

MRTR (Multi Round-Trip Requests). El patrón con el que un servidor pide algo al cliente sin iniciar peticiones. El servidor responde con input_required e inputRequests, y el cliente reintenta la petición original con un id nuevo y añade inputResponses. Solo lo admiten tools/call, prompts/get y resources/read. → Interacción con el usuario y extensiones

requestState. Un texto opaco que el servidor puede incluir en un resultado input_required y que el cliente debe devolver exacto en el reintento, sin leerlo ni modificarlo. El servidor debe tratarlo como entrada de un atacante. Si influye en permisos o en la lógica de negocio, debe protegerlo con HMAC o AEAD. → Interacción con el usuario y extensiones

Identificador de estado (handle). Como no hay sesiones, el servidor emite un identificador explícito para el estado que abarca varias llamadas, y el cliente lo pasa como argumento en las siguientes. Tenerlo no equivale a estar autenticado: el servidor no debe tratarlo como prueba de identidad y debería ligarlo al usuario del token. → Diseño de servidores MCP

ttlMs y cacheScope. Las pistas de caché obligatorias en los resultados completos de server/discover, de los listados y de resources/read. ttlMs dice cuántos milisegundos puede considerarse fresco el resultado. cacheScope dice si es "public" (compartible entre usuarios) o "private" (solo en el mismo contexto de autorización). → Recursos

subscriptions/listen. La petición que abre un stream de notificaciones de larga duración: cambios en las listas de tools, prompts o resources y actualizaciones de recursos concretos. Sustituye al endpoint GET de HTTP y a resources/subscribe, que ya no existen. → Recursos

Primitivas: tools, resources y prompts

Tool. Una acción que el servidor expone y que el modelo puede proponer usar, con name, description e inputSchema en JSON Schema. Se lista con tools/list y se ejecuta con tools/call. El host decide si la llamada se hace. → Herramientas

structuredContent y outputSchema. El resultado de una tool en forma de dato JSON, además del contenido para el modelo en content. Si la tool declara outputSchema, el servidor debe devolver un structuredContent conforme a ese esquema. → Herramientas

Anotaciones de tool (tool annotations). Pistas sobre el comportamiento de una tool: readOnlyHint, destructiveHint, idempotentHint y openWorldHint. Son solo pistas: el cliente debe tratarlas como no fiables salvo que el servidor sea de confianza. → Herramientas

Error de protocolo y error de ejecución. Una tool desconocida o una petición malformada producen un error JSON-RPC. Un fallo al ejecutar la tool (una API caída, un dato inválido) se devuelve como resultado con isError: true, para que el modelo pueda leerlo y corregirse. → Herramientas

Resource. Un dato identificado por una URI que el servidor expone para leer, como un fichero o un registro. Se lista con resources/list y se lee con resources/read. La aplicación, no el modelo, decide qué recursos incorpora al contexto. → Recursos

Plantilla de recurso (resource template). Una URI con variables, en formato RFC 6570, que describe una familia de recursos, como pedidos://pedido/{pedidoId}. Se listan con resources/templates/list. → Recursos

Prompt. Una plantilla de mensajes con argumentos que el servidor publica para que el usuario la invoque. prompts/get la convierte en mensajes con rol user o assistant listos para la conversación. → Prompts

Interacción con el usuario y operaciones largas

Elicitation. El mecanismo con el que el servidor pide datos al usuario a través del cliente. Nunca lo hace como petición del servidor: en el núcleo usa MRTR y, dentro de una task, tasks/get y tasks/update. Tiene dos modos: formulario, para datos simples, y URL, que abre una página externa. Las contraseñas, claves o datos de pago nunca se piden por formulario, sino por el modo URL. → Interacción con el usuario y extensiones

Progreso (progress). Si el cliente incluye un progressToken en _meta, el servidor puede enviar notifications/progress con un valor de progress que siempre aumenta y, opcionalmente, un total y un mensaje. Esas notificaciones viajan por el stream de respuesta de esa misma petición. → Cómo viaja una petición

Cancelación (cancellation). En Streamable HTTP, cerrar el stream de la respuesta es la señal de cancelar. En stdio, el cliente envía notifications/cancelled con el id de la petición. En los dos casos el servidor debería dejar de trabajar en ella cuanto antes. → Cómo viaja una petición

Tasks. La extensión oficial io.modelcontextprotocol/tasks para operaciones largas. Si el cliente la declara, el servidor puede responder a un tools/call con una task (resultType: "task"). El cliente la consulta con tasks/get, le envía la información que pida con tasks/update y puede cancelarla con tasks/cancel. En 2026-07-28 salió del núcleo. → Operaciones largas y tiempo real

Lo deprecado en 2026-07-28

Ciclo de vida de una funcionalidad (feature lifecycle). Cada funcionalidad está Active, Deprecated o Removed. En general, lo deprecado sigue en la especificación al menos doce meses desde la revisión que lo deprecó (HTTP+SSE tiene su propia ventana) y con una ruta de migración. Las implementaciones nuevas no deberían adoptarlo. → Estado actual y evolución

Roots (deprecado). La capacidad con la que el cliente indicaba al servidor qué directorios o ficheros podía usar. La migración es pasar esas rutas como parámetros de tool, como URIs de recursos o en la configuración del servidor. → Estado actual y evolución

Sampling (deprecado). La capacidad con la que el servidor pedía al cliente una generación del modelo (sampling/createMessage). La migración es que el servidor se integre directamente con la API del proveedor del modelo. → Estado actual y evolución

Logging (deprecado). Los mensajes de log del servidor al cliente (notifications/message). La migración es escribir en stderr con stdio y usar OpenTelemetry para la observabilidad. logging/setLevel ya se eliminó. → Estado actual y evolución

Autorización y seguridad

OAuth 2.1 en MCP. La autorización es opcional. Si un servidor HTTP la usa, sigue OAuth 2.1: el servidor MCP es el resource server, el cliente MCP es el client y el servidor de autorización puede ser otro servicio. Con stdio no se usa: las credenciales salen del entorno. → APIs externas y autorización

Protected Resource Metadata. El documento (RFC 9728) en el que un servidor MCP indica qué servidores de autorización acepta. El cliente lo encuentra en la cabecera WWW-Authenticate de una respuesta 401 o en /.well-known/oauth-protected-resource. → APIs externas y autorización

CIMD (Client ID Metadata Documents). La forma recomendada de obtener un client_id cuando no hay registro previo, por delante del registro dinámico. El client_id del cliente es una URL HTTPS que apunta a un JSON con su nombre y sus redirect_uris. Sirve con cualquier servidor de autorización que lo soporte sin registrarse de nuevo. → APIs externas y autorización

Registro dinámico de clientes (Dynamic Client Registration, deprecado). El registro automático de un cliente en el servidor de autorización (RFC 7591). Queda como alternativa de compatibilidad para servidores de autorización sin CIMD, que es su sustituto. → APIs externas y autorización

Token passthrough. El antipatrón de aceptar un token que no se emitió para tu servidor y reenviarlo a otra API. La especificación lo prohíbe: un servidor MCP debe comprobar que el token se emitió para él y no puede reenviar tokens ajenos. → Seguridad avanzada

Confused deputy. El ataque contra un servidor MCP que hace de proxy hacia una API de terceros con un client ID estático, combinado con registro dinámico y cookies de consentimiento del tercero. Con esa combinación, un atacante consigue códigos de autorización sin consentimiento real del usuario. La defensa es pedir consentimiento por cada cliente antes de iniciar el flujo con el tercero. → Seguridad avanzada

Tool poisoning. Instrucciones maliciosas escondidas en las tools o en sus resultados, sobre todo en las descripciones, que el modelo lee y el usuario no ve. El término viene del MCP Top 10 de OWASP (MCP03). Los casos reales de estos meses están en Seguridad en servidores MCP. → Seguridad avanzada

Extensiones y ecosistema

Extensión (extension). Una adición opcional fuera del núcleo, con un identificador {prefijo}/{nombre}, que se negocia en el campo extensions de las capacidades. Siempre está desactivada por defecto. Las oficiales usan el prefijo io.modelcontextprotocol. → Interacción con el usuario y extensiones

MCP Apps. La extensión oficial io.modelcontextprotocol/ui: un servidor entrega interfaces HTML interactivas, como recursos ui://, que el host muestra dentro de la conversación en un iframe aislado. Su estado de adopción está en MCP Apps. → Estado actual y evolución

Skills sobre MCP. La extensión oficial io.modelcontextprotocol/skills (SEP-2640, Final el 13 de septiembre de 2026). Permite descubrir y leer Agent Skills desde un servidor con skills/list, skills/get y URIs skill://. → Skills sobre MCP

MCP Registry. El repositorio oficial de metadata de servidores MCP públicos, descritos en un server.json con nombres en DNS inverso. No aloja código, está pensado para agregadores y sigue en preview. → Estado actual y evolución

Server Card. Una extensión (SEP-2127, Final desde el 6 de octubre de 2026) para describir la conexión de un servidor remoto de modo que se pueda descubrir sin conectarse a él, a través de un AI Catalog en /.well-known/ai-catalog.json. No forma parte de 2026-07-28. → Descubrir un servidor MCP sin conectarse

SEP (Specification Enhancement Proposal). Una propuesta numerada para cambiar la especificación, como SEP-2575, que eliminó el handshake. Desde el 28 de septiembre de 2026 hay que discutir la idea en un grupo de trabajo o de interés antes de abrirla. Las que preparan la próxima versión están en La próxima versión de MCP. → Estado actual y evolución

AAIF (Agentic AI Foundation). El fondo dirigido de la Linux Foundation bajo el que está MCP. Las notas de prensa de la fundación lo citan entre sus «founding projects», en una lista que hoy incluye también A2A, AGENTS.md, goose, agentgateway y Agent Router. → Qué es MCP

“MCP 2.0”. Un apodo, no un número de versión oficial. Así llama parte del ecosistema, incluidas Anthropic y OpenAI, a la especificación 2026-07-28. → “MCP 2.0” en producción

MCP Inspector. La herramienta oficial (@modelcontextprotocol/inspector) para conectarse a un servidor y probar a mano sus tools, resources y prompts, con interfaz web, de terminal o de línea de comandos para CI. → Testing y depuración

Pasarela MCP (gateway). Un servidor que se pone delante de varios servidores MCP y ofrece a los clientes un único endpoint, con una política de acceso y un registro de auditoría comunes. Debería desambiguar los nombres de tools que coinciden entre servidores. → Arquitecturas distribuidas

Cómo usar este glosario

Cada enlace lleva a la ficha pública de la lección que trata el término, también en los niveles Avanzado y Experto, o al artículo del blog que lo desarrolla. Las lecciones de Básico se leen completas con solo registrarte, porque ese nivel es gratuito (planes). Si quieres el recorrido ordenado en lugar de las definiciones sueltas, empieza por Introducción a MCP o mira el temario completo en /aprende.