Dokploy MCP Server

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

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description doesn't contradict these (it implies creation, which aligns with non-readOnly). However, it adds no behavioral context beyond what annotations already cover - no information about what gets created, authentication requirements (though apiToken/userKey are parameters), rate limits, or what happens on duplicate calls. With annotations covering basic safety, the description adds minimal value.

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?

While technically concise, the description is under-specified rather than efficiently structured. It wastes space on a basic parameter list that adds little value without explanations, and the first line '[notification] notification.createPushover (POST)' is redundant with the tool name. The information is poorly organized and doesn't front-load the most important details about the tool's purpose.

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?

This is a creation tool with 13 parameters (3 required), 0% schema description coverage, no output schema, and no behavioral context in the description. The description fails to explain what the tool does, when to use it, what the parameters mean, or what to expect as a result. Given the complexity and complete lack of parameter documentation, this description is wholly inadequate for an agent to understand and use the tool correctly.

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%, meaning none of the 13 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what they mean, their purpose, or how they interact. For example, it doesn't explain what 'appBuildError' triggers, what 'priority' values correspond to, or what 'retry' and 'expire' control. This leaves critical semantic gaps for an agent trying to use the tool correctly.

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 is essentially a tautology that restates the tool name with minimal context. It mentions 'notification.createPushover (POST)' which indicates it creates a Pushover notification, but doesn't explain what Pushover is, what kind of notification system this integrates with, or what the tool actually accomplishes beyond the obvious from the name. No differentiation from sibling notification tools is provided.

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 absolutely no guidance on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or relationship to other notification tools (like createDiscord, createSlack, etc.). An agent would have no idea when this specific notification type is appropriate.

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