Loading ToolBench
Storybook-style static gallery generated from Compose @Preview / SwiftUI #Preview screenshots
Phonebook has 4 tools with basic schemas and descriptions, but significant gaps prevent production use. Tool names lack clear action verbs (phonebook_doctor, phonebook_generate, phonebook_build are domain-specific but not verb-first). Descriptions exist but are brief (10-60 chars) and lack context on when to use each tool or what happens on failure. Parameter descriptions are minimal, 'Path to the project directory' repeats across all tools without explaining validation, format, or error cases. No output schemas documented. Error handling is present in code (errorResult, textResult functions) but not surfaced in tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (phonebook_generate and phonebook_build are WRITE operations). The warnAboutPreviewlessFiles and explainIncompleteRender functions show sophisticated error recovery logic, but this is buried in implementation, not exposed to the LLM via tool descriptions or structured error responses.
Analyze preview coverage for components in the project
Build the static preview gallery site
Collect and report diagnostic checks for the Phonebook configuration and project setup
Generate preview screenshots for Android and iOS components
Tool names do not start with action verbs. 'phonebook_doctor', 'phonebook_generate', 'phonebook_build' are domain-specific but lack clarity. LLMs expect 'get_', 'create_', 'analyze_', 'run_' patterns. Rename to 'run_diagnostics', 'generate_previews', 'build_gallery', 'analyze_coverage' (last one is closer but still weak).
Descriptions are too brief (10-60 chars) and lack context. 'Collect and report diagnostic checks...' does not explain when to call this vs analyze_coverage, what 'diagnostic checks' means, or what happens on failure. Descriptions should be 50-200 chars and answer: WHAT, WHEN, and WHAT HAPPENS.
No output schemas documented. Code returns textResult() or errorResult() with unstructured text, but tool definitions do not declare what fields the LLM should expect. LLMs cannot plan downstream calls or extract structured data without documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
No tool annotations despite clear risk profiles. phonebook_generate and phonebook_build are WRITE operations (risk: WRITE) but lack destructiveHint or idempotentHint annotations. LLMs cannot reason about retry safety or side effects without these hints.
Parameter descriptions are generic and lack constraints. 'Path to the project directory' appears on all tools but does not specify: absolute vs relative, validation rules, error handling if missing, or examples. 'Optional list of specific files' (phonebook_generate) lacks format (glob patterns? file extensions? relative to projectDir?).