Budget pacing: spend vs expected to date, projected end, on_track/under/over (5% default)

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description only adds the endpoint path and the 5% tolerance default; it says nothing about the response shape, the meaning of the on_track/under/over classification boundaries, or whether 'expected to date' is prorated by day or month. For a metrics tool whose output semantics matter, that is 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?

It is a single compact line that front-loads the resource and the output contents. The endpoint path in parentheses is mostly redundant with the tool name, but nothing else is wasted.

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 nested-body analytics tool with 0% schema coverage, no output schema, and six sibling analytics tools, the description leaves too much unresolved: no scope selection guidance, no parameter meaning, and no sense of the returned pacing figures. It is readable but not sufficient for confident invocation.

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 the body object nests seven undocumented properties (asOf, clientId, currency, platform, tolerance, campaignId, crossCampaignId). The description only explains the tolerance default of 5%, leaving asOf date semantics, currency format expectations, and whether campaignId and crossCampaignId are mutually exclusive entirely unaddressed.

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 description names a specific analytics resource and enumerates what the response covers: spend vs expected to date, projected end, and on_track/under/over status. That is more specific than a bare resource name and distinguishes it from analytics_forecast and analytics_breakdown. It does not explicitly say how it differs from those siblings, keeping it at 4 rather than 5.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools (analytics_forecast, analytics_breakdown, analytics_timeseries, analytics_digest) that an agent could pick instead. The only usage-like hint is the '(5% default)' tolerance note, which describes a parameter rather than when to select this tool.

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