The server defines 8 tools with complete input schemas and descriptions. All tools follow verb_noun naming conventions (build_, list_, clear_, graph_, search_, query_, export_, call_). Descriptions are present and reasonably detailed (averaging ~150 chars), though some lack critical context about when to use them vs. similar tools. Parameter descriptions are present for most inputs. However, output schemas are NOT documented anywhere in the codebase, the tool definitions show return types as Dict[str, Any] with no schema definition. This is a critical gap for LLM reasoning. Error handling is basic, no actionable recovery guidance visible. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write semantics. The code shows input validation (reject_control_chars, normalize_* functions) but error responses are not shown to be LLM-friendly. Tool composition is reasonable, each tool has a single responsibility. However, dependencies between tools (e.g., build_graph must be called before query_graph) are not explicit in descriptions.

• Document output schemas for all 8 tools. Example for build_graph: 'Returns {ok: bool, graph_id: string, node_count: int, edge_count: int, error?: string}'. Every field should be typed and described.
• Add tool annotations via fastmcp API (if supported) or update tool registration to include destructiveHint=true for clear_graph_cache and build_graph (when force_rebuild=true). Mark all others readOnly=true.
• Add docstrings to all tool functions explaining WHEN to use them. E.g., 'Use search_nodes to find functions by name substring; use query_graph to trace caller/callee relationships.' This helps LLMs disambiguate.
• In each tool description, state the prerequisite: 'Requires a graph_id from a prior build_graph() call.' and 'Use build_graph() first to create a graph before querying it.'
• Document error responses with actionable guidance. E.g., 'If graph_id is invalid, returns {ok: false, error: "Graph not found. Use list_cached_graphs() to see available graphs."}'.
• For list_cached_graphs, document the return schema: {ok: bool, graphs: [{graph_id: string, source_path: string, node_count: int, timestamp: string}, ...]}.
• Add limits to search_nodes and query_graph: 'depth parameter capped at 5; search results limited to 50 nodes. Use pagination via limit + offset if needed.' Currently depth is not bounded.
• For call_certainty_gemini, clarify that max_output_tokens is capped at 4096 (as mentioned in docstring) and document why: 'Limits response size to prevent excessive token consumption.' Update description to reflect this constraint.