The DuploCloud MCP server exposes 6 tools with varying quality. Tool naming follows verb-noun conventions (resources, explain_resource, explain_command, execute, config, health), which is good. Descriptions are present for all tools and generally adequate (range 30-200 chars). However, several critical gaps emerge: (1) The 'execute' tool accepts a broad 'body' parameter as an untyped object, forcing LLMs to rely on separate explain_command calls to discover valid schemas, this is a composition and schema design weakness. (2) Parameter descriptions are sparse or missing context for complex cases. (3) Output schemas are undocumented, LLMs cannot know what fields to expect from execute() without calling explain_command first. (4) Error handling is minimal; tool implementations return error dicts but offer no recovery guidance. (5) The 'explain_command' and 'explain_resource' tools are discovery helpers, not primary agents, they add indirection to the LLM workflow (resources → explain_resource → explain_command → execute) rather than surfacing resource operations directly. This is a valid but inelegant composition pattern. Across 6 tools, average scores show competent naming (85), acceptable descriptions (68), and weak schemas (45).

• Add documented output schemas for all tools. For execute(), document the response structure: e.g. {'result': {...}, 'status': 'success|partial|error', 'command_summary': '...'}. This lets LLMs understand what data is available after a call.
• Enhance error messages with actionable guidance. Instead of {'error': 'Resource not found'}, return {'error': 'Resource "foo" not found', 'available_resources': ['tenant', 'service', 'asg'], 'hint': 'Call resources() to list available resources'}. This enables LLMs to self-correct.
• For execute(), consider pre-populating 'args' and 'body' examples in the description, or link to a reference. E.g. 'args example: {"image": "nginx:latest", "replicas": 3}'.
• Document pagination and limits in execute() if applicable. If results can exceed context, state the default limit and how to paginate.
• Consider adding individual resource action tools (e.g., create_service, update_service, delete_service) alongside the generic execute() tool. This would let LLMs call resource-specific tools directly without explain_command steps, reducing latency for common operations.
• Expand health() description: 'Health check endpoint. Returns 200 if the server and DuploCloud connection are operational. Use this to verify the server is ready before running commands.'
• Add an 'idempotentHint' or 'destructiveHint' annotation to execute() to signal whether certain commands (delete, create) may have side effects. This helps LLMs reason about retry safety.

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

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