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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description still adds genuine behavior beyond that: the row granularity (one row per ad account, including networks not yet connected) and the fact it wraps GET /api/v2/ads/offers. It doesn't mention pagination or result limits, but the extra context is meaningful.

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?

Front-loaded with the read-only tag and a dense enumeration of returned fields in a single sentence; the endpoint reference in parentheses is useful. Minor waste: read-only is stated twice ('[read-only]' and 'Read-only.'), which is redundant against the annotations as well.

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?

There is no output schema, so the description usefully enumerates what comes back (status, spend so far, remaining spend, daily pace, deadline, claim path). Given a single optional parameter and full annotation coverage, an agent has enough to call it correctly; only cross-tool routing and pagination are 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?

Schema description coverage is 100% and there is only one optional parameter, brandId, whose description already explains the account-wide vs brand-bound 403 behavior thoroughly. The tool description references the brand scope only obliquely ('the brand's ... offers') and never mentions brandId, so it adds little beyond the schema – baseline 3 applies.

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?

States a concrete verb+resource with scope: the brand's new-advertiser offers per ad network, one row per ad account or unconnected network. The 'per ad account / per network' granularity is a real differentiator, but the description never names the adjacent siblings offers_list or ads_accounts_list, so an agent must infer how this differs from them.

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?

Usage is only implied by the content described (status, spend, pace, deadline, claim instructions); there is no explicit when-to-use or when-not-to-use guidance. With offers_list, offers_capture, offers_update and ads_offer_update all present as siblings, an explicit boundary statement would be valuable and is absent.

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