Codescope provides 9 well-named, verb-prefixed tools (cs_index, cs_callers, cs_callees, etc.) with clear descriptions (avg ~80 chars). However, critical gaps undermine production readiness: (1) Most parameter descriptions are minimal or absent. cs_index has an empty input schema with no description of what 'building' means or side effects. (2) No output schemas documented, LLMs cannot predict return structure or chain tools. (3) Parameter constraints missing: depth defaults to 3 but no min/max stated; max_tokens unbounded. (4) No error handling guidance, tools fail silently or return generic errors. (5) Tool descriptions lack WHEN/WHY context. E.g., cs_blast_radius says 'Everything downstream-affected' but doesn't explain when to use it vs cs_callees. Naming is strong (verb_noun pattern, 18-char avg), but schema and parameter documentation are severely underdeveloped.

• Document output schemas for all tools. E.g., cs_callers should return {callers: [{symbol: string, file: string, line: number}], total: number, truncated: boolean}.
• Add min/max constraints to numeric parameters: depth 1 - 10, max_tokens 100 - 100000. Document defaults in descriptions.
• Expand cs_index description to explain side effects: 'Builds or incrementally refreshes the structural index. Writes to .codescope/idx.redb. Idempotent, safe to call repeatedly. Returns IndexStats with files_indexed, symbols, edges, elapsed_ms.'
• Add WHEN/WHY context to tool descriptions. E.g., 'cs_blast_radius: Use when assessing impact of a change. cs_callees: Use to understand what a function does. cs_callers: Use to find dependent code.'
• Document cs_structural_search query syntax with examples: 'kind:function calls:db_query returns:Result', explain kind, calls, returns operators and valid values.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry