Plan a cross-platform launch without sending anything (dry run); returns the plan

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

The annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with them by confirming nothing is sent. It adds only that a plan is returned; it says nothing about validation failure behavior, whether a failed preview still returns a partial plan, or what the plan contains. Given annotations carry the safety profile, this is adequate but thin.

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?

One front-loaded sentence with no filler, ending with the endpoint path. It is efficient, though it spends words restating the title and gives the endpoint before any substantive body guidance.

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 tool whose input is a large nested campaign brief and whose output is an undescribed 'plan' (no output schema), the description omits the two things an agent most needs: what the request body must contain and what the returned plan looks like (per-platform issues, warnings, resolved IDs). "Returns the plan" is not enough given the tool's complexity.

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% and there is one deeply nested body parameter (CampaignBrief with split policies, micros/currency budgets, platformOverrides keyed by ~400 platforms, and an acceptUnknownSpec toggle). The description mentions none of this, so it does not compensate for the coverage gap at all — an agent must reverse-engineer the entire contract from the schema structure alone.

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 definition states a specific verb and resource — plan a cross-platform launch in dry-run mode — plus the REST endpoint it maps to. "Without sending anything" implicitly contrasts it with crosspost_launch, but the sibling is never named, so the differentiation relies on inference.

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 dry-run framing implies when to use it (validate a plan before committing), but there is no explicit instruction such as "use before crosspost_launch" and no statement about when preview is unnecessary or what to do with the returned plan. Usage must be inferred from the phrase 'without sending anything'.

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