The systems layer around an agent: a spec-correct MCP server, supervisor/worker orchestration with detectable failure modes, and enforced cost governance.
Three tools with basic schemas and minimal descriptions. All tools have input schemas with required parameters properly defined (hospital_id, sku, units). However, descriptions are extremely terse (10-30 chars), falling well below the 194-char baseline for production tools. No parameter-level descriptions exist, LLMs cannot infer what 'hospital_id' or 'sku' represent without additional context. Tool annotations (destructiveHint/readOnlyHint) are present in the wire format, which is good. Error handling in the server catches exceptions and returns isError=true, but tool-level error guidance is absent. No output schema documentation. The server code is well-structured and implements proper version negotiation and JSON-RPC error handling, but the tool definitions themselves lack the depth needed for reliable LLM selection and execution.
Days of cover for a hospital. Args: hospital_id.
Supplier lead time in days. Args: sku.
Raise a replenishment PO. Args: hospital_id, sku, units.
Parameter descriptions completely missing. 'hospital_id', 'sku', 'units' have no descriptions explaining what they represent, their format, or constraints. LLMs cannot infer meaning from names alone.
Tool descriptions are 10-30 characters, far below the 194-char baseline. 'Days of cover for a hospital. Args: hospital_id.' lacks context on when to call this tool, what 'days of cover' means, or how to interpret the result.
No output schema documentation. Clients cannot predict what get_inventory or get_lead_time return (numeric value? object with metadata? array?). This forces LLMs to guess and wastes tokens on trial-and-error.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Destructive tool (raise_purchase_order) lacks confirmation or dry-run capability. No guidance on recovery if the PO is raised in error. Agents can trigger irreversible state changes without safeguards.
Parameter 'units' has no type constraints (min/max). An LLM could pass 0, negative, or absurdly large values. No validation guidance in the description.