mcp-compose defines 15 tools with complete input schemas and descriptions. However, quality varies significantly across tools. Naming follows verb_noun convention (task_scheduler_*, server_*) which is good. Descriptions range from adequate (50-100 chars) to excellent (task_scheduler_create_task at 289 chars). Most parameters have type definitions and descriptions, meeting baseline for C/B grade. Key gaps: (1) no output schemas documented for any tool, forcing LLMs to infer response structure; (2) descriptions lack specific context about when to use each tool vs alternatives (e.g., when to call server_restart vs server_stop+server_start); (3) error handling guidance absent, tools describe what they do but not what failures look like or how to recover; (4) no examples of parameter constraints or validation feedback. The task_scheduler tools are stronger (especially task_scheduler_create_task with detailed param descriptions) vs system tools which are more generic.

• Document output schemas for all tools. Include field names, types, and descriptions. Example for server_list: {type: 'array', items: {type: 'object', properties: {server_name: {type: 'string'}, status: {type: 'string', enum: ['running', 'stopped']}, uptime_seconds: {type: 'integer'}}}}
• Add error handling guidance to each tool description. Explain: (1) Common failure modes (e.g., 'Server already running', 'Task not found'), (2) Which errors are retryable, (3) Suggested recovery actions. Example: 'Fails with 409 if server is already running (retryable after 2s); fails with 404 if server_name does not exist (ask user for valid name via search)'
• Clarify conditional parameter requirements. In task_scheduler_create_task, explicitly state: 'If task_type is "ai", prompt is required. If task_type is "shell", command is required. Exactly one of prompt or command must be provided.'
• Add tool annotation hints (readOnlyHint/destructiveHint/idempotentHint) in the tool registration. Mark server_stop, task_scheduler_delete_task, task_scheduler_create_task with appropriate hints so agents know which operations are safe to retry.
• For destructive operations (task_scheduler_delete_task, server_stop), implement a confirmation pattern. Either add a confirm=true parameter with default false, or separate the operation into a dry-run variant (e.g., task_scheduler_delete_task_confirmed). This prevents accidental data loss.
• Add disambiguating language to tools with similar names. E.g., server_restart description should clarify: 'Equivalent to stop + start. Use this for a full restart cycle. Use server_stop alone to halt without restarting.'

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

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