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

Annotations only declare read-only, idempotent, open-world, non-destructive, so the description carries real weight and adds a lot: controls are checked before the run, the tool refuses and does not charge on a failed control, it returns changes and bands but never monthly volumes, and results carry a run id, date and citation line. The payment paragraphs muddy this by saying both 'this tool charges nothing' and 'Price: $3.00 per run', so an agent cannot cleanly predict whether this call returns data or only a payment_url.

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?

The usage trigger and result summary are well front-loaded, but the payment material is repeated and redundant: MPP and the Stripe shared payment token are each explained twice, and the free-sample URL plus price restatement add bulk. The tool's own charging model is stated in contradictory terms across adjacent sentences, which costs more than the extra words buy.

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?

With no output schema, the description does the necessary work of describing what comes back: YoY change versus an everyday basket, a volume band, a 10-K confirmation flag, plus run id, date and citation. What remains unresolved is the payment handshake — whether the first call yields results or only a payment_url and what happens after the POST — which matters because the tool costs money to complete.

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 both parameters are self-documenting, including the example 'protein snacks' for phrase and the comma-separated 'also' keywords. The description adds no additional meaning about how phrase vs also interact or how category breadth is resolved. Baseline 3 is appropriate when the schema does all the work.

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 states a specific measurement: a category's year-on-year search change against a basket of ten unrelated searches, a volume band, and 10-K corroboration. That is far more than a restatement of the name and makes the tool's distinct output recognizable. It stops short of naming how it differs from near-neighbors like run_share_of_search or run_angle_demand, which are listed as siblings.

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?

It opens with an explicit trigger: use when the user asks whether interest is really growing, or whether a search rise is more than noise before investing. That is clear context for selection. There is no when-not guidance and no named alternative tool for the decline/noise case, so routing among siblings is left to inference.

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