MCP explicado desde la especificación: qué es realmente un servidor

Antes del cable, la aritmética. Tienes $N$ aplicaciones de IA y $M$ cosas a las que deberían poder llegar: un calendario, un gestor de tickets, una base de datos de almacén, una herramienta de diseño. Sin un contrato compartido, alguien escribe $N \times M$ integraciones, y cada una de ellas es un esquema más un endpoint más una historia de autenticación más una carga de mantenimiento. Con uno, el proveedor de la herramienta escribe un servidor, el proveedor de la aplicación escribe un cliente, y el total es $N + M$.

No es una observación nueva, y la especificación dice de quién tomó la idea:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

Tómate esa comparación literalmente, no como un cumplido. Antes de ese protocolo, dar soporte a un lenguaje en un editor significaba un plugin por editor; después, el equipo del lenguaje distribuía un servidor y todos los editores lo obtenían. La medida del éxito no era la elegancia, sino que el número de integraciones dejaba de multiplicarse. Aquí pasa lo mismo: el valor está en el número de implementaciones, no en el diseño. Un protocolo que hablan dos productos es un formato de datos con ceremonia extra.

Los mensajes MCP son JSON-RPC 2.0. Una petición es un objeto con jsonrpc, un id, un method y params opcional; una respuesta lleva el mismo id y result o error; una notificación es una petición sin id y no recibe respuesta. La especificación añade tres restricciones encima: el id debe ser una cadena o un número y no debe ser null, no debe colisionar con otra petición aún en curso, y todo resultado debe llevar un campo resultType.²

En el transporte stdio —el que usó el comando anterior— la regla de framing es una línea por mensaje:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

Esa última cláusula es la forma más habitual en que se rompe un servidor casero, y se rompe en silencio: un console.log perdido, una barra de progreso, una advertencia de deprecación de una dependencia, y el parser de líneas del cliente encuentra algo que no es JSON. La vía de escape está en la misma sección: el servidor puede escribir lo que quiera en stderr, y el cliente no debería tratarlo como un error. El servidor de referencia anterior imprime Starting default (STDIO) server... en cada arranque, en stderr, por eso la tubería siguió funcionando.

El otro transporte estándar es Streamable HTTP: cada mensaje es un POST a un único endpoint, y la respuesta es o bien un objeto JSON o bien un flujo de Server-Sent Events con alcance de petición: el formato de cable que el capítulo 14 parseó a mano. La semántica es idéntica en ambos, porque un transporte es un binding: define framing y entrega, no significado.⁴

El comando anterior envió tools/list y nada más. Bajo la revisión actual, esa petición está mal formada, y un servidor conforme debe rechazarla.

Desde el 2026-07-28, MCP es un protocolo sin estado, y la especificación lo afirma sin matices:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

Así que cada petición lleva su propia versión del protocolo y sus propias capacidades de cliente, en un objeto reservado _meta dentro de params. Dos de esos campos son obligatorios en todas y cada una de las peticiones; una petición a la que le falte cualquiera de ellos está mal formada y el servidor debe responder -32602:²

Escrita completa, una tools/list correcta es esta, y es la última vez que este capítulo muestra los metadatos completos, porque aparecen en todas las peticiones a partir de aquí:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

El objeto de capacidades es la negociación. Ya no hay un paso de negociación separado: el cliente declara qué puede hacer en cada petición, el servidor declara qué puede hacer en el resultado, y ninguna parte puede usar una función que la otra no haya declarado. Un servidor que necesite una capacidad que el cliente no declaró debe responder -32021 y nombrar la capacidad que falta en data.requiredCapabilities. Un servidor que no hable la versión solicitada debe responder -32022 y listar las versiones que sí habla.²

Los clientes que quieren la respuesta por adelantado pueden pedirla: server/discover es una RPC obligatoria que devuelve versiones soportadas, capacidades, identidad y un bloque opcional de instructions en un solo viaje de ida y vuelta.⁵ Llamarla es opcional. Implementarla no.

El comando funcionó. Bajo la revisión actual no debería haberlo hecho, y la razón merece una medición más que un párrafo, porque es el estado de todo el ecosistema en una línea.

Sondea el servidor de referencia como la especificación indica que debe hacerlo un cliente moderno:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

Esa es la tercera rama de la regla de compatibilidad: un DiscoverResult significa moderno, un error moderno reconocido significa moderno-pero-versión-incorrecta, y cualquier otra cosa —incluido -32601— significa legacy, vuelve al handshake initialize.³ Así que hazlo, pidiendo la revisión actual:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

El cliente pidió 2026-07-28 y el servidor respondió 2025-11-25. El 7 de septiembre de 2026, el servidor de referencia oficial —paquete npm @modelcontextprotocol/server-everything, versión 2026.8.31, publicado el 31 de agosto de 2026— no implementa la revisión actual. Tampoco, por las fechas, lo hace el SDK de TypeScript sobre el que está construido: la release 1.30.0 salió el 27 de julio de 2026, el día antes de la revisión.

Lee la consecuencia, no el cotilleo. Casi todo lo escrito sobre MCP describe un protocolo con un handshake initialize, una sesión, una petición roots/list que el servidor envía al cliente y un transporte HTTP+SSE. Las cuatro cosas han desaparecido o van camino de hacerlo. Cuando leas cualquier cosa sobre MCP, incluida esta página, lo primero que debes buscar es un número de revisión.

Y la razón por la que funcionó el primerísimo comando aparece en la especificación como un peligro, no como una función:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Medido: enviar tools/list a ese servidor sin ningún handshake devuelve el catálogo completo. Un método que debería haberse rechazado fue atendido, que es exactamente por lo que la especificación dice que primero hay que sondear con server/discover aunque solo soportes versiones modernas.

MCP tiene tres partes, y la distinción entre las dos primeras es la que la gente suele confundir:

Servidor. Un proceso o servicio que expone recursos, herramientas y prompts. Puede ser local o remoto, opera de forma independiente, y todo su trabajo es un área concreta.⁶

Esa regla de «exactamente un servidor» no es contabilidad. Es lo que hace implementable el principio de diseño de abajo, y esta es la frase que debes llevarte de la especificación si solo te llevas una:

Servers should not be able to read the whole conversation, nor "see into" other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

Eso invierte el modelo mental con el que llega la mayoría. Un servidor del tiempo que conectas a tu asistente no ve lo que preguntaste. Ve un tools/call con los argumentos que eligió el modelo, y nada más: ni los turnos anteriores, ni tu system prompt, ni los resultados que devolvió el servidor de calendario hace un momento. Si dos servidores necesitan cooperar, el host lleva un valor de uno a otro, deliberadamente, porque el modelo se lo pidió. Por eso el aislamiento es la propiedad de seguridad en la que se apoya el capítulo 30: un servidor comprometido tiene un radio de explosión pequeño y definido, y ampliarlo exige que el host coopere.

El primer comando pidió herramientas a ese servidor y obtuvo trece. Hazle las otras dos preguntas y también las responde: resources/list devuelve siete, prompts/list devuelve cuatro. Ninguna apareció, porque nadie preguntó. Esto nos lleva a la columna vertebral pedagógica de MCP, presente en la especificación como una tabla que casi nadie cita:

No son «tres formas de exponer una capacidad». Son tres respuestas a quién decide que esto ocurra. El modelo decide llamar a una herramienta. La aplicación decide adjuntar un recurso. La persona decide ejecutar un prompt. Si te equivocas ahí, la función sigue funcionando, pero funciona en el momento equivocado y por la razón equivocada.

La forma más clara de sentirlo es un calendario. Aquí hay un servidor que expone el mismo calendario tres veces, una como cada primitiva, en cien líneas de Node puro sin dependencias:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

Ejecútalo y pregúntale de las tres maneras. Salida real, un mensaje por línea en el cable, ajustada aquí para la página, con el _meta de la petición y el bloque de identidad del servidor omitidos:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

Tres métodos, tres formas, un calendario. Ahora, la idea:

Casi todo el mundo convierte las tres cosas en herramientas. El resultado es un catálogo donde una lectura que la aplicación debería haber adjuntado en silencio compite por la attention del modelo con una escritura que necesita aprobación, y donde lo único para lo que una persona quería un botón queda enterrado en un esquema. Hacerlo bien no cuesta nada, y se decide antes de escribir una línea.

La herramienta de calendario tiene un argumento obligatorio, title, y uno opcional, startsAt. Pídele que cree un evento sin fecha y vuelve algo interesante:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

El servidor no envió una petición. Respondió a la que recibió, con resultType: "input_required" y una descripción de lo que todavía necesita. El cliente recoge la respuesta de la persona y luego reenvía la llamada original, con un nuevo id, llevando inputResponses y devolviendo el requestState opaco:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

Esto es Multi Round-Trip Requests, introducido en la revisión actual, y sustituyó al diseño anterior en el que los servidores enviaban peticiones JSON-RPC de vuelta a los clientes. La especificación de transporte ahora enuncia la regla sin rodeos: «servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses».⁴ Hay una sola dirección de iniciativa, y pertenece al host.

Dos funciones del lado del cliente se apoyan en ese mecanismo, y una de ellas tiene un nombre que te hará tropezar.

Elicitation es que el servidor pida algo a la persona: un formulario con un JSON Schema deliberadamente restringido —objetos planos, propiedades primitivas, sin anidamiento— para que cualquier cliente pueda renderizarlo sin un motor de layout. Lleva una regla estricta: los servidores no deben usar el modo formulario para pedir «passwords, API keys, access tokens, or payment credentials», y deben usar el modo URL para eso, que envía al usuario a una página que el cliente nunca lee.⁷

Sampling es que el servidor pida una generación al modelo del host, para que un servidor pueda ser inteligente sin tener una API key. Y aquí va la advertencia de vocabulario, porque esta palabra ya significa otra cosa en este curso: esto no es el sampling del capítulo 17. Aquí nada va de temperatura, top-p ni de la forma de una distribución de probabilidad. Es una llamada anidada al modelo que viaja hacia atrás por un protocolo.

Hay una segunda razón para no recurrir a ello: en esta revisión, sampling está deprecated, junto con roots y logging, bajo SEP-2577, con una migración sugerida sin rodeos: «integrate directly with LLM provider APIs instead of Sampling».⁸ La idea no falló técnicamente; no logró justificar su superficie, y un protocolo que puede quitar cosas es más sano que uno que no puede.

La ausencia de estado suena a detalle de formato de cable hasta que la pruebas. Toma el intercambio de tres mensajes anterior y ejecuta cada mensaje en un proceso separado: un node calendar.mjs nuevo, sin memoria compartida, sin nada trasladado:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

El proceso B, que nunca vio la pregunta, completó una llamada multi-round-trip que empezó el proceso A. Ese es el sentido de requestState: la continuación viaja en el mensaje, así que nada depende de que el proceso sea el mismo.

El proceso C es el fallo. El evento se creó y no está ahí, porque el servidor de juguete guarda EVENTS en un array a nivel de módulo, y un array a nivel de módulo es estado de conexión. La nota de la especificación nombra el error con precisión:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

La solución prescrita no es una sesión. Es un handle explícito: una herramienta de creación devuelve un identificador opaco, y cada llamada posterior lo toma como argumento ordinario. El protocolo no tiene ningún concepto de él: «from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls».⁹ Eso pone al modelo a cargo de llevarlo, y al servidor a cargo de validar que quien llama tiene permiso para usarlo en cada llamada, porque un handle es un nombre y no un permiso.

Cada herramienta que expone un servidor es un esquema que entra en tu prompt en cada petición, y el capítulo 24 midió lo que eso le hace a una ventana. MCP añade una segunda partida fácil de pasar por alto, así que conviene contar ambas en el servidor de referencia anterior.

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

Dos observaciones. La primera es aritmética: conecta cinco servidores de este tamaño y unos ocho mil tokens de tu ventana quedan ocupados en cada turno, para siempre, use o no el modelo alguno de ellos; ese es el mecanismo detrás de la reducción de 150.000 a 2.000 que citaba el capítulo 24, y la razón por la que existe el descubrimiento de herramientas justo a tiempo.

La segunda es una nota de seguridad disfrazada de contabilidad. instructions es texto en lenguaje natural, escrito por quien creó el servidor, que acaba en el prompt del host, y las descripciones de las herramientas que lo acompañan son lo mismo. La especificación dice qué hacer con eso en sus propios principios de seguridad: las anotaciones y descripciones de herramientas «should be considered untrusted, unless obtained from a trusted server», y los hosts «must obtain explicit user consent before invoking any tool».¹ Conectar un servidor MCP no es añadir una dependencia. Es conceder a un desconocido 1.619 tokens de tu system prompt y el derecho a ser llamado. El capítulo 30 trata de lo que ocurre cuando ese desconocido es hostil.

Todo en esta sección es cierto para la revisión del protocolo 2026-07-28, la actual, leída el 7 de septiembre de 2026. Las revisiones se fechan como YYYY-MM-DD y la fecha es la última vez que se hizo un cambio incompatible hacia atrás.¹⁰ El documento normativo es un archivo TypeScript, schema/2026-07-28/schema.ts; el JSON Schema que lo acompaña se genera a partir de él, por eso aquí la especificación se lee en TypeScript y por eso enseñar MCP desde cualquier otra cosa es enseñar una traducción.

El cambio de gobernanza bajo esa tabla importa más que cualquier fila concreta. Esta revisión adoptó una política de ciclo de vida de funciones y deprecación: las funciones son Active, Deprecated o Removed, una función deprecated documenta su ruta de migración y permanece en la especificación al menos doce meses antes de ser elegible para eliminación, y hay un registro que lista todo lo que está actualmente en estado Deprecated.⁸ Antes de esa política, «deprecated» en un protocolo de IA significaba lo que dijera el último post del blog. Ahora significa una fecha.

Este es el vocabulario de todo el bloque en un solo lugar.

Dos de ellos merecen una frase cada uno, porque ahí es donde vive realmente la confusión.

MCP frente a A2A no es una rivalidad, y ambas especificaciones lo dicen. La documentación de A2A traza la línea por lo que hay al otro extremo: MCP «defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API», donde una herramienta realiza «specific, often stateless, functions»; A2A aborda agents, «more autonomous systems» que «reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues». Su propio resumen es la frase que debes recordar: «A2A is about agents partnering on tasks, while MCP is more about agents using capabilities».¹¹ Los dos se anidan: una aplicación usa A2A para llegar a otros agents, y cada agent usa MCP para llegar a sus propias herramientas. El capítulo 25 trazó esa línea dentro de un proceso, entre pedir a un sub-agent y entregarle la conversación; A2A la traza entre organizaciones.

MCP frente a ACP es una comparación con una premisa caduca, que es exactamente por lo que merece la pena responderla. Agent Communication Protocol era un estándar abierto separado para mensajería agent-to-agent. Su propia documentación ahora abre con el aviso: «ACP is now part of A2A under the Linux Foundation!»¹² La respuesta honesta a «¿MCP o ACP?» en septiembre de 2026 es que la pregunta tiene una opción menos de lo que sugieren las páginas que posicionan para ella.

Y la comparación que más pide la gente, mcp vs api, tiene la respuesta menos interesante: MCP es una API. Lo que añade no es potencia, sino convenciones: un conjunto fijo de nombres de métodos, una llamada de descubrimiento, una jerarquía de control sobre las primitivas y un modelo de aislamiento. Renuncias a la libertad de diseñar tu propia interfaz y obtienes todos los hosts que hablan el protocolo, que es el intercambio que todo protocolo ha ofrecido siempre.

Ahora puedes leer la especificación sin traductor, distinguir un recurso de una herramienta y de un prompt por quién manda sobre él, escribir una petición a mano cuando una biblioteca de cliente te está mintiendo, y fechar cualquier artículo sobre MCP que leas por cuáles de las funciones deprecated sigue enseñando como actuales.

Lo que no has hecho es publicar uno. El capítulo 27 escribe el mismo servidor dos veces —TypeScript y Python, lado a lado—, porque MCP es el único territorio genuinamente bilingüe de este curso y los números lo dicen en ambas direcciones. Cubre bien los dos transportes vivos, el inspector, el empaquetado y la mitad del protocolo que este capítulo ha dejado deliberadamente aparte: autorización. Porque en el momento en que tu servidor es remoto y no un subproceso en tu propio portátil, el cliente de un desconocido presentará un token, y la regla de la especificación sobre qué puedes hacer con él es inusualmente estricta.

Lo que plantea la pregunta que tiene que responder el próximo capítulo, y no es amable: si llega un token a tu servidor y fue emitido para la audiencia de otra persona, ¿qué impide exactamente que lo reenvíes?

Cada cita, nombre de método, código de error y regla de este capítulo se leyó en la especificación de Model Context Protocol, revisión 2026-07-28, el 7 de septiembre de 2026. Cada traza se produjo localmente en Node 22: el servidor de calendario de juguete tiene 101 líneas y ninguna dependencia, y el servidor de referencia es el paquete npm publicado que se nombra abajo. No se llamó a ninguna API de pago para escribir este capítulo: nada aquí necesita un modelo, que es precisamente la idea.

Las mediciones: @modelcontextprotocol/server-everything@2026.8.31, publicado el 31 de agosto de 2026, construido sobre @modelcontextprotocol/sdk@1.30.0, publicado el 27 de julio de 2026, un día antes de la revisión que describe este capítulo. Responde a server/discover con -32601, negocia 2025-11-25 cuando se le pide 2026-07-28, y sirve tools/list sin ningún handshake. Su catálogo son 13 herramientas en 7.663 bytes; los recuentos de tokens son o200k_base mediante tiktoken, sobre name, description y inputSchema de cada definición, que es lo que un proveedor renderiza en tu prompt y no lo que pesa el frame JSON-RPC.

Anthropic, Code execution with MCP: building more efficient agents, 4 de noviembre de 2025, es la fuente de la cifra de 150.000 a 2.000, citada y usada en el capítulo 24 y solo referenciada aquí.