Loading ToolBench
Lookbook — MCP server and packet compiler that routes frontend briefs through a curated design library.
Lookbook-MCP has 15 tools with complete JSON schemas and descriptions, but suffers from critical naming and composition issues. Tool names lack clear action verbs (resolve_design_context, inspect_design_library, get_source_excerpt are acceptable, but route_alternatives and prepare_golden_build_arena are vague). Many tools accept 15+ parameters with overlapping concerns, resolve_design_context and export_opencode_bundle share nearly identical parameter sets, violating single-responsibility principle. Descriptions are present (100-300 chars) but generic; they state WHAT without explaining WHEN to use each tool or how they differ. Parameter descriptions exist but lack constraints (enums, ranges, patterns). No output schemas documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. Security: no evidence of secret injection, permission gates, or audit trails. The server is functional but would not pass production code review.
Inspect donor leakage risk: scan all source files for hardcoded identifiers, credentials, or domain-specific copy that should not appear in generated code.
Build a semantic embedding index for all anchor packs using a local or remote embedding model.
Build a visual feature index for all anchor packs by analyzing screenshots and source structure.
Analyze code density and complexity metrics for a pack or example.
Identify underutilized or never-routed donor packs that may indicate gaps in the design library.
Write an unbounded PACKET.md, capacity telemetry, and complete relevance-selected SOURCE to a filesystem bundle for hand-off to external build systems.
Duplicate parameter sets across tools. resolve_design_context and export_opencode_bundle share 18+ identical parameters (surface, task, stack, tone, layout_mode, constraints, etc.), violating single-responsibility principle. LLMs cannot distinguish when to use each tool.
No output schemas documented. Tools return results but LLMs have no visibility into response structure, field names, or types. Agents cannot plan downstream calls or extract required data reliably.
Parameters lack enums and constraints. Fields like 'route_profile', 'rerank_mode', 'code_profile', 'tier' accept free-form strings with no declared valid values. LLMs hallucinate invalid options.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Expand one route-qualified optional Pattern Card by exact pattern_id. Returns only that card at tier S, M, or L; foreign or unqualified patterns are rejected.
Load targeted anchor/example code after routing. Selected source files are returned complete; legacy character-limit arguments are ignored.
List packs, vertical rules, and optional per-example local source inventory without loading full donor source text.
Prepare a golden build arena: a controlled environment for testing design routing and code generation against known-good reference implementations.
Resolve a frontend design task into an anchor-first packet. Use code_profile='code_first' for implementation-heavy local model builds.
Generate alternative routing decisions for a brief, showing top-k candidates with confidence scores and reasoning.
Analyze routing decisions and confidence scores from the telemetry ledger to identify low-confidence or abstained routes.
Execute a golden build arena test suite against the current design library and routing configuration.
Run setup checks: verify manifest integrity, index consistency, and routing readiness.
No error handling or recovery guidance. Tools provide no error messages, categorization (retryable vs fatal), or next-step hints. Agents cannot self-correct or diagnose failures.
Vague tool names and descriptions. 'prepare_golden_build_arena', 'route_alternatives', 'donor_starvation_audit' lack clarity on when to invoke them vs similar tools. Descriptions do not explain WHEN or WHY to use each tool.