The Zen MCP Server suffers from severe definition quality issues across most tools. While 16 tools are declared, the source code provided does not contain explicit tool registration with complete schemas. Tool names are descriptive but lack the verb-noun pattern baseline (90% of A+ tools). Critically, no input schemas are visible in the provided code, only tool names and brief descriptions. The base_tool.py excerpt shows infrastructure but not actual parameter definitions or output schemas. Descriptions exist but are generic (50-100 chars, well below the 194-char baseline for production tools) and lack context on WHEN to use each tool, error recovery, or prerequisites. Parameter descriptions are completely absent from visible code. The tools appear to be workflow/reasoning tools (think_deep, consensus, debug) but their actual invocation contracts are not defined in the source. Without seeing server.py's full TOOLS registration dictionary with explicit schemas, this evaluation must treat tool definitions as inferred rather than directly visible, triggering the hard cap of 50 per tool, but the actual score is lower due to multiple critical gaps.

• Provide complete, visible tool registration with JSON Schema input and output schemas. Include server.py TOOLS dictionary or tools/ file with explicit Pydantic model definitions. Example: class ChatRequest(ToolRequest): content: str = Field(description='The message to discuss with the AI assistant'); models: Optional[List[str]] = Field(default=None, description='List of model IDs to use for multi-model consensus'); max_tokens: int = Field(ge=1, le=10000, default=2000, description='Maximum tokens to generate per response')
• Expand tool descriptions to 150 - 250 characters, following the pattern: 'What it does' (What does it do?) → 'When to use it' (When should the LLM call it instead of alternatives?) → 'What it returns' (What structure is returned?). Example for consensus: 'Multi-model consensus workflow that queries 3+ LLM providers on the same task and synthesizes their outputs. Use when high-stakes decisions need diverse perspectives; returns consensus_decision, model_opinions: {model_id: string}, confidence_score: 0.0 - 1.0, dissenting_views: string[].'
• Document output schemas for all tools. Add a structured 'Returns' section to each tool's docstring or create output_schema.json files. Example for listmodels: Returns array of {provider: str, model_id: str, display_name: str, capabilities: string[], rate_limit_rpm: int, cost_per_1m_tokens: {input: float, output: float}}. This enables downstream tool chaining.
• Add parameter descriptions and constraints to tools that accept inputs. For tools without visible inputs (version, listmodels), confirm they truly accept no parameters; if they do, document them. Example for listmodels if it accepts filtering: provider: Optional[str] = Field(None, description='Filter by provider (openai|google|anthropic|cohere). If omitted, returns all providers.'); include_pricing: bool = Field(True, description='Whether to include rate limits and pricing info in response.')

Inferred effective spec: 2026-07-28+.

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