Compile an API, an MCP server, or a database into a CLI your agent can run. Ten engines, one output contract.
Four tools with explicit schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. list_notes and add_note have reasonable input schemas with descriptions; boom and blob are minimal. No output schemas visible in the source. Parameter descriptions exist but are sparse (e.g., 'how many bytes to return' lacks constraints). Tool names follow verb_noun convention (list_, add_, boom, blob) but 'boom' and 'blob' are vague and don't clearly signal intent. Error handling for boom is mentioned but not detailed. Overall: functional but below production baseline.
Add a note to the book
Return a payload of the requested size
Always reports a tool error
List notes, newest first.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess or make follow-up calls.
Tool names 'boom' and 'blob' are vague and do not clearly signal intent. 'boom' should be 'trigger_error' or 'test_error_handling'; 'blob' should be 'generate_payload' or 'create_large_response'.
Parameter 'bytes' in blob tool lacks constraints (min/max). LLMs could pass absurd values (negative, gigabytes) causing timeouts or crashes.
add_note requires 'title' and 'count' but 'count' purpose is unclear (copies of what?). Description should explain the semantic meaning and use case.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2025-06-18+ | v2 |
list_notes description states 'Everything after the first line is dropped', this is implementation detail, not user-facing guidance. Rewrite to explain when to call this tool and what it returns.