Mandoline MCP Server demonstrates solid definition quality with well-structured tools, clear naming conventions, and comprehensive parameter documentation. All 11 tools follow verb_noun naming patterns (create_metric, get_metric, update_metric, etc.). Descriptions are present and substantive (ranging 50-250 chars), explaining what each tool does and when to use it. Input schemas are complete with type definitions and parameter descriptions. However, there are notable gaps: (1) Output schemas are not explicitly documented, tools return responses but the response structure is not specified in the schema definition; (2) Error handling lacks recovery guidance, errors do not suggest next steps or categorize as retryable vs. fatal; (3) Tool descriptions could better specify prerequisites, side effects, and downstream dependencies; (4) Some parameter descriptions in the complex nested objects (prompt/response in create_evaluation and batch_create_evaluations) are vague about required structure. The batch tools (batch_create_metrics, batch_create_evaluations) show good composition patterns by accepting arrays, reducing token waste. Pagination is well-handled in list tools (get_metrics, get_evaluations) with skip/limit parameters and cost warnings in descriptions.

• Add explicit output schemas to all tools. Document return type structure, required fields, and example response shape. For create_metric, specify what fields the returned metric object contains (e.g., metric_id, name, description, tags, created_at). For batch operations, document per-item results and any failure rollback behavior.
• Enhance error handling guidance. Add sections like 'Error cases' to each tool description explaining what can go wrong (e.g., 'metric_id not found', 'invalid tags format', 'permission denied') and what the LLM should do (retry, ask user, call search_metrics first).
• Clarify nested object requirements in create_evaluation and batch_create_evaluations. Specify: (1) whether context_assets and invocations are truly optional if empty; (2) the exact structure of messages array (must include role, content, etc.); (3) whether invocations array can be empty or must contain at least one tool call.
• Document idempotency and side effects. For create_metric, state: 'If a metric with the same name already exists, this returns the existing metric without creating a duplicate.' For create_evaluation, state: 'This is not idempotent, calling it twice with identical inputs creates two separate evaluations. Use get_evaluation to check if an evaluation already exists before creating a new one.'
• Add a note in the server documentation explaining that authentication is handled server-side via API Key injection, so the LLM does not need to concern itself with passing credentials to individual tools.

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

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