mono-pilot defines 5 tools with mixed quality. The two MCP gateway tools (CallMcpTool, ListMcpTools) have complete schemas and reasonable descriptions, but the three game extension tools (BusSend, MailBox, ReadFile) are inferred only from a registry, no visible implementation, schemas, or parameter documentation in the provided source. CallMcpTool has a detailed description (150+ chars) and explicit JSON Schema, but 'arguments' is Optional with Any type, too permissive for LLM safety. ListMcpTools has a good description but its schema uses optional string parameters with no type constraints or enums. Per-tool analysis reveals critical gaps in naming, parameter descriptions, and schema rigor across the portfolio.

• Document the three game extension tools (BusSend, MailBox, ReadFile) with explicit JSON Schemas, descriptions, and parameter docs. Extract tool definitions from src/extensions/game/tools.ts and the underlying extension factories (src/tools/bus-send.js, etc.) into the source code review.
• Replace CallMcpTool's 'arguments' Type.Any with a constrained schema. At minimum, document that arguments must be a valid JSON object matching the target tool's input schema. Better: generate or cache tool schemas and validate arguments against them before posting to the remote MCP server.
• Add parameter descriptions and validation guidance to ListMcpTools: 'server' should document that it filters by configured MCP server ID (e.g. 'anthropic', 'github'); 'toolName' should document the expected format and that it returns full schema only when a matching tool is found.
• Move the example JSON from CallMcpTool's description text into a separate markdown file or README example section. Replace it with a constraint-based description: 'Arguments must be a JSON object with keys and values matching the target tool\'s input schema. Consult ListMcpTools to inspect the schema.'
• Implement error categorization in CallMcpTool responses. Return a structured error object: { isError: true, errorType: 'retryable|user_fixable|fatal', message: '...', suggestion: '...' }. This enables the LLM to decide whether to retry, ask the user, or escalate.
• Return CallMcpTool results as structured JSON instead of formatted text. Example: { success: true, server: 'anthropic', toolName: 'search', content: [...], isError: false, contentItemCount: N }. This supports LLM reasoning and downstream tool chaining.