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

Adds meaningful context beyond the annotations: it discloses that Trends has no public API, that endpoints can change without notice, that roughly 12 requests are sent, and that results are never served from cache. The annotation set (readOnly, idempotent, openWorld, non-destructive) already covers the safety profile, and the description enriches it with cost and caveat detail.

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?

Three sentences, each earning its place: what it does, why it exists, and when to run it. The purpose is front-loaded and the framing caveat follows naturally.

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-value detail is not required. For a zero-parameter diagnostic, the description supplies the why, the when, and the operational cost (requests, cache behavior), leaving nothing an agent needs to invoke it 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?

The tool takes no parameters, so the baseline is 4; the description correctly implies it is argument-free by describing a fixed probe of all endpoints. No additional parameter semantics are needed or missing.

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 action (probe each Google Trends endpoint with a small request) and the output (which ones answer). An agent can immediately distinguish this diagnostic tool from the data-retrieval siblings like interest_over_time or trending_now.

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?

Explicitly names the trigger condition ('Run this when a tool fails unexpectedly') and the diagnostic decisions it disambiguates: rate-limiting, endpoint change, or network failure. This routes the agent away from guessing or blindly retrying failed sibling calls.

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

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

Adds substantial context beyond the annotations: it discloses exactly what is removed (cached answers, session cookie, back-off state) and, crucially, what is preserved ('Saved Trending Now history and the watchlist are never touched'). This confirms and enriches the destructiveHint=false / idempotentHint=true profile rather than contradicting it.

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 the core action and the rejection/safety caveat is well placed at the end. The 'what' enumeration line is dense but each token maps to a real option, so little 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 two-parameter cache-clearing tool with an output schema, the description covers destruction scope, parameter values, and side effects. An agent has everything needed to invoke it correctly; return values are handled by the output schema.

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%, so the description carries the full burden and does so: it defines the default value of 'what' ('expired — only answers too old to be used even as a fallback'), lists the alternative scopes (all, trending, timeseries, regions, related, explore), and explains reset_session's side effects. Both parameters are fully specified in prose.

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 ('Delete saved answers') and even the downstream effect ('so the next call asks Google again'). No sibling tool clears cache, so the agent can place it immediately among the trending/history tools.

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 clear context for use: 'reset_session' is 'for a clean start after a block', and the 'what' values enumerate the scopes. It stops short of an explicit when-to-use-this-vs-alternatives statement, but no competing cache tool exists.

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

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

Annotations already cover readOnly/openWorld/idempotent/destructive, so the remaining burden is low. The description adds genuinely useful interpretive context: values are relative share of each place's own searches, not raw counts, so a small country can outrank a large one. That prevents a real misreading of the output, though nothing is said about rate limits or failure modes.

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 description is short, front-loads the core capability, then separates the geos format note into its own block. Every sentence carries information, with no filler.

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-value explanation is not required. However, with 5 of 6 parameters undocumented and no explicit when-to-use routing against several close siblings, the definition is only adequate for a tool this configurable.

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% across 6 parameters, so the description must carry the load. It documents only 'geos' well (comma-separated codes, countries or regions, not worldwide), while keyword, points, category, property, and timeframe are left completely opaque — notably timeframe and property, which materially change results.

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 concrete verb and resource ('one term in up to 5 countries or regions side by side') plus the analytical payoff ('where it matters more, and whether the curves move together'), which is more specific than the bare tool name. It does not explicitly differentiate itself from near-siblings like trending_across_countries or compare_many, so it stops short of a 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?

Usage is implied by the scope constraint ('up to 5 countries') and the format note for geos, but there is no explicit statement of when to pick this over compare_many, trending_across_countries, or interest_by_region. An agent must infer the selection condition from the sibling list alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine value beyond that: cost ('two requests per group of four terms') and output scaling ('largest average is 100'). However, it discloses no rate-limit ceiling, error behavior, or auth context. Given annotations carry the safety burden, a 3 reflects useful but not rich added context.

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-loaded with the core purpose, then the rescaling rationale, then anchor, then return/cost. Each paragraph earns its place, though the rescaling explanation runs slightly long for a definition.

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 format needn't be explained (though partially is). But with 0% schema coverage, a 6-parameter tool leaves five parameters wholly undocumented in both schema and description — a real gap for correct 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 coverage is 0%, so the description must compensate. It explains 'anchor' well (shared term, blank = auto, mid-sized selection rationale), but leaves geo, category, property, timeframe, and the required keywords format undocumented. It compensates for one of six parameters, so the baseline 3 is appropriate at best.

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 (rank) and resource (6-25 terms) plus the scope that distinguishes it from single-comparison siblings: 'past Google Trends' limit of five per comparison.' The rescaling rationale makes its unique role unmistakable.

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 scope condition (6-25 terms, beyond the five-term limit) clearly cues when to reach for this over the native comparison, and the anchor guidance covers the main decision point. It stops short of naming a specific sibling alternative or exclusion.

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

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

Annotations already cover read-only, idempotent, open-world behavior, so the bar is lower. The description adds real behavioral context the annotations cannot: the two curves are aligned by position, so day 10 of one sits next to day 10 of the other. That alignment rule meaningfully affects how results should be read.

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 definition is front-loaded with the core concept and then uses labeled lines for the parameters that need explanation. It is compact and every sentence contributes; only the slightly terse opening framing ('one term') costs it a point.

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 values need no explanation. However, for a 7-parameter tool with zero schema descriptions, the description omits too many parameters (points, geo, property, category) to be considered fully complete, even though the central comparison semantics are well covered.

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 0% across 7 parameters, so the description carries the full burden. It documents the two most distinctive parameters well, spelling out accepted period formats and the three 'against' values, but leaves points, geo, property, and category entirely unexplained — notably 'points', which controls resolution and is not self-evident from its name.

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 capability: plotting one term across two time ranges on a shared scale, with concrete examples ('this year against last year'). It is clearly differentiable from nearby siblings like interest_over_time and compare_locations, though it never names them explicitly.

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 opening examples imply when the tool fits, and the 'against' options hint at comparison modes, but there is no explicit statement of when to prefer compare_periods over compare_locations, compare_many, or interest_over_time. Usage is implied rather than prescribed.

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

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

Annotations already establish this as a safe, idempotent read. The description adds real behavioral context beyond them: each term's five-year rhythm is measured, output is sorted by soonest publishing need, and terms lacking a yearly pattern are flagged as evergreen.

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?

Reasonably short and front-loaded with the core purpose, but the text is broken into awkward fragments and the trailing 'lead_weeks' line reads as a dangling note rather than integrated guidance.

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 an output schema present, return values need not be explained, and annotations cover safety, so the description's focus on output semantics and lead_weeks is well placed. However, the three unexplained input parameters (geo, category, property) leave a gap for a five-parameter tool.

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% for five parameters, so the description carries the full burden. It explains lead_weeks precisely and implies that keywords is the topic list, but geo, category, and property are left entirely undocumented — most of the parameter surface contributes nothing.

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 output: a publishing calendar derived from seasonality, giving peak timing and the must-be-live date for up to 8 topics. It is clearly distinguishable from the related 'seasonality' sibling by its publishing-deadline framing, though it never names that sibling to draw the contrast explicitly.

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?

Usage is implied by the publishing-planning framing and the 'up to 8 topics' limit, but there is no explicit when-to-use statement or comparison to alternatives like seasonality or interest_over_time. An agent can infer the scenario but receives no routing guidance.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real operational disclosure: the data is stitched from overlapping 8-month windows joined on shared days, scaled to one 0-100 series, with a ~4-year cap of eight windows at two requests each. That request/limit context is valuable and not in the schema, though return-shape details are left to the output schema.

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?

Content is mostly front-loaded and every paragraph earns its place — the windowing mechanics, the cap, the weekday add-on, then parameter notes. Slightly sprawling with the hard line break mid-sentence, but no filler.

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 7-parameter tool with an output schema, the description covers the non-obvious mechanics (windowing, scale, cap) and the two most important parameter semantics. The undocumented geo/category/property parameters are the remaining gap, though they are largely self-explanatory.

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%, so the description carries the burden, and it only partially compensates: start/end format (YYYY-MM-DD, end defaults to today) and points (the series is averaged down to that many rows, summary always included) are explained, but geo, category, property, and keyword are left undocumented.

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+resource: day-by-day interest data over a long range, explicitly contrasted with the ~9-month daily limit that Google Trends imposes. That framing makes it clearly separable from interest_over_time and other siblings without naming them.

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 a clear use condition — you need daily granularity over ranges beyond ~9 months, up to about 4 years — and notes it also returns a weekday pattern. It stops short of explicitly naming the sibling to use for shorter ranges, so the exclusion is implied rather than stated.

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

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

Annotations already declare read-only, idempotent, open-world safety, so the bar is lower. The description adds genuine behavioral context about what a category does to search results (narrowing 'jaguar' to the car vs. the cat) and how the output id is consumed downstream.

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-loaded with the core action and the numeric example; the middle paragraph earns its place by explaining the narrowing semantics. The third sentence is a small tag-on but still informative, with little waste.

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 values needn't be explained. For a simple two-parameter lookup the description covers intent well, but it leaves the `limit` parameter and the exact query semantics unaddressed, which is the remaining gap.

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 0% for two parameters. The text implies `query` is a category name to look up, but never says so directly, and `limit` (default 25) is completely unexplained. With no schema descriptions, the description should compensate but does not.

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: 'Find the id of a Google Trends category', with a concrete example ('Autos & Vehicles' = 47). It implies a lookup role distinct from find_topic/find_location, but never names or contrasts those siblings, so an agent must infer the boundary.

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 usage context: pass the returned id as `category` to the explore tools, and note that with no keyword a category id shows interest in the whole subject. It stops short of an explicit when-not-to-use or a direct comparison to find_topic/find_location.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld behavior, so the safety profile is covered. The description adds value beyond that: it explains the code format taxonomy (IR, US, US-CA, US-CA-807) and clarifies that a blank result means worldwide scope, which the annotations do not convey.

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 the core purpose in the first sentence, then uses compact labeled lines for the two parameters. Dense but every line earns its place; the code-format line is slightly terse but functional.

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 an output schema present, return values need not be described, and the description covers both input modes, the geo-code format, and the blank-means-worldwide convention. The only omission is the meaning of 'limit', which is minor given its default.

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 0%, so the description carries the burden, and it documents both query (partial name or code, with examples) and inside (a code whose sub-locations to enumerate, with an arrow example) well beyond the bare schema. Only 'limit' is left unexplained, though its default of 25 makes it largely self-evident.

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 ('Find the location code (geo) for a country, region, state or metro area by name'), which instantly separates it from sibling lookup tools like find_category and find_topic. The output is named explicitly (a code), so an agent knows exactly what it retrieves.

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?

Explains how to drive the two core modes: 'query' for a partial name or code, 'inside' to list sub-locations of a known code. It also gives the critical downstream context that 'every other tool takes them as `geo`; blank means worldwide,' which is genuine usage guidance. It stops short of naming an explicit alternative tool or a when-not condition, so not a 5.

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

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful algorithmic context by defining a spike as a run of points at least `threshold` times the term's usual level around that date, based on the surrounding year's median.

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 description is front-loaded with the returned spike attributes, then defines the core spike concept and use cases. It is efficient and avoids repetition, though the first sentence is somewhat indirect rather than leading with a direct action verb.

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?

The output schema covers return values and annotations cover safety, so those need not be described. However, with 7 parameters and no schema descriptions, the description is incomplete because it only clarifies `threshold` and leaves the remaining parameters undocumented.

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% across 7 parameters, so the description must compensate. It explains only `threshold`; the other six parameters, including required `keyword`, plus `geo`, `limit`, `category`, `property`, and `timeframe`, are not given meaning in either the schema or the description.

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 clearly identifies a specific analytical resource: detecting spikes in a term's search interest and returning start, peak, duration, and magnitude. It is more concrete than a tautology, but it does not explicitly differentiate itself from sibling tools such as interest_over_time or trend_details.

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 gives explicit use cases: dating events, launches, outages, news cycles, and distinguishing one-off bursts from real growth. It does not state when not to use it or name alternative sibling tools, so it falls short of the highest usage-guidance bar.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds semantic transparency by explaining how topics count searches versus exact terms, which helps an agent understand the tool's results, though it omits operational details like rate limits.

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 sentences, front-loaded with purpose, then a concise explanation, then a usage directive. No redundant or filler content; every sentence serves the explanation.

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?

Given an existing output schema and comprehensive safety annotations, the description provides sufficient context: what the tool does, the distinction from keyword search, and how to use the returned ids. No critical gaps for an agent to invoke it 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 0% for the single 'text' parameter. The description implies the parameter is a search term/keyword and gives an example ('tesla'), but does not specify format, whether phrases are allowed, or how the text maps to returned topics, so it only partially compensates.

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 (Find) and resource (Google Trends topics), and clarifies output (ids that select them). It distinguishes from keyword search by contrasting search terms and topics, making the tool's scope unmistakable.

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?

Explains the conceptual difference between search terms and topics and instructs to pass a topic id wherever a keyword is expected. This provides clear context for when to use the output, but does not name sibling tools or explicit exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety behavior is covered. The description adds that the response inventory includes session/cache state and saved history, which is mild extra context, but it says nothing beyond that about what reading this state does or how fresh it is.

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 two tight fragments with the contents front-loaded and the usage cue at the end; nothing is padded. The list-style phrasing is slightly ambiguous about whether these are returned or configured, which keeps it from a 5.

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 an output schema present, return-shape detail is unnecessary, and annotations cover the safety profile. For a simple, parameter-free discovery tool the description is nearly complete, lacking only an explicit 'first call in a session' framing.

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?

The tool takes no parameters, so the schema carries no semantic burden and the baseline for zero-param tools applies. Nothing in the description is needed to compensate for parameter documentation.

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 enumerates what the tool surfaces (version, settings, session/cache state, saved history, tool list), which is specific for a zero-param introspection call, but it uses a bare noun list with no verb and no differentiation from siblings like check_endpoints or clear_cache. An agent can infer it is a discovery/state tool, but the phrasing leaves the action implicit.

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?

'Call this first when unsure' gives an explicit, actionable trigger for invocation. It stops short of naming when-not-to-use conditions or alternative siblings, so it is clear context rather than full routing guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds important operational context beyond annotations: it identifies the local data file, lists the available tables and columns, notes unix-second UTC times, and marks JSON-list 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?

The purpose is front-loaded in the first sentence. The table definitions and example are information-dense and directly support query construction, with no redundant or filler text.

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?

The tool is complex, but annotations and an output schema already cover safety and return structure. The description supplies the data model, key column semantics, and an example, though it omits the limit parameter and any further query restrictions such as row caps or forbidden statements.

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%, so the description should compensate for both parameters. It explains the query parameter well by describing allowed SQL and providing table schemas, but it says nothing about the limit parameter, its default of 100, or how row limiting interacts with returned results.

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 verb and resource: 'Run a read-only SQL SELECT on the local data file.' It also distinguishes the tool from sibling history tools by saying it is for questions they do not cover, which is enough for an agent to identify its role.

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 gives clear context for when to use SQL instead of other history tools: 'for questions the other history tools do not cover.' However, it does not name specific alternative tools or state exclusions such as preferring structured tools whenever possible.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: the 0-100 normalization relative to the strongest place, the percentage split for multi-term queries, and what include_low_volume does. It does not mention rate limits or pagination, which limits it from a 5.

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 description is compact and front-loaded, leading with the core purpose before the term-count behavior and parameter semantics. The shorthand 'geo: ... resolution: ...' structure is efficient, though slightly terse for readers unfamiliar with the domain.

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 an output schema present, return values need not be explained, and the description still usefully clarifies the 0-100 scale and percentage semantics. The main remaining gap is the four undocumented parameters, but the core call-correctly information is present for an 8-param read-only tool.

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% across 8 parameters, so the description must compensate, and it only covers geo, resolution, include_low_volume, and implicitly keywords. limit, category, property, and timeframe are left entirely undocumented in both places, so the description only partially closes the 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 description gives a specific verb+resource ('where a term is most popular') and immediately defines the output unit as places ranked by interest, distinguishing it from siblings like interest_over_time or compare_locations. The one-term vs 2-5-term explanation makes the ranking semantics unambiguous.

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 conveys clear usage context: blank geo ranks countries, a country ranks its regions, a region ranks its cities, and how results differ for one term versus 2-5 terms. It does not explicitly name an alternative tool to use instead, so the routing guidance is implicit rather than spelled out.

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

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

Annotations already declare readOnly/idempotent/openWorld safety, lowering the bar, yet the description adds real behavioral context: result granularity scales with timeframe (minute/hour up to ~9 months daily, 5 years weekly, longer monthly) and long series are averaged down to the requested points. That is substantive detail an agent cannot get from annotations.

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-loaded with the one-line purpose, then a clean per-parameter list. It is dense but each line maps to an otherwise undescribed parameter, so little is wasted given the 0% schema coverage; only minor tightening is possible.

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 six optional parameters, an output schema present, and no schema descriptions, the definition still documents every input, the default-location behavior, and the resolution/averaging semantics. Nothing an agent needs to invoke it correctly is missing.

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%, so the description carries the full burden and does so thoroughly: keyword operators ('a + b', 'a -b', '"a b"'), timeframe shorthand (1h...all, 6m/2y/45d, year, month, explicit date pairs), geo, category, property enum values, and the meaning of points=0. Every one of the six parameters is explained.

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 sentence states a specific verb, resource and scope: 'Search interest over time for up to 5 terms on one shared scale — the main Google Trends chart.' This is unambiguous and hints at primacy among siblings, but it never names an alternative (compare_periods, trend_details, keyword_overview) to sharpen the distinction.

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?

Usage is implied through dense parameter guidance and useful pointers to helper tools (find_topic, find_location, find_category), which tell the agent how to construct a call. However, there is no explicit when-to-use vs. when-not guidance against the many overlapping siblings that also return trend data.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the two-request-per-seed cost/pacing, deduplication of queries appearing under multiple seeds, per-idea seed attribution, and the breakouts-first sort order for rising ideas.

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 short sentences, front-loaded with the core purpose, followed by deduplication/sorting behavior and cost. The line 'an idea related to several seeds sits at the centre of the subject' is slightly decorative but still conveys that multi-seed ideas are signals.

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?

Output schema exists so return values need no explanation, and cost/merge/sort behavior is well covered. What is missing is guidance on the five undocumented filter parameters (geo, timeframe, category, property, limit), which matters for a 6-parameter tool.

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 0% across 6 parameters, so the description carries the burden and only partially does so. It constrains `seeds` to at most 5 terms and explains the merge semantics, but geo, category, property, timeframe, and limit are left entirely undefined in both schema and description.

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 resource (related/rising keyword queries) and a specific verb-like output ('Keyword ideas from what people actually search next'), naming the two result flavors (rising and top). It does not, however, distinguish itself from the very similar sibling related_queries, so an agent must infer the boundary.

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?

Usage is implied: feed it up to 5 seed terms to get merged idea lists. There is no statement of when to prefer this over related_queries, trending_now, or keyword_overview, and no exclusions or prerequisites beyond the seed count constraint.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world. The description adds genuine, non-redundant behavior: it fans out to four requests and degrades gracefully, reporting a refused part while still returning the rest. That partial-failure semantics is exactly the kind of context annotations cannot express.

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?

Three short sentences, front-loaded with the composite scope before the usage cue and the fan-out caveat. Every sentence adds information; only minor polish is missing.

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?

The composite scope, first-look guidance, and partial-failure behavior are covered, and the presence of an output schema means return values need no explanation. However, with five undocumented parameters at 0% coverage, an agent cannot confidently set geo, timeframe, or category from the description alone.

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% across five parameters (geo, category, property, timeframe, keyword), and the description mentions none of them. It gives no syntax, format, or default guidance (e.g. '12m' timeframe strings, geo codes, category IDs), so it fails to compensate for the empty schema descriptions.

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+resource ('whole Google Trends page for one term in a single call') and enumerates the bundled outputs (curve, direction, top places, related searches). This implicitly distinguishes it from the granular siblings (interest_over_time, related_queries, interest_by_region) by signalling it is the aggregate first-pass tool.

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?

'Use it as the first look at a keyword' gives explicit positioning guidance for when to reach for this tool. It does not name an alternative or state when not to use it (e.g. when only one data section is needed), so it stops short of full routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description adds real value by disclosing the matching rule: whole-word, case-insensitive containment in trend title or query, with the concrete 'ai' vs 'rain' example. It also clarifies geo defaulting behavior. Return shape is left to the output schema.

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-loaded with the purpose, then compact per-parameter notes. No filler sentences, though the geo phrasing ('blank = the default location, else US') is slightly tangled and costs a little clarity.

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 an output schema present, return values need not be described, and the matching semantics are well covered. However, the omission of hours and limit semantics, which control the time window and result count, leaves a meaningful gap for a 4-parameter tool.

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%, so the description must carry all parameter meaning. It documents 'terms' thoroughly with format and matching semantics and explains 'geo' defaulting, but leaves 'hours' and 'limit' entirely unexplained despite both being part of the 48h/25-item behavior.

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 first sentence names the resource (current trends) and the operation (matching them against your subjects), with the use case (newsjacking/timely content) making the intent concrete. It is distinguishable from siblings like trending_now or trend_details, though it never directly names an alternative.

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?

Usage is implied through the newsjacking/timely-content framing, which tells the agent the scenario this tool serves. There is no explicit when-not-to-use guidance or routing to sibling tools such as trending_feed or keyword_overview.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description goes beyond them by defining the semantics of the result categories (Rising = largest growth vs prior period, Breakout = >5000% growth, Top = most searched with 100 being most common), which is genuinely useful interpretation context an agent cannot get from annotations alone.

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?

Content is front-loaded with the core purpose before the interpretive details, and the Breakout/Top explanations earn their space by clarifying return values. It is slightly verbose in the multi-line definition block but has no throwaway sentences.

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 values needn't be re-explained, and annotations cover the safety profile. The remaining gap is the undocumented limit parameter and absent detail on the deferred geo/timeframe/category formats, which is a modest but real shortfall for a 0%-coverage schema.

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%, so the description must compensate for six parameters. It documents keyword ('one term or topic id') and defers timeframe, geo, category, and property to interest_over_time, but leaves limit completely unexplained and gives no format details (timeframe syntax, geo codes) that the empty schema lacks.

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 opens with a specific verb+resource framing ('What else people who search a term also search: the top related queries and the rising ones'), which is concrete enough to distinguish the intent from sibling tools. It does not explicitly name related_topics as the contrasting sibling, so sibling differentiation is only implicit.

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?

Usage is implied by the description of what the tool returns, but there is no explicit 'use this when...' statement, no mention of when to prefer it over related_topics or keyword_ideas, and no prerequisites. The only routing signal is a parameter cross-reference to interest_over_time.

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

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

Annotations already declare read-only/idempotent/open-world, so the description earns credit for adding real behavioral context: the auth requirement (GTRENDS_COOKIE or GTRENDS_COOKIES_FILE) and the fact that it reports emptiness honestly rather than fabricating data. This goes well beyond the annotations.

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-loaded with what the tool returns, then the crucial caveat in a second paragraph. Two sentences in the caveat are slightly verbose but every sentence carries useful information.

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?

The presence of an output schema means return values need not be explained, and the auth caveat is well covered, but for a six-parameter tool with zero schema descriptions the definition is incomplete on inputs. Adequate but with a clear gap.

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% across six parameters (geo, limit, keyword, category, property, timeframe), and the description only alludes to a search 'term' without documenting any of them. It does not compensate for the coverage gap, leaving the semantics of most inputs to the caller's guesswork.

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 resource (topics searched alongside a term, top and rising, with topic ids), which is clear enough to distinguish from related_queries, which it names. It is phrased as a noun list rather than an explicit verb, but the content is unambiguous.

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 gives a clear conditional: without a signed-in cookie the tool usually returns empty, and related_queries works either way, effectively steering the agent to the alternative when unauthenticated. It does not cover geo/limit/timeframe selection choices.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful context: the 5-year default, that 'all' extends to 2004, and that growth/decline is detrended so rising terms are not mistaken for seasonal. This detrending disclosure is behavioral context the annotations cannot provide.

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-loaded with the core purpose and the parenthetical asides are efficient, though the return-value list in the middle sentence is somewhat baggy and the trailing lead_weeks definition feels detached.

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 describing return fields is optional (though done well). However, for a 6-parameter tool at 0% schema coverage, leaving geo/category/property semantics entirely unexplained is a real gap.

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 0%, so the description must carry the parameter burden. It explains timeframe ('all' = back to 2004) and defines lead_weeks, but geo, category, and property remain undocumented in both schema and description.

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 sentence names a specific analysis (seasonal rhythm of a term: peak/dip months, reliability, publishing timing) with a clear verb-resource framing. It is readily distinguishable from siblings like interest_over_time (raw series) or content_calendar (scheduling).

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?

Usage is only implied - the tool is for understanding seasonality and choosing a publish date - but the description never says when to prefer it over interest_over_time, compare_periods, or content_calendar. No exclusions or prerequisites are stated.

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

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

The annotations already establish read-only, idempotent, open-world, non-destructive behavior. The description usefully adds scope and output behavior: up to 4 competitors, share over the whole range, start/end fifth values, and change in points. It does not cover auth or rate limits, but the annotation coverage lowers that burden.

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 description is front-loaded with the core definition, then adds rationale, return details, and one input-resolution rule. It is readable and mostly earns its length, though the return-detail sentence is partially redundant because an output schema exists.

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 an output schema present, the description need not detail return values, yet it does. It still omits meaning for several optional parameters and provides no sibling differentiation, leaving an agent with gaps despite adequate coverage of the core brand/competitor use case.

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% across six parameters. The description clarifies that brand can be a topic id resolved via find_topic and that competitors may include up to 4 brands, but it leaves geo, category, property, and timeframe unexplained.

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 clearly defines the tool as computing a brand's share of search against up to 4 competitors and how it moves. It states the specific metric and scope, though it does not explicitly distinguish itself from sibling analytical tools such as keyword_overview or compare_many.

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 provides one concrete usage rule — use topic ids via find_topic when a brand name has other meanings — and implies the tool is useful as a leading market-share indicator. However, it gives no explicit when-to-use or when-not-to-use guidance relative to the many sibling trend tools.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true; the description reinforces this by stating that re-seen trends are updated rather than duplicated, which explains the idempotency in user terms. It also discloses the retention rationale and per-country scope. It does not say where history is stored or whether writes need any setup, so it stops short of full disclosure.

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-loaded with the action and rationale, then parameters, then the scheduling hint. The embedded CLI invocation and the 'run it on a schedule' aside add a little redundancy against the cron sentence, but every sentence still carries usable information.

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 an output schema present, return values need not be explained. The description covers purpose, motivation, scheduling guidance, parameter formats, dedupe behavior, and the sibling tool for retrieval, which is everything an agent needs to call it 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 description coverage is 0%, so the description carries the load and does so well: geos is described as comma-separated country/region codes, up to 12, with blank meaning the default location else US; hours is bounded 1-191 with 24 recommended for a daily run. Both parameters gain meaning absent from the bare schema.

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 ('Save the current Trending Now list to the local history') and immediately explains the motivating constraint (Google drops trends after about a week). It is clearly distinguishable from trending_now (live read) and trending_history (the query side, which it names).

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?

Explicitly tells the agent to run it on a schedule, gives a concrete example (cron with `gtrends-mcp-full snapshot US,GB`), recommends hours=24 for a daily cadence, and routes follow-up queries to trending_history. When-to-use and what-to-do-next are both spelled out.

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

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

Annotations already declare readOnly/idempotent/openWorld/destructive=false, so safety is covered. The description adds real value beyond them: with_chart triggers 'two more requests,' disclosing a cost/latency trait, and geo blank resolves to a default location. That is meaningful behavioral context the structured fields do not carry.

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?

A front-loaded summary sentence followed by short per-parameter clarifications; nothing is padded. The parameter notes are compact and each earns its place.

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 values need not be explained, and the headline purpose is captured. But with news and hours undocumented and no routing guidance among the dense sibling set, the definition is not fully complete for a 5-parameter tool.

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 0%, so the description must compensate. It documents trend, geo, and with_chart semantics well, but the news (default 5) and hours (default 48) parameters get no explanation at all, leaving two of five parameters opaque.

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-driven scope: fetching every query, news, and hourly curve for 'one current trend.' This pins down the resource clearly, though it does not explicitly name a sibling (e.g. snapshot_trending or trend_momentum) to disambiguate among the many trend_* tools.

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?

'one current trend' implies context, and the geo: blank default note hints at usage, but there is no explicit when-to-use vs alternatives guidance despite a crowded sibling set (interest_over_time, daily_history, trending_now, etc.). Usage is inferable but not stated.

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

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

Annotations already cover read-only, idempotent, open-world safety, so the bar is lower. The description adds genuine behavioral detail beyond them: how trends are grouped (same title, or one country's title appearing among another's queries) and the default geo set when blank.

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?

Content is front-loaded with the core idea first, then mechanism, then parameters. The bulleted param notes are efficient; the only mild waste is repeating 'Pulls Trending Now' which the title already implies.

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-value explanation is unnecessary. The description covers the essential selection semantics (geo set, cross-country threshold), leaving only the hours and limit parameters unaddressed.

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 0%, so the description carries the full burden. It explains geos (comma-separated codes, max 12, blank = default list of 8 countries) and min_countries (threshold), but leaves hours and limit completely undocumented.

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 analysis (trends live in several countries at once) and explains the mechanism (pull Trending Now per country, group identical searches). This clearly distinguishes it from siblings like trending_now and compare_locations.

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 gives clear context for when this cross-country view applies versus the single-country trending tools, and the 'the stories that travel' framing signals intent. It stops short of explicitly naming a sibling as the alternative or stating when not to use it.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds real behavioral context beyond that: expected volume (~10-20 trends), single-request cost, and that results include headlines and links. Only a note on pagination/rate behavior is missing.

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?

Three short sentences, front-loaded with the resource definition and followed by the sibling comparison and the geo semantics. Efficient, with only mild informality ('the news stories behind each').

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 values need no explanation, and the description covers volume, content, locale semantics, and sibling routing. The only gap is the undocumented limit parameter.

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%, so the description must carry parameter meaning. It does well for geo (country code, blank = default location, else US) but says nothing about the limit parameter, leaving one of two params entirely undocumented.

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+resource ('top daily search trends with the news stories behind each') and explicitly frames it as Google's public trending feed. It is immediately distinguishable from trending_now in both what it returns and its weight.

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?

Names the sibling alternative (trending_now) and gives the condition that selects this tool: lighter, one request, carries headlines and links, best for 'what is in the news in <country> today'. Usage is explicit rather than implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds genuine behavioral context: it operates offline on previously stored snapshots and defaults to listing the biggest saved trends when unfiltered. It does not state pagination or result-size behavior.

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 core purpose is front-loaded in the first sentence, and the parameter notes are compact and non-redundant. The layout is slightly fragmented but every line earns its place.

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 values need not be explained, and annotations cover the safety profile; however two of five params are undocumented and there is no explicit alternative-tool routing, leaving minor but real gaps for an agent.

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 0%, so the description carries the full param burden, yet it documents only 3 of 5 params (contains, geo, days) — with useful detail (whole-word matching, single location code, blank = all, days counted from trend start). limit and min_volume are left completely undefined in both schema and description.

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 (search) and resource (saved Trending Now history) plus the value dimensions returned (when, how big, how long). It also distinguishes itself from live siblings by naming snapshot_trending as the data source, so an agent can separate it from trending_now/trending_feed.

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?

'Works on what snapshot_trending has stored — no network' and 'with no filter it lists the biggest saved trends' imply usage context, but there is no explicit when-to-use-this-vs-trending_now/trend_details guidance or exclusion criteria.

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

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

Annotations already declare this a read-only, idempotent, open-world, non-destructive operation, so the safety profile is covered. The description adds genuinely useful behavior in the 'contains' whole-word matching rule and the note that categories appear in the result header, but it says nothing about pagination/limit behavior or rate limits, which are real gaps for a list tool.

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 core purpose is front-loaded in the first sentence, followed by a tight bullet list of parameters; almost every line carries new information. Slightly telegraphic fragment style but no wasted sentences.

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 an output schema present, the description need not explain return values, and annotations cover the safety profile, so the remaining burden is parameter meaning — which is largely met for a zero-coverage schema. Only limit and min_volume semantics are missing, a minor completeness gap.

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%, so the description must carry the load, and it does document six of eight parameters with concrete meaning: geo syntax (US, GB, DE, IR, US-CA), hours values, category examples, status and sort_by options, and the whole-word semantics of contains. limit and min_volume are left undocumented, which keeps it short of a 5.

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 verb and resource — retrieve the full Trending Now list for a country or region — and scopes it to real-time search behavior. It is clear, but it never names how it differs from close siblings such as trending_feed, snapshot_trending or trending_history, so the agent must infer the distinction.

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?

Usage is implied through the documented filters (status active/ended/all, sort_by, category) rather than stated as when-to-use guidance. There are no explicit exclusions or pointer to an alternative tool, leaving selection among the many trending_* siblings to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds substantive behavior beyond that: each term is normalized to its own scale so small terms aren't flattened, and the five-label taxonomy (breakout/rising/stable/declining/new) is disclosed. It does not state rate limits or how the scale is computed, but this is genuinely additive context.

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 opening line is front-loaded and useful, but the second paragraph is a long comma-run that lists metrics in prose where a compact list would read faster. Nothing is outright wasted, yet the phrasing is denser than it needs to be.

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 an output schema present, the description need not explain return values, yet it spends most of its length doing exactly that while omitting usage guidance and parameter meaning. For a read-only analysis tool with 0% schema coverage, it is adequate but leaves the invocation side underspecified.

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 four of five parameters (geo, category, property, timeframe) are entirely undocumented anywhere. The description contributes only the implicit cap of 8 keywords, leaving geo/category/property/timeframe formats and defaults unexplained, which is a real gap for a 5-param tool.

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: it measures whether each keyword is growing, fading, flat or exploding, and enumerates the per-term metrics and labels. It is clear what the tool produces, but it never names or contrasts a sibling (interest_over_time, trend_details, seasonality), so an agent must infer where it fits in the family.

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 statement, no prerequisites, and no exclusion pointing to an alternative tool. The description only explains what the output contains, leaving the agent to guess when momentum is the right call versus interest_over_time or compare_periods.

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

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

Annotations already declare the safety profile (not read-only, idempotent, non-destructive, closed-world), so the description need not restate it. The description adds that entries persist and are tracked over time, but does not say what happens on a duplicate keyword or whether a prior entry is overwritten — the one behavior an idempotent add tool should clarify.

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?

Three short, front-loaded lines with no filler; the purpose sentence comes first and each parameter line is a compact definition. Slightly terse for a mutation tool, but nothing 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?

An output schema exists, so return values need no explanation, and annotations cover the mutation/safety profile. All three parameters are semantically covered, leaving only duplicate-handling behavior as a minor gap for a 3-param idempotent add tool.

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 carries the full burden and largely does: keywords accepts comma-separated terms or topic ids, geo is the location with blank meaning default, and note is an optional label like a client or campaign. Only keyword multiplicity/format edge cases (spacing, mixed ids and terms) remain unspecified.

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 ('Put terms on the watchlist') and ties it to a downstream sibling, watchlist_report, which tracks direction over time. It is clearly the add-side counterpart to watchlist_remove, though it never names that sibling explicitly.

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 link to watchlist_report implies the use case (set up tracking), but there is no explicit when-to-use / when-not guidance and no mention of alternatives such as watchlist_remove or watchlist_report for reading results. Usage is inferable rather than stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: that past readings are retained, which scopes exactly what destruction occurs, and that a blank geo clears the term from every location.

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?

Two tight sentences with zero waste; the core action is front-loaded and the geo-scoping caveat follows immediately. Every clause earns its place.

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 values need no explanation, and annotations cover the safety profile. For a two-parameter mutation, the description covers the key retention and geo-scope behaviors; only keyword input format and failure cases are left implicit.

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%, so the description must compensate. It meaningfully clarifies 'geo' (blank removes from every location) but says nothing about 'keywords' format, even though that is the required parameter. Half the parameters are effectively documented.

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 ('Take terms off') and resource ('the watchlist'), which clearly distinguishes it from the sibling watchlist_add. No sibling is named explicitly, but the add/remove pair is unambiguous from the name and description.

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 description explains what removal does but gives no guidance on when to use this versus watchlist_add or watchlist_report, and no prerequisites or state conditions are mentioned. Usage is only implied by the verb.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true, and the description resolves the non-obvious part of that profile by stating 'Every run stores a reading per term' and that it measures 'two requests each'. This explains the persistence side effect behind readOnlyHint=false and the external calls behind openWorldHint, adding real value beyond the annotations. It does not describe failure modes or rate limits, keeping it short of a 5.

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 core purpose is front-loaded in the first sentence, followed by the persistence note and the pagination mechanics, with no filler. Three short sentences and a parenthetical keep it tight, though the 'was stable, now rising' illustration is slightly decorative rather than load-bearing.

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-value detail is appropriately omitted. The description covers the report's content, the side effect, and pagination, which is what an agent needs to call it. The only real gap is the undocumented geo parameter for this openWorld tool.

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%, so the description must carry the parameter burden, and it explains limit ('terms per call') and offset ('to continue') with a clear pagination model. However, the geo parameter is never mentioned, so a third of the parameters remain undocumented in both schema and description.

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 gives a specific verb and resource: it reports the watchlist's measured direction, change since last report, and trending status per term. That clearly distinguishes it from siblings like watchlist_add, watchlist_remove, and trending_now. It stops short of naming an alternative for overlapping use cases, so it is clear but not fully differentiated.

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?

Usage is implied rather than stated: you run it to get a watchlist report, and the pagination sentence ('limit terms per call, offset to continue') gives a partial workflow. There is no explicit when-to-use guidance, no exclusions, and no pointer to an alternative tool for a similar need.

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