dokploy_volume_backup

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the rclone-based nature, scheduling, the turnOff option to stop services during backup, and runManually for immediate triggers. However, it does not disclose potential side effects such as downtime implications of turnOff, the destructive nature of remove, or how keepLatestCount affects retention. It adds some meaningful context but not a full behavioral profile.

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 dense but efficiently communicates all key information without fluff. It uses a compact action-colon format that packs a lot of detail. However, it's a single block of text; a bulleted list would improve readability, but it remains reasonably structured and front-loaded with the core 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?

With 23 parameters, 6 actions, no output schema, and no annotations, the description does a solid job of covering the operational aspects. It explains each action's required parameters and the distinction from related tools. Missing elements include return value descriptions and specific behavior of each action (e.g., what get returns, what runManually does beyond 'trigger immediately'), but given the high complexity, the description is fairly complete.

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?

The schema description coverage is only 22%, and the schema alone does not indicate which parameters apply to which action. The description compensates exceptionally well by explicitly mapping each action to its required and optional parameters (e.g., create needs name+volumeName+prefix+cronExpression+destinationId, list needs id+volumeBackupType). This is critical semantic guidance that the schema lacks.

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 clearly states it manages scheduled volume-level backups using rclone, and explicitly distinguishes it from dokploy_backup which does DB-native dumps. This specific verb+resource+scope fully clarifies what the tool does and differentiates it from its sibling.

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 explicitly contrasts this tool with dokploy_backup ('Distinct from dokploy_backup, which does DB-native dumps'), giving direct when-to-use/when-not-to-use guidance. It also enumerates the actions (create, update, remove, get, list, runManually) and the required parameters for each, effectively guiding the agent on how to invoke the tool correctly for different operations.

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