AgentDispatch MCP server has well-structured tool definitions with consistent naming (verb_noun pattern) and complete input schemas. However, descriptions are generic and lack LLM-optimization guidance. Parameter descriptions are minimal (often single phrases). No output schemas are documented. Error handling is absent from tool definitions. The server exposes complex nested objects (target, metadata) without clear guidance on structure or required fields. Tool composition is reasonable but lacks idempotency guarantees and recovery patterns.

• Expand all tool descriptions to 80-150 characters. Include: (1) what the tool does, (2) when to call it vs similar tools, (3) what it returns. Example: 'Dispatch a task to a cloud agent. Call this after check_cloud_agent_runtime succeeds. Returns task_id for polling status.'
• Document output schemas for all tools. Add a comment block or separate schema file showing response structure, field types, and which fields are required for chaining (e.g., task_id for get_task_status).
• Standardize parameter naming to snake_case only. Remove camelCase variants (runtimeArn, ecrImageUri, etc.). This eliminates LLM confusion and reduces parameter count.
• Add error handling guidance to state-changing tools (spawn_cloud_agent, dispatch_task, cancel_task). Document: (1) what errors are retryable, (2) what errors require user input, (3) recovery steps. Example: 'If runtime not found, call list_providers() to see available options.'
• For complex nested objects (target, metadata, runtime_tools), provide example JSON structures in tool descriptions or create separate helper tools that guide LLMs through valid configurations.