This MCP server has CRITICAL failures across all definition quality dimensions. The tool registry in lib/codex_pooler/mcp/tool_registry.ex defines 5 tools, but they are tool FAMILIES with metadata-only descriptions, not actual tool implementations. The descriptions state 'metadata only, actual tools defined in family module', meaning the actual schema, parameter definitions, and tool descriptions are not visible in the provided source code. Per the hard scoring rules, if tool definitions cannot be verified in source, they are capped at 50. No input schemas are visible for any tool. No parameter descriptions are visible. No output schemas are documented. Error handling patterns are not evident. The server has toolAnnotations enabled but no evidence of how they are applied to actual tools. This is a bare-bones, incomplete MCP server definition.

• Expand each tool family into explicit tool definitions with names starting with action verbs. E.g. 'foundation_tool_family' → 'get_foundation_config', 'list_foundation_settings', 'update_foundation_settings'.
• Add detailed descriptions (50 - 200 chars) to each tool. State clearly: What does it do? When should an LLM call it? What does it return? Example: 'Retrieves the current configuration and resource limits for the Codex Pooler foundation service. Use this to check available quotas before submitting large requests.'
• Define complete JSON Schemas for all tool inputs and outputs. Include type definitions, constraints (enums, ranges, patterns), and descriptions for every parameter.
• Add parameter-level descriptions explaining format, constraints, and examples. E.g. for a 'pool_type' param: 'The pool type (enum: compute, memory, io). Determines which resource limits apply.'
• Implement error responses that guide LLM recovery. For example, if a quota is exceeded: 'Pool quota exceeded (used 950/1000). Call get_pool_metadata() to check available resources, or split the request into smaller batches.'
• Verify all tool names follow verb_noun convention. Rename generic names like 'operator_metadata' to action-driven names like 'get_operator_status', 'list_operators', 'assign_operator_to_pool'.
• Document tool composition: which tools can chain together (e.g., list_pools → get_pool_metadata → update_pool_config). Ensure downstream tools receive IDs and references from upstream tools.
• If tools modify state (e.g., update_pool_config), add descriptions stating: 'Modifies the pool configuration. This action is irreversible; consider validation before calling.' Include a dry-run option if possible.