13 tools with mixed quality. Most have basic descriptions (50-150 chars) and visible schemas, but critical gaps exist: parameter descriptions are sparse or missing entirely (e.g., 'depth' in get_minimal_context has no description), output schemas are undocumented, and error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint). Naming is verb-forward but some tools conflate concerns (e.g., create_handoff_packet + record_agent_review both write state). The find_alternatives tool stands out with detailed parameter descriptions and enum constraints; most others lack this rigor. Average tool score: 42/100.

• Add output schema documentation to every tool. Example: 'Returns {ok: boolean, context: {file: string, symbols: string[], dependencies: string[]}, elapsed_ms: number}'. This enables agents to plan downstream calls.
• Complete parameter descriptions. For numeric params (depth, max_depth, max_results, min_weekly_downloads), specify valid ranges and defaults. For string params (verdict, decision), document allowed values or constraints.
• Add tool annotations: mark read-only tools with readOnlyHint=true; mark destructive tools (build_or_update_graph, create_handoff_packet, record_*) with destructiveHint=true; mark idempotent tools with idempotentHint=true.
• Expand tool descriptions to 100-200 chars. Include WHEN to use each tool and what it returns. E.g., 'Get minimal context for a file or symbol to understand its dependencies and usages. Returns file path, symbol name, direct dependencies, and usage count. Use before making changes to assess impact.'
• Document error scenarios and recovery paths. E.g., 'If build_or_update_graph times out (>30s), the graph is still building in the background. Retry after 5s or check server logs. If it fails with 'invalid_repo_path', verify the path exists and is a git repository.'