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

Annotations only provide idempotentHint, so the description carries the behavioral burden. It explains visibility semantics (private = link-only + noindex, public = indexable), warns that switching to public triggers a stricter content re-scan and may be rejected, and clarifies auth requirements for badgeHidden and managementToken. These details add real value beyond the annotation and schema.

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?

Three dense, front-loaded sentences: the first enumerates what can be changed, the second warns about the public-switch side effect, and the third clarifies auth. Every sentence earns its place with no filler or repetition.

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?

For an 8-param mutation tool with only idempotentHint and no output schema, the description covers the critical behavioral, auth, and edge-case context an agent needs to call it correctly. The few omitted details, such as publishAt and tags, are already documented in the schema, so the overall definition is complete enough.

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 63%, and the description adds meaning where the schema is silent or minimal: visibility enum semantics, managementToken vs account-token ownership, and the badge's Pro requirement. It does not mention publishAt or tags, but those already have schema descriptions, so the combined coverage is strong.

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?

Description opens with a concrete verb+resource: 'Change a drop's visibility... its expiration, or remove the badge... or its private name,' so an agent immediately knows what the tool does. It does not explicitly contrast with siblings like dropyou_publish or dropyou_schedule, but the settings-update scope is clear.

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 implies when to use the tool: when you need to change visibility, expiration, badgeHidden, or the private name. However, it does not explicitly state when to prefer a sibling tool or when this tool should not be used, such as for publishing/scheduling operations.

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