RRClaw defines 12 tools with complete JSON schemas and descriptions present in source. However, significant quality issues prevent a higher score: (1) Naming conventions lack consistent verb-first structure, 'memory_store', 'memory_recall', 'memory_forget' are acceptable but 'routine' and 'skill' are vague action names that don't clearly convey their scope or effect. (2) Descriptions are present but brief (ranging 10 - 120 chars), mostly functional rather than LLM-optimized. Most lack dependency hints, failure modes, or clarity on when to call this tool vs. similar ones. (3) Parameter descriptions are minimal, e.g., 'args' in git tool lacks detail on what each operation expects. (4) No output schemas documented for any tool, LLMs cannot plan downstream tool chains or know what fields to extract. (5) Error handling is not evident from code, no recovery guidance, no classification of retryable vs. fatal errors. (6) Security posture: shell and git tools accept arbitrary commands without visible input sanitization or rate limiting. Memory tools store/recall unstructured strings without validation. (7) Tool composition: file_write + file_read + shell + git are tightly grouped, but no clear guidance on precedence or error handling if one fails. Baseline: 549 production tools average 18-char names (p10=10, p90=27), 194-char descriptions (p10=34, p90=392), 100% have return type docs, 94% have tool descriptions, 100% of params described in A+ tools. RRClaw's avg tool name = 16 chars ✓, avg description ≈ 65 chars (too short, below p10), 0% have return type docs (critical gap), param descriptions ≈ 50% complete. Median MCP server scores 45 - 55; this server lands in that range due to presence of schemas but lack of depth and output documentation.

• Add output schema documentation for every tool. Document field names, types, and which fields downstream tools depend on. For example, file_read should document: {type: object, properties: {content: {type: string}, encoding: {type: string}}}, etc.
• Expand tool descriptions to 150 - 250 chars, following pattern: 'WHAT (verb + noun). WHEN (when to use vs. similar tools). RETURNS (summary of output).' Example: 'Read file contents from the filesystem. Use when you need to view code, config, or doc files. Returns file content as string and detected encoding.'
• Add per-parameter descriptions with constraints. For git.args, specify: 'Array of arguments for the operation. For commit: ["--message", "<msg>"], ["--author", "<name>"], etc. For push: ["<remote>", "<branch>"], etc.'
• Rename vague tools: 'routine' → 'manage_scheduled_routine' or 'create_routine'; 'skill' → 'execute_skill' or 'run_behavior_guide'. This follows pattern:naming verb-first convention and reduces LLM confusion.
• Document error handling in descriptions. Add: 'Errors are classified as retryable (command timeout, network error) or fatal (permission denied, invalid git repo). Retryable errors include retry_after_seconds.' Implement error responses per pattern:recovery-guide.
• Implement explicit input validation and sanitization for shell, git, and file_write. Add validation descriptions: 'File paths must not contain ../ (path traversal) or symlinks outside safe directories. Shell commands are validated against a whitelist policy (see SecurityPolicy).'

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

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