The server has 5 tools with complete input schemas and descriptions, but quality varies significantly. All tools accept project path, file, and function name parameters with clear descriptions following a consistent pattern. However, there are critical issues: (1) duplicate tool definitions (func_code and get_snippet are identical), (2) generic descriptions that could be more LLM-optimized, (3) missing output schema documentation, (4) no error handling guidance, and (5) no pagination/result limiting for potentially large outputs. The tool descriptions are adequate (145-280 chars) but lack specific guidance on when to select one tool over similar ones. Parameter descriptions are present and reasonably detailed (28-85 chars), meeting the 'every param needs description' requirement, though some could be more constraint-focused (e.g., no guidance on depth parameter bounds or output size warnings).

• Remove get_snippet. It is a duplicate of func_code. Choose one canonical name and deprecate the other.
• Document output schemas. For each tool, specify: full_report returns {report: string, function_count: int, ...}; func_code returns {source: string, line_count: int, ...}; etc. This enables LLMs to extract relevant data and plan follow-up calls.
• Add pagination to full_report, ref_types, and called_funcs. Include parameters like limit (default 20) and cursor. Document: 'Results may be paginated if depth > 2 or result count > 50. Use cursor from response to fetch next page.'
• Constrain depth parameter: min=1, max=5 (or justified max). Add to description: 'Depth must be 1-5. Depth > 3 may timeout for large codebases.'
• Enhance error messages. When a function is not found, return: 'Function "func_name" not found in "file.go". Try calling called_funcs(...) with an existing function from the same file, or use full_report(...) on a nearby function to discover available names.'
• Add readOnlyHint=true to all tool definitions (via mcp-go framework if supported) to signal to clients that these tools never modify state.
• Rename func_code and get_snippet to more specific names. Suggestions: get_func_source_code (tool), get_function_implementation (tool), analyze_call_tree (tool for called_funcs), map_type_deps (tool for ref_types). Current names are too generic.
• Document typical use case flows. E.g., 'Start with called_funcs(depth=1) to map immediate dependencies. Then use func_code on interesting functions to inspect implementation. Use full_report only when you need a comprehensive dependency matrix.'