Three tools with significant definition gaps. nreki_navigate and nreki_code have action parameters accepting free-form strings (no enums), making them ambiguous for LLM selection. Descriptions are present but generic (50-80 chars, below the 194-char baseline). Parameter descriptions exist but lack format constraints, ranges, or examples. nreki_guard's description is vague ('Safety controls, session monitoring, and persistent memory'). No output schemas documented. No error handling guidance visible. Tool names use verb_noun pattern correctly, but parameter design invites hallucinated action values.

• Replace free-form 'action' string with enum: action: {type: 'string', enum: ['outline', 'search', 'refactor_analysis']} for nreki_navigate. Document each action's purpose in the parameter description.
• Expand tool descriptions to 150-250 chars. Example for nreki_navigate: 'Analyze code structure and dependencies using AST parsing. Use outline to view file structure, search for semantic matches, or refactor_analysis to assess impact of changes. Returns structured code metadata.'
• Document output schema for each tool. Example: nreki_navigate returns {outline: {symbols: [{name, type, line}]}, search: {matches: [{file, line, context}]}}.
• Add format constraints to parameters. Example: path should be 'File path relative to project root (e.g. src/index.ts)'. query should be 'Semantic search term (1-200 chars, alphanumeric + spaces)'.
• Add error handling guidance to descriptions. Example: 'If file not found, returns error with available files in directory. If action is invalid, returns list of valid actions.'

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

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