HeyClaw exposes only one tool: read_skill. The tool has a basic description and minimal input schema. The description (89 chars) is below the 194-char baseline for production tools and lacks context on WHEN to use it or WHAT it returns. The input schema defines only a 'name' parameter with a string type and brief description, but provides no enum constraints, format specifications, or validation guidance. No output schema is documented. The tool name 'read_skill' is generic and does not follow verb_noun conventions clearly (should be 'get_skill_instructions' or 'fetch_skill_details'). No error handling guidance, no pagination, no composition hints. The server appears to be a voice assistant backend with MCP integration, but the single exposed tool is insufficient for meaningful agent interaction.

• Expand tool description to 150-250 chars: explain what a 'skill' is in this context, what instructions are returned, and when to call this tool (e.g., 'Retrieves the complete instructions and parameters for a skill before invoking external tools. Call this first to understand what a skill does and what inputs it requires.').
• Document the output schema explicitly. Specify fields like 'skill_name', 'instructions', 'parameters', 'examples', and their types. This enables the LLM to extract and use the returned data.
• Add an enum constraint or discovery mechanism for the 'name' parameter. Either list valid skill names as an enum, or add a companion tool like 'list_available_skills()' and reference it in the description.
• Rename tool to 'get_skill_instructions' or 'fetch_skill_details' to follow verb_noun convention and clarify the action.
• Add error handling guidance: 'If the skill name is not found, call list_available_skills() to see available options.' Include this in the description or as a separate error response pattern.

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

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