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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds a great deal beyond them: null checkedAt means not measured yet, sentimentSource enumerates 'model'/'keyword'/null with the instruction to disclose keyword estimates, and shareOfVoiceSample carries counts, sample, a 95% Wilson interval, tooThin and earlyReading with a warning to always quote the sample. The demandBand caveat (a band, never a count, null on non-paid plans or when unmeasured) discloses plan-dependent behavior an agent could not infer from structured fields.

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-loads purpose and the buyer question before the field inventory, and with no output schema the field-by-field enumeration is largely earning its place. It is dense and long, with some near-restatement (sentiment/sentimentSource listed in the row then re-explained), but no filler sentences or marketing language.

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 must carry the return contract, and it fully does: top-level fields, the per-prompt query row, the meaning of every ambiguous value, and the interpretation caveats on share-of-voice and demand. For a read-only single-parameter tool whose complexity lives in the response, an agent has everything needed to call it and to report results correctly.

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 coverage is 100% and the single siteId parameter already documents the connected-app-vs-API-key behavior and the select_site fallback. The description never mentions siteId or adds any scoping meaning beyond the schema, so the baseline 3 applies rather than a higher score for added 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?

Opens with a specific verb-and-resource statement plus scope: "The latest verdict for every tracked prompt on a site," and frames the agent question it answers. It then names the exact sibling tools (get_citation_history, get_evidence, get_sources_report) that cover adjacent needs, so the tool is distinguishable without opening any schema.

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 explicit routing: use this for a current snapshot, use get_citation_history "for a window or a trend," get_evidence "for the answer text," and get_sources_report "for domains ranked across all prompts." It also defines the ambiguous word "latest" as each prompt's newest answers per engine rather than a time window, removing the most likely mis-invocation.

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