N3MO provides 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (n3mo_index, n3mo_search_symbol, etc.). However, descriptions are minimal (34-72 chars, below the 50-200 char LLM-optimized baseline), lack WHEN/WHY context, and omit output schema documentation. Parameters have types and descriptions, but lack constraints (enums, ranges, patterns). No error handling guidance, no recovery paths, and no documentation of side effects or prerequisites. Tool composition is sound (each does one thing), but descriptions don't guide LLM selection or explain dependencies between tools.

• Expand all tool descriptions to 80-150 chars. Include: (1) What it does, (2) When to use it vs similar tools, (3) What it returns. Example: 'Search the indexed codebase for a symbol definition. Returns file path, line number, and function/class signature. Call this first if you only have a symbol name, before calling get_blast_radius.'
• Document output schemas for all tools. Specify return type (object/array), required fields, and field types. Example for n3mo_search_symbol: 'Returns {symbol_name: string, file_path: string, line_number: int, definition: string, type: "function"|"class"}'.
• Add parameter constraints: depth (1-10), project_path (non-empty absolute path), symbol_name (1-255 chars, alphanumeric + underscore). Include validation rules in descriptions: 'Absolute path to workspace directory (must exist and be readable).'
• Add error recovery hints to descriptions. Example: 'If symbol not found, the codebase may not be indexed. Call n3mo_index first, then retry. If still not found, try search_symbol with a partial name.'
• For n3mo_index, add a dry_run parameter (boolean, default false) to preview what would be indexed without committing. Document that indexing is a long-running operation and may take minutes on large codebases.

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

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