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

With annotations present the bar is lower, and this description still adds real value: it explains why readOnlyHint is false by noting "the result is recorded on the campaign", and it pre-empts the destructive/delivery worry with "Sends nothing and changes no content." Auth requirements, rate limits, and whether a re-run overwrites the prior result are not covered.

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 short sentences, front-loaded with the purpose, followed by the side-effect disclaimer and the one parameter worth calling out. The dry_run sentence partly restates the schema field, keeping it just short of maximally tight.

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 two-parameter check tool with full schema coverage, the description covers what it does and what it does not change. The one gap is that there is no output schema and the description never says what the call returns (only that the outcome is recorded on the campaign), leaving the response shape to inference.

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 100%, so both parameters are already documented and baseline 3 applies. The description's "Set dry_run: true to skip the check" adds a slightly different framing than the schema's "show what the check would do without running it or recording a result", but it clarifies rather than extends the parameter meaning.

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?

"Check a campaign's content for broken links and blocklisted links or domains" names a specific verb (check) and a precisely scoped resource/outcome, and "the same check as in the panel" anchors it to a behavior the user already understands. It does not explicitly name which sibling to prefer (e.g. audit_campaign_draft, analyze_campaign, check_sending_setup), so differentiation is inferred rather than stated.

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 gives one concrete usage condition ("Set dry_run: true to skip the check") and implies the normal case runs the check, but never says when to reach for this versus analyze_campaign, audit_campaign_draft, or check_sending_setup. Prerequisites (campaign state, required permissions) are unstated.

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