Novgraph tools have basic schemas and descriptions but significant gaps. All 11 tools have descriptions (10-100 chars, mostly adequate) and input schemas with type definitions. However, parameter descriptions are minimal or absent, most params lack guidance on format, constraints, or dependencies. Output schemas are undocumented; responses are opaque to the LLM. Error handling is not visible in tool definitions. Tool naming follows verb_noun convention (novgraph_*) but is generic and domain-specific rather than action-oriented (e.g., 'novgraph_why' vs 'explain_code_constraints'). No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinction. One write tool (novgraph_record_why) lacks confirmation or dry-run pattern. Composition is reasonable, tools are single-purpose, but chaining is unclear without documented output schemas.

• Document output schema for every tool. Specify field names, types, and whether results are paginated. Example: novgraph_search should return {results: [{symbol: string, file: string, line: number}], total: number, next_cursor?: string}.
• Add parameter constraints to descriptions. For 'precision' in novgraph_why, specify valid values (e.g., 'general|detailed|minimal'). For 'limit', specify range (e.g., '1-100, default 20'). For 'budget_tokens', specify range and impact.
• Add tool annotations: mark all read-only tools with readOnlyHint=true; mark novgraph_record_why with destructiveHint=true and add a confirmation pattern (dry-run or explicit approval).
• Rename tools for clarity: novgraph_why → explain_code_constraints; novgraph_connections → find_symbol_relationships; novgraph_impact → analyze_change_impact. Verb-first names help LLMs parse intent.
• Document error responses with recovery guidance. Example: 'Codebase not found. Call novgraph_codebases() to list available codebases.' Include error classification (retryable, user-fixable, fatal).