Provenlens exposes 10 code-analysis tools with consistent naming (verb_noun pattern: searchSymbols, getSymbol, callersOf, etc.) and reasonable descriptions (80 - 150 chars). All tools are READ_ONLY and well-scoped. However, input schemas lack critical details: parameter types are present but descriptions are minimal or missing for several params (e.g., 'limit' in searchSymbols has a description but 'kind' is vague). Output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is absent from visible code. No enum constraints on 'kind' parameter despite it accepting a known set of values (class, method, function, etc.). Parameter descriptions do not explain ranges, formats, or dependencies.

• Document output schemas for all tools. Specify field names, types, and nesting. E.g., searchSymbols returns [{id, name, kind, file, line, lang, ...}]. Include pagination info (total, next_cursor) if applicable.
• Convert 'kind' parameter to an enum in searchSymbols: ['class', 'method', 'function', 'interface', 'module', ...]. Add similar enums for any other constrained parameters.
• Add min/max bounds to numeric parameters: limit (1 - 1000), depth (1 - 10), repoId (>0). Document in parameter descriptions.
• Add error handling documentation: 'Returns 404 if symbol not found. Try searchSymbols() to discover available symbols.' Include examples of invalid composite IDs and how to fix them.
• Enhance parameter descriptions with format/dependency hints. E.g., 'symbolId: Composite ID in format repo:id (e.g., 2:481). Obtain repo ID from projectStats().' This guides multi-step planning.