Capítulo 3 — Primitivas del servidor: exponer contexto y capacidades

Tercera entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que aprendemos qué puede decir realmente un servidor MCP — tres sustantivos, tres ciclos de vida, tres modelos de error — y por qué la disciplina de elegir el correcto decide si un servidor escala o se va llenando de capas.

Por qué existe este capítulo

Un protocolo vale lo que valgan las cosas que te deja decir. El Capítulo 2 construyó el modelo mental de host, cliente y servidor, y vio cómo una sesión cobraba vida a través de la negociación de capacidades. Una vez completado el saludo y conociendo cada parte lo que la otra puede hacer, ¿qué hay concretamente sobre la mesa? MCP responde con tres sustantivos: Recursos, Prompts y Herramientas. Se parecen superficialmente — cada uno es una cosa con nombre y descrita por esquema que el servidor puede producir o ejecutar — pero corresponden a tres intenciones distintas. Los Recursos son estado de lectura. Los Prompts son andamiaje reutilizable. Las Herramientas son acciones de escritura. El capítulo recorre cada uno por turno: esquema, ciclo de vida, modelo de error y los sitios donde los ingenieros se equivocan.

3.1 Recursos: datos contextuales de sólo lectura

Un recurso es datos que el servidor puede entregar al modelo como contexto. La palabra clave es sólo lectura. Un recurso no muta el mundo; lo describe. Si una lectura provoca un cambio de estado en otro sitio — una fila en un log de auditoría, un contador que sube, un webhook que se dispara — no es un recurso, es una herramienta disfrazada. Trazar esta línea con nitidez es la primera disciplina del diseño de servidores MCP.

Cada recurso tiene una URI estable en un esquema que el servidor elige (file://, postgres://, linear://issue/ENG-1234), más metadatos: nombre, descripción opcional, tipo MIME, tamaño opcional. Ninguno de estos campos es decorativo. Un recurso sin descripción es uno que el modelo no puede evaluar. El ciclo de vida es directo: resources/list para enumerar, resources/read para obtener. No hay resources/write — si el servidor quiere escrituras, debe exponer una herramienta. La asimetría mantiene visible la frontera de confianza.

Dos patrones hacen prácticos los recursos a escala. Las plantillas de URI permiten al servidor exponer un endpoint de lectura parametrizado (db://orders/{order_id}) en vez de enumerar millones de filas. Las suscripciones dejan al host registrar interés por una URI y recibir notifications/resources/updated cuando los datos subyacentes cambian — la alternativa es el polling a cadencia LLM, derrochador en ambas direcciones. La trampa que conviene evitar es volcar todo objeto interno en la lista de recursos al arranque de la sesión: una lista de tres mil recursos se come decenas de miles de tokens antes de que el usuario haya escrito nada. Expón un primer nivel curado más plantillas, y deja que el modelo busque la cola larga.

3.2 Prompts: plantillas y flujos reutilizables

Los prompts en MCP no tienen nada que ver con el system prompt de un LLM. Son plantillas reutilizables, definidas por el servidor, que un usuario — o un host en nombre de un usuario — puede invocar para arrancar una interacción concreta. Un prompt está más cerca de un comando de barra que de una personalidad. La idea es que un servidor pueda enviar patrones de interacción ya probados junto a las herramientas y los recursos que expone, para que el humano frente al teclado no tenga que recordar cómo formular la petición.

Un prompt tiene nombre, descripción opcional y una lista de argumentos. El host llama a prompts/list para descubrir, y luego prompts/get para expandir un prompt en una secuencia de mensajes que el host puede entregar a su bucle de modelo. El prompt puede referenciar recursos por URI, en cuyo caso el host los inserta antes de enviar. El servidor guioniza los turnos de apertura; el modelo continúa desde ahí.

La distinción entre prompts y mensajes de sistema importa. Un usuario que invoca /review_pr ve, en su registro de conversación, al asistente empezar a trabajar en una revisión — entiende qué arrancó, puede interrumpir, puede auditar. Si el servidor, en cambio, hubiera anexado en silencio instrucciones al system prompt del host, el usuario no sabría por qué el asistente se comporta de pronto distinto. Los prompts son andamiaje visible para el usuario; los system prompts son el marco del host. No conviene confundir los dos. La disciplina es que cualquier contenido de prompt que el usuario no aprobaría si se le mostrara explícitamente es un defecto.

3.3 Herramientas: acciones, salidas estructuradas, idempotencia

Las Herramientas son donde MCP se vuelve interesante y peligroso a partes iguales. Los Recursos son lectura; los Prompts son andamio; las Herramientas son escritura — crean filas, envían mensajes, despliegan servicios, cobran tarjetas. Toda herramienta tiene nombre, descripción y un esquema de entrada en JSON Schema. La descripción es el campo más importante de toda la superficie MCP, porque es el texto que el modelo usa para decidir si llamar a la herramienta, cuándo llamarla y con qué argumentos. Una herramienta cuya descripción dice "envía un correo" es una a la que el modelo recurrirá cuando aparezca cualquier intención con forma de correo. Una cuya descripción dice "envía un correo transaccional vía la plataforma de marketing, sólo a direcciones verificadas de clientes; no para correspondencia personal" es una que el modelo usa con más discriminación.

El modelo de error tiene dos canales. Un error de protocolo (argumentos mal formados, herramienta desconocida) devuelve un error JSON-RPC y es un fallo de encuadre. Un error de la herramienta (destinatario rebotado, disco lleno) devuelve una respuesta exitosa con isError: true y un bloque de contenido explicando lo ocurrido. La distinción importa: el modelo debe ver los errores de herramienta y adaptarse; el host debe ver los errores de protocolo y recuperar el transporte. Confundirlos le quita al modelo la información que necesita.

El MCP moderno soporta structuredContent junto al array de contenido en prosa, conformándose a un outputSchema declarado. El efecto compuesto a lo largo de una traza larga es real: salidas de herramienta cortas y estructuradas le dejan al modelo margen para razonar; salidas largas en prosa se comen el presupuesto de contexto. Dos disciplinas más merecen nombre. Minimalidad: doce herramientas bien descritas baten a sesenta en casi todos los benchmarks; expón find_users con un filtro estructurado en vez de list_users, get_user, search_users, count_users. Idempotencia: las tormentas de reintentos son inevitables; una herramienta que acepta una clave de idempotencia o usa un esquema determinista de identificador convierte las caídas de red en no-ops en vez de en incidentes de integridad de datos.

3.4 Composición: cómo cooperan las tres primitivas

Las primitivas son más útiles cuando funcionan juntas. Un servidor bien diseñado suele exponer algo de cada una: unos cuantos prompts para sembrar interacciones comunes, un pequeño conjunto de herramientas para las acciones que importan y un conjunto posiblemente grande de recursos que aportan el contexto. Un servidor de soporte podría exponer perfiles de cliente e historial de tickets como recursos, reply_to_ticket y escalate_ticket como herramientas, y /triage_ticket como un prompt que carga los recursos adecuados y pide al modelo que clasifique. Los prompts siembran; los recursos rellenan la situación; las herramientas cambian el mundo.

La tentación, una vez que ves lo flexibles que son las primitivas, es empujarlo todo a través de una sola. Puedes simular recursos con herramientas de sólo lectura, simular herramientas con prompts que empujan al modelo a emitir comandos, simular prompts con recursos que contienen instrucciones. Cada atajo comprime el espacio de diseño y pierde algo. Recursos simulados como herramientas no se pueden cachear, suscribir ni insertar en una expansión de prompt. Herramientas simuladas como prompts no se pueden autorizar en el sitio de llamada ni tienen canal de salida estructurada. Las primitivas no son arbitrarias; están factorizadas para que el host sepa cómo tratar cada una con seguridad. Respetar la factorización es parte del contrato del protocolo.

Lo que prepara el Capítulo 3

Has recorrido el lado del servidor del trato. Un servidor expone Recursos, Prompts y Herramientas, cada uno con su esquema, su ciclo de vida y su modelo de error. La disciplina consiste en elegir la primitiva correcta para cada cosa que el servidor pueda hacer, nombrarlas y describirlas con cuidado, y resistir la sobrecarga. Pero MCP no es una calle de un solo sentido. Un host también puede exponer capacidades de vuelta al servidor — y ahí es donde viven algunas de las decisiones más interesantes y más sensibles a la seguridad del protocolo.

Próximamente — Capítulo 4: Primitivas del cliente — Sampling, Roots, Elicitation. La superficie inversa — lo que el host le devuelve al servidor — y las implicaciones de seguridad de cada capacidad entregada al otro lado de la frontera de confianza.