Dokploy MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating it's a safe, repeatable read operation with open-world semantics. The description adds no behavioral context beyond this (e.g., pagination details, rate limits, or auth requirements), but it doesn't contradict annotations, so it meets the lower bar with annotations present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a header and bullet-pointed parameters, making it easy to scan. It's appropriately sized without unnecessary fluff, though the header is redundant with the name/title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, 0% schema coverage, no output schema, and annotations covering safety, the description is incomplete. It lists parameters but doesn't explain their semantics, return values, or behavioral nuances like pagination (implied by limit/offset), leaving gaps for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description lists all parameters with types and enums, adding meaning beyond the bare schema (e.g., clarifying optional enums for action and resourceType). However, it doesn't explain parameter purposes (e.g., what 'from' and 'to' represent) or usage, so it partially compensates for the low coverage but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description merely restates the tool name and HTTP method ('[auditLog] auditLog.all (GET)'), which is tautological. It doesn't specify what the tool actually does (e.g., retrieve audit logs with filtering capabilities) or distinguish it from siblings like other audit-related tools (none listed, but it doesn't clarify its unique role).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, typical use cases, or any mention of sibling tools (e.g., if there are other audit log tools for specific scenarios).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.