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

Far exceeds what the annotations provide. Annotations only declare safe/idempotent/read-only; the description adds the auth requirement (ad-account ADMIN key with billing permission), the graceful non-failure behavior for ordinary keys ('says exactly that instead of failing'), the billing-plan restriction (postpaid invoice only), currency units, and exclusive end-date semantics in the account time zone. This is exactly the operational context an agent needs to interpret a result or an unexpected response.

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?

Four dense but front-loaded sentences: what it shows first, then the account-vs-campaign caveat, then data semantics, then auth. Every clause except the trailing 'Read-only' earns its place; that last sentence duplicates readOnlyHint and could be dropped. No filler otherwise.

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 structure needn't be described, and the description covers currency, date exclusivity, billing-plan scope, and auth behavior thoroughly. The one real gap is the unexplained `account` parameter, which matters because the tool is account-scoped.

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?

There is one parameter, `account`, with 0% schema description coverage and a bare empty-string default, so the schema does not carry the burden — this is not the zero-parameter baseline-4 case. The description never explains what `account` accepts or what the empty default resolves to (all accounts? default account?), leaving the agent to guess how to target an account.

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 specific verb and resource ('Shows the ChatGPT Ads account-level spending limits') and enumerates what is returned: date-range windows, recurring daily limit, spend so far. It also draws the crucial account-vs-campaign scope boundary, which is what separates it conceptually from the campaign budget tools. It does not name the obvious sibling `manage_chatgpt_ads_spend_limit` (the write counterpart), so the read/write routing is only implied by 'Read-only'.

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?

Gives concrete when-it-matters context: an account limit caps spend across ALL campaigns, so a campaign can have budget left and still stop — this tells an agent exactly which diagnostic question this tool answers. It also states preconditions (admin key with billing permission, postpaid/invoice billing only), which is strong usage guidance. It stops short of naming the alternative tool to use for changing limits.

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