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

The description transparently frames this as a preparation step rather than a direct execution, and it notes the need for a subsequent approval and confirmation. It also communicates that amounts must be positive and in major units. The annotations do not contradict this and add safety signals (not read-only, not destructive), so the extra context about the approval flow goes beyond the structured data.

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 two sentences long and highly efficient: it states the action, the batch size, required fields, the major-units caveat, and the recommended next step. There is no filler or repetition of already-stated annotations, and the most important information is front-loaded.

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 a batch prepare-tool with an output schema, the description covers the critical invocation details: item count limits, required identifiers, budget positivity/units, and the approval/confirm workflow. It leaves out some secondary lifecycle details, such as what happens if the approval is denied or whether prepared changes can be overwritten, but nothing essential to calling the tool correctly is missing.

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?

Although the top-level 'items' parameter has no schema description (0% coverage), the description compensates by naming the three required per-item fields and explicitly requiring a positive daily_budget in major units. This adds meaning beyond the schema, especially because daily_budget can be a string and the schema's exclusiveMinimum only applies to the number form.

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 opens with a specific verb and resource: 'Prepare 1-10 campaign daily-budget changes under one approval.' It clearly describes a batch preparation action and is set apart from the singular sibling overview_update_campaign_budget by the explicit plural scope and count range. The follow-up reference to overview_update_confirm further anchors what this tool is for.

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 a clear workflow: prepare the batch, review current/new amounts, then call overview_update_confirm after approval. This gives solid context on when and how to use the tool, including the expected next step. It does not explicitly say when to prefer this over the singular overview_update_campaign_budget, but the batch framing makes the intended use reasonably clear.

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