Dokploy MCP Server

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

The annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which already tell the agent this is a safe, non-destructive, repeatable operation. The description adds minimal value beyond the annotations - it only confirms the HTTP method is GET. It doesn't provide any additional behavioral context like rate limits, authentication requirements, or what specific MySQL resource is being retrieved.

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 extremely concise - arguably too concise. While it's structured with clear labeling of parameters, the content is insufficient. The two-line format is efficient but under-specified. Every sentence should earn its place, and here the minimal content doesn't provide enough value to justify even this brevity.

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 the complexity of database operations and the complete lack of output schema, the description is inadequate. While annotations provide good safety information, the description doesn't explain what MySQL resource is being retrieved, what information is returned, or how this tool fits into the broader MySQL management context. For a tool that presumably retrieves critical infrastructure information, this level of documentation is insufficient.

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?

With 0% schema description coverage and only one parameter (mysqlId), the description provides no semantic information about what mysqlId represents. The schema only indicates it's a required string with minimum length 1, but the description doesn't explain what this identifier refers to, how to obtain valid values, or what format it should have. The description fails to compensate for the complete lack of schema documentation.

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 '[mysql] mysql.one (GET)' is essentially a tautology that restates the tool name and adds the HTTP method. It doesn't specify what the tool actually does - whether it retrieves a MySQL database instance, configuration, status, or something else. While 'GET' implies retrieval, the purpose remains vague and doesn't distinguish this tool from other MySQL-related tools in the sibling list.

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?

The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple MySQL-related tools in the sibling list (dokploy_mysql_changeStatus, dokploy_mysql_create, dokploy_mysql_deploy, etc.), but the description offers no context about when this specific 'one' tool is appropriate versus those other MySQL operations.

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