Diseño de servidores MCP

No hay un número correcto: la cantidad y el tamaño de las tools se deciden a partir de las tareas que el usuario quiere hacer, no copiando los endpoints de la API que hay detrás. El modelo elige qué llamar guiándose por el nombre, la descripción y el esquema de cada tool, de modo que un servidor mal dimensionado lleva al agente a equivocarse aunque el código funcione. En la lección se rehace nortia-pedidos desde un diseño ingenuo, que expone cada endpoint de la API interna como una tool, hasta uno pensado para producción.

Con identificadores: la especificación 2026-07-28 pide que cualquier estado que dure más de una petición se nombre con un identificador explícito, y que el cliente lo mande en cada llamada. Hacerlo bien importa, porque un estado guardado a escondidas en el proceso del servidor puede acabar mostrando a una persona los resultados de otra. En la lección se ve cómo diseñar esos identificadores para que los emita el servidor y queden ligados a quien llama.

Como errores de ejecución, es decir, un resultado normal marcado con isError: true y acompañado de un texto, que es lo que los clientes entregan al modelo para que corrija su siguiente paso. Ese texto es lo único que el modelo tiene para decidir si reintenta, pide algo al usuario o se detiene, así que redactarlo forma parte del diseño de la tool tanto como su esquema. En la lección se ve cómo escribir esos errores en un servidor real y cómo acotar además el tamaño de cada resultado.