The Gmail Lead Nurturing MCP server has explicit tool definitions with schemas and descriptions visible in the source code. However, the overall quality is significantly hampered by: (1) vague and incomplete parameter descriptions, most parameters lack guidance on expected formats, ranges, or valid values; (2) parameter descriptions under 20 characters for several tools, triggering hard score caps; (3) no documented output schemas, tool responses are not formally specified, forcing LLMs to infer structure; (4) missing error handling guidance, no indication of what errors can occur or what the LLM should do in recovery scenarios; (5) weak parameter constraints, no enums where expected, no ranges on numeric parameters, no validation hints. The tools are logically partitioned (naming is verb-first: start_, stop_, run_, get_, update_, send_), but the definitions lack the rigor required for confident agent use. Baseline comparison: production tools average 194 chars for tool descriptions and 72 chars for parameter annotations; this server's parameters are notably shorter and less informative.

• Document output schemas for all tools. Example for get_status: 'Returns: {is_running: boolean, last_run: ISO8601 datetime or null, total_runs: integer, error_count: integer, uptime_hours: integer}'.
• Expand parameter descriptions to 50-100 characters with explicit constraints. For 'interval_hours', change to: 'Hours between nurturing cycles. Must be between 1 and 24. Default is 4 hours. Shorter intervals increase email frequency; longer intervals reduce system load.'
• Add tool-selection guidance to descriptions. For get_status, add: 'Call this before starting or after stopping to verify system state. Returns current statistics on email sends and errors.'
• Define error categories and recovery actions in each tool description. Example: 'Errors: (1) Gmail API unavailable, wait 30s and retry; (2) Invalid email, check send_test_email parameter format; (3) Config lock, another process is updating, retry in 5s.'
• For update_config, define the configuration schema explicitly. Example: '{email_template_id: string, batch_size: 1-100, retry_count: 1-5, timeout_seconds: 10-300}'.
• Add a confirmation step for destructive operations. Consider adding a 'dry_run' boolean parameter to send_test_email and update_config, defaulting to false, with guidance: 'Set dry_run=true to preview without sending/updating.'
• Add enum constraints where appropriate. For update_config, if it accepts a 'mode' field, declare: 'mode: enum("test", "production", "disabled")' in the schema.
• Include next-step guidance in tool descriptions. For run_single_cycle, add: 'After running, call get_status to observe results. Then call get_lead_report for detailed metrics.'

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

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