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

Annotations already cover read-only/idempotent, but the description goes well past them: clipping of `until` to observedAt with partialDay=true and null daily spend/ratios, null on missing spend or mixed currencies, provider conversions never counting as paid bookings, UTM/click IDs never being guessed into Ads links, and fail-closed source caps (2000/8 connections/20 pages). Those are exactly the behavioral traits an agent needs to interpret results and avoid misreporting.

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?

Purpose is correctly front-loaded in the first sentence, but the remainder is a chain of semicolon-joined clauses of varying readability, with some near-telegraphic fragments ('capture/test exclusion remains not_attested'). Almost nothing is pure padding, yet the density makes it hard to scan and a bulleted or clause-per-line structure would serve the agent better.

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 read-only analytics call with no output schema, the definition is nearly sufficient: it describes returned metrics, null-result conditions, partial-day behavior, and the unattributed row. The missing pieces are the meaning of the `groupBy` breakout and any hint of result shape (row granularity, volume of rows).

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?

With 0% schema description coverage the description must carry the load, and it does for two of three parameters: `from` inclusive, `until` exclusive, both tenant-calendar YYYY-MM-DD in a confirmed business-hours timezone, plus the 'name tomorrow to include today' trick and the clipping behavior. `groupBy` (enum channel/campaign, default channel) is never mentioned, which is the one clear semantic gap.

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 opening clause names a specific verb-and-resource pair and enumerates the exact metrics returned (spend, inquiries, first offers, distinct paid bookings, receipts, CPA, ROAS, attribution coverage), so an agent knows precisely what it gets back. It scopes itself as tenant-bound channel/campaign reporting but never names a sibling such as get_advertising_performance or get_acquisition_attribution_audit, so the boundaries against those tools must be inferred.

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 'Requires marketing:read AND accounting:read' line is genuine use-gating, and the default window (last 30 completed days, max 366) tells the agent when it can call without arguments. However, there is no explicit statement of when to prefer this over the advertising or attribution-audit siblings, which is the main ambiguity for an agent facing 30+ neighbors.

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