The server exposes 8 tools with basic schemas and descriptions. Most tools have input parameter schemas with type declarations and descriptions, which is good. However, the output schemas are not documented anywhere in the code, only input schemas are visible. Descriptions are present but minimal (many under 100 chars), lacking the LLM-optimized detail needed for reliable tool selection. Parameter descriptions are sometimes vague ('Search query' instead of specifying constraints or format). Critical tools like delete_nodes and clear_graph lack confirmation/dry-run patterns and have minimal error guidance. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Parameter naming is generally good (verb_noun convention), but the server lacks input validation documentation and recovery hints in error handling. The custom Requirement/Preference/Procedure types are well-documented in code but not exposed as first-class tool patterns.

• Document the full output schema for every tool. For example, add_events should document: {success: boolean, message: string, extracted_entities: [{type: string, ...}], graph_updates: {...}}.
• Add tool annotations: readOnlyHint for search_* and get_*, destructiveHint for delete_nodes and clear_graph. This aligns with the risk labels already in the code.
• Expand search tool descriptions to 150-200 chars. Explain the semantic vs hybrid vs keyword distinction. For example: 'Hybrid search combines keyword and vector similarity. Use for natural-language queries. Keyword search is faster for exact terms.'
• Add a confirmation_required boolean output to destructive operations, or create a separate dry-run parameter. For clear_graph: 'Caution: This permanently deletes all graph data. Call with confirm=true after reviewing the statistics via get_graph_statistics.'
• Document parameter constraints in descriptions. For limit: 'Maximum number of results to return (1-1000, default 20).' For node_ids: 'Array of UUIDs (36-char hex strings).'
• Create a separate confirm_clear_graph tool or add a required confirmation_token parameter to clear_graph, with a method to obtain the token from get_graph_statistics. This prevents accidental wipes.
• Add recovery hints to error responses. For example, if search_nodes returns 0 results: 'No nodes found. Try search_facts or search_episodes, or call add_events to populate the graph.'
• Document what extract_entities does in add_events. List available entity types (Requirement, Preference, Procedure) and the structure of extracted_entities in the response.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry