Multi-model code review with ranked todos and subagent dispatch, inside Claude Code CLI
Server has 7 tools with clear verb-noun naming (compare_models, compare_run, compare_diff, compare_debate, compare_todos, compare_status, compare_todo_update). All tools have descriptions (10-200 chars, within baseline 34-392 range). Input schemas are present with type definitions. However, parameter descriptions are sparse or missing entirely, most parameters lack actionable constraints, format guidance, or dependency documentation. Output schemas are not documented. Error handling is minimal; tools return error dicts but lack recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is sound: tools chain logically (compare_run → compare_diff/debate → compare_todos → compare_status/update). Security: no secrets exposed as parameters (config loaded server-side). Overall: solid naming and basic structure, but parameter documentation and error guidance fall short of production baseline.
Run a debate round where each model critiques others' findings, then synthesize.
Diff provider responses: extract unique vs shared insights using fuzzy matching.
List all configured providers with their enabled status, type, and model. Does not expose API keys.
Fan out a code review to all enabled providers (or a subset) in parallel.
Return current todos grouped by status (pending, in_progress, done).
Update a todo's status.
Write ranked findings to the SQLite todo store.
Parameter descriptions lack actionable constraints. 'providers' in compare_run has no format guidance (array of what? valid provider names?). 'status' in compare_todo_update lacks enum constraint (docs say 'one of pending|in_progress|done' but schema has no enum). LLMs cannot infer valid values without explicit constraints.
Output schemas are not documented. Tools return dicts but LLMs cannot plan downstream calls without knowing response structure. E.g., compare_run returns {provider_name: {findings, ...}} but this is inferred from code, not declared. compare_todos returns {todos: [...], db_path: ...} but field types are opaque.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. compare_run returns {error: '...', enabled: [...], hint: '...'} which is good, but most tools have no error path documented. If compare_todos fails to write to SQLite, what should the LLM do? No guidance.
No tool annotations. Tools marked as READ_ONLY or WRITE in metadata but not exposed via readOnlyHint/destructiveHint in schema. LLMs cannot infer safety/idempotency without explicit annotations.
Parameter 'findings' in compare_todos expects array of {title, description, severity, source_providers} but schema shows only type:array with no items schema. LLMs cannot validate structure before calling.