ClawScope MCP exposes only 2 generic tools (list_tools, call_tool) that act as pass-through dispatchers to an external ToolRegistry/SkillRegistry. Tool definitions are NOT visible in the provided source code, only inferred from the handler signatures. Both tools lack parameter descriptions (required fields undescribed), have minimal descriptions (under 50 chars), and no output schema documentation. The architecture delegates all tool semantics to an opaque registry, making it impossible to evaluate actual tool quality. This is a meta-tool pattern that bypasses MCP's tool definition contract.

• Expose actual tool definitions from ToolRegistry/SkillRegistry directly to MCP via list_tools handler. Return full Tool objects with name, description, inputSchema, and annotations for each registered tool. This allows MCP clients to discover and validate tools without a meta-dispatcher.
• Add comprehensive descriptions to list_tools (e.g., 'Discover all available tools from ClawScope ToolRegistry and SkillRegistry. Returns tool names, descriptions, and input schemas.') and call_tool (e.g., 'Execute a registered tool by name with arguments. Validates arguments against the tool's schema and returns structured results or actionable errors.').
• Document the output schema for both tools. Specify that list_tools returns an array of Tool objects with {name, description, inputSchema} and call_tool returns {success: bool, result?: any, error?: {code, message, recovery_hint}}.
• Implement error classification in call_tool responses. Return structured errors like {"error": {"code": "TOOL_NOT_FOUND", "message": "Tool 'xyz' not found", "recovery": "Call list_tools() to see available tools"}} instead of plain text.
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to the Tool schema returned by list_tools. This enables MCP clients to warn users before destructive operations and optimize retry logic.