¿Qué es un servidor MCP? Tools, resources y prompts explicados | We.Inc
Un servidor MCP es un programa que ofrece tools, resources y prompts a aplicaciones de IA mediante el Model Context Protocol. Mira los mensajes JSON reales, paso a paso.
¿Qué es un servidor MCP?
Un servidor MCP es un programa que da a las aplicaciones de IA algo con lo que trabajar mediante el Model Context Protocol: tools que pueden invocar, resources que pueden leer y prompts que los usuarios pueden elegir. La aplicación se conecta a través de un cliente MCP, y ambas partes intercambian mensajes JSON-RPC 2.0 por stdio en local o por Streamable HTTP en remoto.
Las tres cosas que puede ofrecer un servidor
Primitiva
Qué es
Quién decide usarla
Métodos principales
Tools
Funciones que realizan una acción, con un JSON Schema para su entrada
El modelo
tools/list, tools/call
Resources
Datos de solo lectura identificados por una URI, como un archivo o un esquema
La aplicación
resources/list, resources/read
Prompts
Plantillas de instrucciones reutilizables con argumentos
El usuario
prompts/list, prompts/get
Recorre abajo un intercambio real paso a paso. Cada paso muestra el JSON que envía un cliente y lo que responde el servidor, con las formas de mensaje de la especificación actual (versión 2026-07-28). Leer los mensajes en bruto es la forma más rápida de dejar de ver un servidor como algo mágico.
Elige un paso: descubrimiento, listado de tools, invocación de una tool o recepción de una notificación de cambio.
Lee la petición a la izquierda y la respuesta a la derecha.
Revisa la nota bajo cada par para ver el campo que más importa en ese paso.
Copia cualquier mensaje para compararlo con lo que envía tu propio servidor o cliente.
Pon a las tools un prefijo claro, como weather_current en lugar de get. Un host puede cargar tools de muchos servidores a la vez, y los nombres vagos chocan entre sí.
Escribe la descripción de cada tool para el modelo, no para una persona que ojea una lista. Di qué hace la tool y cuándo debe elegirse.
Expón el contexto de solo lectura como resources en lugar de tools. Los resources permiten que la aplicación decida qué incluir, lo que evita que el modelo pida datos que no necesita.
Trata como arriesgada cada tool que modifica algo. El protocolo deja la aprobación al host, así que diseña tools que se puedan confirmar con seguridad de una en una.
Preguntas frecuentes
¿Un servidor MCP es lo mismo que una API?
Normalmente envuelve una. Un servidor típico recurre a una API o base de datos existente y describe esas operaciones de forma estándar, para que cualquier aplicación compatible con MCP pueda descubrirlas e invocarlas sin código de integración a medida.
¿Un servidor MCP se ejecuta en mi ordenador o en la nube?
En cualquiera de los dos. Un servidor local lo arranca la aplicación y se comunica por la entrada y la salida estándar. Un servidor remoto se ejecuta en otro lugar y se accede a él por Streamable HTTP, donde puede atender a muchos clientes.
¿Un servidor MCP contiene un modelo de lenguaje?
No. El servidor solo ofrece tools, resources y prompts. La aplicación host es dueña del modelo y decide qué enviarle. La especificación marca como obsoleto el sampling solicitado por el servidor a partir de la versión 2026-07-28.
¿Qué cambió en la versión 2026-07-28 del protocolo?
El protocolo pasó a ser sin estado: cada petición lleva la versión del protocolo y las capacidades en su campo _meta, y los servidores responden a una petición server/discover obligatoria. Las notificaciones de cambio ahora son opcionales mediante un stream subscriptions/listen.
¿Quién aprueba la invocación de una tool?
El host. La documentación del protocolo sugiere diálogos de aprobación, ajustes de permisos y registros de actividad, pero aplicarlos es tarea de la aplicación, así que un servidor nunca debe suponer que una persona revisó una invocación.
Host, cliente y servidor
En cada configuración aparecen tres roles. El host es la aplicación de IA que usa la persona. Por cada servidor al que se conecta, el host crea un cliente, y cada cliente mantiene una conexión dedicada con exactamente un servidor.
Así, un host conectado a un servidor de archivos y a un servidor de base de datos tiene dos clientes. El servidor es simplemente el programa que responde, esté donde esté.
Dos capas: datos y transporte
La capa de datos define los mensajes: peticiones, respuestas y notificaciones JSON-RPC 2.0 para el descubrimiento, las tools, los resources y los prompts. La capa de transporte mueve esos mensajes y se encarga de establecer la conexión y de la autorización.
Hay dos transportes estándar. Stdio pasa los mensajes por la entrada y la salida estándar entre procesos de una misma máquina. Streamable HTTP usa HTTP POST del cliente al servidor, con Server-Sent Events opcionales para el streaming, y admite bearer tokens, API keys y OAuth.
Lo que el cliente puede ofrecer a cambio
Los servidores también pueden pedirle cosas al cliente. La elicitation permite que un servidor solicite más información o una confirmación al usuario mediante el método elicitation/create.
El sampling, en el que un servidor pide al host una respuesta del modelo, y el logging a nivel de protocolo están obsoletos desde la versión 2026-07-28. Los servidores nuevos deben registrar en stderr cuando usan stdio o usar OpenTelemetry.
¿Stdio o Streamable HTTP?
Cómo elegir un transporte
Stdio
Streamable HTTP
Dónde se ejecuta el servidor
En la misma máquina, arrancado por el host
En cualquier lugar accesible por la red
Cómo viajan los mensajes
Streams de entrada y salida estándar
HTTP POST, Server-Sent Events opcionales
Clientes típicos por servidor
Uno
Muchos
Autenticación
No hace falta, es un proceso local
Bearer tokens, API keys, cabeceras personalizadas; se recomienda OAuth
Dónde registrar logs
stderr (stdout lleva los mensajes del protocolo)
Los logs habituales de tu servidor
Cómo es una plantilla de resource
Una plantilla de resource con un parámetro en la URI
Los clientes encuentran las plantillas con resources/templates/list, rellenan las llaves y leen el resultado con resources/read.
1. Descubrimiento
server/discover es opcional para el cliente, pero todo servidor debe responderlo. El objeto capabilities indica qué primitivas existen; listChanged significa que el servidor puede notificar cambios en las tools.
2. Listar tools
Cada tool lleva un name, una description y un inputSchema escrito en JSON Schema. El host se los pasa al modelo para que sepa qué puede invocar.
3. Invocar una tool
El nombre debe coincidir exactamente con la tool listada y los argumentos deben encajar con su inputSchema. Los resultados vuelven como un array content, aquí con un único elemento de texto.
4. Notificación de cambio
Las notificaciones no tienen id, así que nada les responde. El cliente solo recibe esta porque abrió un stream subscriptions/listen pidiendo toolsListChanged.