Ejemplo práctico

Primero el host descubre qué ofrece cada servidor (server/discover, tools/list, resources/list, prompts/list), con la versión y las capacidades del cliente dentro de _meta en cada petición; después el modelo propone llamadas a tools, el host decide si las aprueba y el cliente las envía con tools/call; y al final el modelo redacta con los resultados. En la lección se sigue, mensaje a mensaje, una incidencia de soporte de Nortia que pasa por tres servidores (soporte, pedidos y facturación), separando lo que ve la persona, lo que recibe el modelo y lo que viaja por la red.

No: el protocolo no da a un servidor ningún canal para llamar a otro ni para ver lo que este devuelve. Cuando una tarea necesita varios sistemas, es el modelo quien junta la información y el host el que traslada, por ejemplo, el identificador de factura que obtuvo de un servidor a la llamada que hace a otro. Gracias a eso un servidor puede cambiar el sistema que tiene detrás sin que los demás lo noten, siempre que mantenga la definición de sus tools.

Con una clave de idempotencia que viaja como argumento de la tool y que el servidor guarda junto al resultado con una restricción de unicidad: si la misma clave vuelve a llegar, devuelve lo que ya hizo en lugar de repetirlo. Hace falta porque en la versión 2026-07-28 un stream cortado no se reanuda, y el cliente, sin saber si la operación terminó, solo puede reenviarla con un id nuevo, y el servidor la trata como si fuera otra. Es un dato de la aplicación ligado a un identificador explícito, no una sesión del protocolo.