ndxr provides 10 well-structured tools with complete JSON schemas and descriptions. All tools have clear verb-noun naming (run_pipeline, get_context_capsule, search_memory, etc.) and detailed parameter documentation. However, descriptions are often technical and lengthy (200+ chars), optimized for developers rather than LLM selection. Output schemas are documented in code but not exposed in tool definitions. Error handling guidance is minimal, tools lack recovery hints for common failure modes. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Add tool annotations: mark read-only tools with readOnlyHint=true; mark save_observation and reindex_workspace with destructiveHint=true. This enables LLM safety guardrails.
• Shorten descriptions to 50-100 chars and add a 'When to use' clause. E.g., 'run_pipeline: Execute full indexing and search. Use when you need comprehensive code context for a task.' vs. current 150+ char technical description.
• Document output schemas in tool definitions. For get_skeleton, add: 'Returns array of {path, skeleton, symbol_count, original_lines}'. For get_impact_graph, add: 'Returns array of {fqn, kind, file_path, depth, direction}'.
• Add error recovery hints to descriptions. E.g., 'get_impact_graph: If symbol not found, verify FQN format (e.g., crate::module::function) or use search_memory() to find the correct FQN.'
• Expand get_index_status description and document its return value. Clarify whether it returns index size, file count, last-indexed timestamp, or all three. Distinguish from list_sessions.

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

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