Five tools with clear verb-noun naming (hi_ask, hi_multiline, hi_choose, hi_confirm, hi_notify) and consistent descriptions (50-120 chars). All parameters have type definitions and descriptions. However, output schemas are completely undocumented, no response structure defined for any tool. Error handling guidance is absent. Tool descriptions lack WHEN/WHY context and don't explain return values. Parameters like 'agent_name' are optional but lack guidance on when to use them. No mention of idempotency, side effects, or recovery paths.
Ask the human developer for a single-line text response. Use this instead of stopping the session to ask a clarifying question.
Present a list of choices to the human developer and return their selection(s). Use for branching decisions.
Ask the human developer to confirm or deny an action before the agent proceeds. Use before irreversible or sensitive operations.
Ask the human developer for a multi-line text response, such as a description, code snippet, or detailed feedback.
Send a non-blocking informational notification to the developer. Does not wait for a response. Use for status updates.
Output schemas completely undocumented. No response structure defined for any tool. LLMs cannot plan downstream operations or extract return values.
Descriptions lack WHEN/WHY context. 'Ask the human developer for a single-line text response' doesn't explain when to use hi_ask vs hi_multiline, or what the tool returns.
No error handling guidance. Tools don't document what happens if user cancels, times out, or provides invalid input. LLM has no recovery path.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Parameter 'agent_name' is optional but lacks guidance on when/why to provide it. Unclear if it affects routing, logging, or UI display.
hi_choose lacks enum constraint on 'choices' array items. Should document expected format (string, max length, character restrictions).