Naveo

STEP 26 / 27

B1 TOOL-SCHEMA

DEFINÍ EL SCHEMA

Escribí el JSON Schema del tool inventory_mcp.

PROPÓSITO DEL TOOL

Diseñar un MCP completo de 3 tools para que un agente pueda gestionar
el inventario de repuestos críticos de la nave. El agente lo usará
en pedidos como:

- "¿cuántos reguladores de bay quedan en stock?"
- "marcá el cargador del bay 3 como low-stock"
- "agregá 12 filtros de aire de tipo H7 al inventario"

Tres tools mínimos para cubrir el caso:

1. `list_inventory_items(category?)`. lectura. Lista items con sus stocks.
   category es opcional para filtrar (ej: "regulator", "filter", "charger").
2. `add_inventory(item_id, quantity, location)`. escritura. Suma unidades
   a un item existente. Devuelve el nuevo total.
3. `mark_item_low_stock(item_id, reason)`. escritura. Marca un item como
   requiring re-supply. reason es texto libre (motivo del aviso).

Tu trabajo: el JSON completo con las 3 definiciones. Las descripciones
tienen que ser tan buenas que un agente las elija correctamente sin
que vos tengas que orientar la conversación.

INVOCACIONES DE EJEMPLO

list_inventory_items(category: "regulator") → {items: [{item_id: "reg-bay-001", name: "...", stock: 4, location: "vault-A"}, ...]}
add_inventory(item_id: "filter-H7", quantity: 12, location: "vault-A") → {ok: true, new_stock: 28}
mark_item_low_stock(item_id: "charger-bay-3", reason: "Falla intermitente, conviene reponer antes del próximo ciclo") → {ok: true}

TU SCHEMA

585 CARACTERES

9 CRITERIOS

MODO INVITADO

Estás viendo esta lección como invitado. Para guardar tu progreso, ganar XP y mantener tu racha, inicia sesión cuando estés listo para comprobar.

Cuesta 1 vida

Tu primer MCP completo

Hasta ahora cada tool fue un caso aislado. El capstone es el MCP entero: 3 tools que cubren un dominio (inventario de repuestos críticos), diseñadas para que un agente las elija solas, sin instrucciones extras del usuario.

El escenario

Forge tiene un registro de repuestos críticos. Quiere que un agente pueda:

Consultar el stock. "cuántos reguladores quedan?"
Reponer items. "agregá 12 filtros H7 al vault-A"
Marcar items para reposición. "el cargador del bay 3 está fallando, marcalo low-stock"

Tres tools cubren todo el dominio. Tu trabajo: diseñar el JSON Schema completo del MCP, con las descripciones tan precisas que el agente sepa cuál usar para cada pedido, sin que vos tengas que orientar la conversación.

Lo que tiene que estar bien

8 criterios. los 5 primeros deterministas (estructura, required correctos), los últimos 3 con LLM-judge sobre la calidad de las descripciones:

JSON válido.
Los 3 tools definidos.
list_inventory_items.category es opcional (NO en required).
add_inventory tiene 3 required.
mark_item_low_stock tiene 2 required.
Las descripciones distinguen lectura vs escritura.
Al menos una description dice cuándo NO usar el tool.
Al menos una description menciona el patrón de uso encadenado.
Todos los parámetros tienen description.

Cómo se aplica todo lo del track

Unidad	Habilidad	Cómo aparece acá
1 · Qué es un tool	Las 3 tools tienen name + description + parameters
2 · Schema craft	Nombres claros, required correctos, enums donde aplique, outputs documentados
3 · Descripciones que el LLM lee	Criterios 6, 7 y 8: lectura vs escritura, cuándo NO usar, sugerencia de composición
4 · Handlers de producción	Aplica al handler real (no a este schema). Pensá idempotencia: `add_inventory` llamado 2× debe sumar 2×, no 1×. Y mensajes de error accionables.
5 · Composición y catálogo	Criterio 8: el patrón `list_inventory_items` → `mark_item_low_stock` tiene que estar sugerido
6 · Estado, scope, debugging	Pensá: ¿qué scope necesita cada tool? `list` es read-only, las otras dos modifican estado. ¿El agente tiene autorización para escribir?

Si tu MCP pasa los 9 criterios deterministas y judge, podés confiar que un agente lo va a usar bien sin que tengas que babysittear cada conversación.

Cuando pase, Forge firma tu primer MCP. Quedás habilitado para diseñar tools de verdad. los que se usan en producción, no en demos.