CodeWell has 16 tools with complete input schemas and descriptions present for all tools and parameters. Naming follows verb_noun convention (index_workspace, search_code, trace_symbol). However, descriptions are often generic and lack actionable context for LLM selection. Many tools accept optional db_path and library_root parameters that create parameter relationship complexity without clear documentation of mutual exclusivity or precedence. Output schemas are not documented, LLMs cannot predict return structure. Error handling is minimal (generic RuntimeError wrapping). No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinctions. Parameter descriptions lack format constraints, ranges, or examples of valid values.

• Add output schema documentation to all tools. Specify return object structure with field names, types, and descriptions. Example: 'Returns {results: [{path: string, snippet: string, score: float}], total: int, next_cursor?: string}'.
• Add tool annotations via FastMCP. Mark read-only tools with readOnlyHint=true and destructive tools (index_workspace, apply_library_repair_plan, apply_library_repair_policy, store_revision, store_failure) with destructiveHint=true.
• Document parameter relationships explicitly. For tools accepting both db_path and library_root, state: 'If library_root is provided, db_path is ignored. If neither is provided, uses default location.' Add to get_context_pack, search_code, trace_symbol.
• Replace generic error handling with categorized, actionable errors. Example: 'FileNotFoundError: Database not found at {path}. Try index_workspace() first to create it.' Include recovery hints for each error type.
• Add enum constraints and ranges to parameters. For response_mode, define valid values (default, compact, detailed). For limit, state range (1-100). For token_budget, state range (1000-100000). Use JSON Schema enum and minimum/maximum fields.