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

Annotations declare readOnlyHint=true and destructiveHint=false, yet the description says '[Analysis] Change one execution right' and 'apply a preset' that alters ad status, budgets, and approval thresholds. Applying a preset that changes operational spend is a state mutation, directly contradicting readOnlyHint. The only mitigating note is 'nothing is sent anywhere', which speaks to openWorldHint, not to read-only behavior.

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?

It is front-loaded with the core action, which is good, but the whole definition is one run-on sentence with a deeply nested parenthetical enumerating every autopilot exception. Much of that enumeration is decision-relevant, but it would read far better as a short list than as a single clause chain.

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?

An output schema exists, so return values need not be explained. Still, for a 9-parameter mutation-shaped tool the description omits key calling details: the meaning of id, what happens when preset and id are both supplied, and the semantics of the ceiling fields. Combined with the readOnly annotation mismatch, an agent cannot confidently predict the call's effect.

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%, so the description must carry the meaning of 9 parameters. It does well for mode (auto|approve|never), category, and preset (explaining what autopilot and manual actually do), and it names the four ceilings. But it never explains id, note, whether id/category and preset are mutually exclusive, or the units/semantics of max_pct and min_margin_ron beyond their names.

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?

Starts with a specific verb+resource: change one execution right, defined as category + mode (auto|approve|never) + monetary ceilings, plus an alternative preset path. An agent can distinguish it from action_rights_list by name and by the 'change/apply' framing. It stops short of naming the sibling, and the preset alternative is buried inside a very long parenthetical rather than stated up front.

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?

It does explain the two operating modes it offers (autopilot vs manual) and spells out what each preset expands to, which is genuinely useful context for choosing a preset. However it never states when to use a preset versus setting an individual right, whether id/preset are mutually exclusive, or how this relates to action_rights_list. Usage is implied by the enum descriptions rather than stated as guidance.

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