manage_backups

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions that the tool can create, update, and delete, implying mutability, but provides no details on side effects, permissions, reversibility, or confirmation requirements. The confirmation requirement for delete is only present in the input schema, not the description, so the agent is left without warning about destructive actions.

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 compact at two sentences, front-loading the core purpose. The second sentence is somewhat dense with a long list of fields, but each item adds relevant detail. It avoids unnecessary filler, so it remains appropriately sized for the tool's complexity.

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 tool's complexity (9 parameters, multiple actions, nested objects, no output schema), the description gives a high-level overview but misses some important distinctions. For example, it does not clarify the difference between 'list' (schedules) and 'executions', nor between 'delete' and 'delete_execution'. However, the input schema covers many required-field constraints, so the description does not need to repeat those. Still, the ambiguity around action applicability leaves gaps.

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 description adds meaning beyond the schema by explaining that `fields` holds backup schedule parameters and lists which ones are required or optional for create/update. It specifically notes that `frequency` is a cron expression and includes the wildcard `database_backup_retention_*`, which is not obvious from the schema alone. This compensates for the 78% schema coverage by clarifying usage of the `fields` object.

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 the tool's function: 'List, create, update, or delete database backup schedules and executions.' It names a specific resource (database backup schedules/executions) and distinct verbs for each action. The qualifier 'Only applicable to databases' further narrows scope, differentiating it from sibling tools like manage_scheduled_tasks.

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 clear context by specifying that the tool is 'Only applicable to databases,' which serves as an exclusion criterion. It also gives actionable guidance for create/update by stating that schedule fields go in `fields` and that `frequency` is required. However, it does not explicitly name alternative tools or state when not to use this tool beyond the database scope.

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