News Volume API

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses the cost model (1 request per data type, boards 1 request per 10 rows), that only answering data types are charged, that the response reports requests_charged, and that a plan-limit message comes back on rate limit or quota exhaustion. That is meaningful operational context annotations cannot express. It stops short of describing ordering, freshness windows, or empty-result behavior, which keeps 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 most discriminating information — what it returns and how it differs from the measure siblings — is front-loaded, and the cost/failure sentences are load-bearing rather than filler. It is dense and runs long as a single block, which slightly hurts scanability, but no sentence is expendable.

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 multi-source, cost-accruing read tool with no output schema, it covers return contents, per-source engagement fields, cost accounting, the charged-only-for-answering rule, and the rate-limit/quota failure mode. An agent has everything needed to call it correctly and predict the billing consequence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds value by tying cost to specific parameter choices ('all' costing 10, boards per 10 rows) and by clarifying that hashtag mode applies only to TikTok and Instagram while other sources fall back to keyword search. The remaining parameters (days, limit, comments) get no extra meaning beyond the 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?

The description opens with a concrete verb+resource statement ('What people are posting, reading and betting about a keyword right now') and enumerates the returned artifacts (posts, videos, news stories, discussions, prediction markets) plus the hashtag mode. It explicitly distinguishes itself from the sibling measure tools, so an agent can separate it from get_time_series and get_growth without reading schemas.

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 states the use case ('explain why something is trending or what the conversation says') and names the alternatives with the condition that selects them ('get_time_series and get_growth measure how much'). The hashtag=true branch is also framed as a distinct mode of use, so when-to-use and when-not-to-use are both covered.

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 only declare it as a safe, read-only, idempotent read. The description adds real behavioral context: request cost accounting, that only answering data types are charged, that the response echoes requests_charged, and that a plan-limit message is returned on rate limit or quota exhaustion. Minor gap: nothing on error shape for invalid keyword formats, but the cost/quota disclosure is the material information.

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 purpose and output scale, which is good, but the cost sentences mention 'boards' and per-10-row board pricing even though this tool's schema accepts no board parameter — that invites confusion with get_top_trends. The quota/rate-limit sentence is useful but the pricing paragraph could be trimmed to sources only.

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 parameters, no output schema, and full schema coverage, the description does the right supplementary work: it explains the returned scale, absolute volume, the requests_charged field, and quota failure behavior. Only the stray board-pricing detail and the absent invalid-input behavior keep it short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description restates the preset-window requirement for percent_growth and the 0-100 output scale, but adds no formatting or default guidance beyond what the per-parameter descriptions already spell out (including the full preset list, source formats, and bundle-ID rules).

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: 'Point-to-point growth for a keyword on one or more sources.' It also explicitly separates itself from get_time_series ('for charting or custom math') and from get_top_trends (App Downloads vs. live boards), so an agent can pick it without opening sibling schemas.

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 an explicit when-to-use rule ('Designed for growth questions') plus the alternative and the condition that selects it ('for charting or custom math, get_time_series provides the full series'). It also warns that App Downloads/App Rankings are keyword sources, not the boards on get_top_trends, which heads off a likely misroute.

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?

With no annotations supplied, the description carries the full burden and does so: it discloses the billing model, that only data types that answer are charged, that the response reports requests_charged, and that a plan-limit message is returned on rate limiting or quota exhaustion. These are exactly the operational traits an agent needs and none are recoverable from the 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 payoff (what the customer says) before the return shape, then cost, then failure modes — a sensible ordering. It is dense but nearly every clause carries information; the cost sentence is slightly compressed ('boards cost 1 request per 10 rows') given boards are not a parameter in this schema, which adds a small amount of noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe return values, and it does so field by field (listing, rating, review count, review text, company reply, average stars, star counts, share negative, share replied). Combined with the cost and rate-limit disclosure, an agent has everything needed to call this correctly and interpret the result.

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 100%, so every parameter is already documented, and the description adds little parameter-level detail beyond restating that results are per source and reviews are newest-first. The one useful addition is the warning to verify the matched listing is the intended subject, which is a semantic caveat rather than parameter syntax. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete verb-and-resource framing ('What customers say about a brand, app, product or place') and then enumerates exactly what comes back per source: matched listing, all-time rating, review count, newest reviews with stars/text/reply, and an aggregate summary. This is specific enough that an agent can distinguish it from get_context without inspecting either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes usage: 'Use it for brand sentiment and complaints; get_context covers social posts' names the sibling and the condition that selects it. It also states the cost model up front (1 request per data type, boards 1 per 10 rows) so the agent can weigh a call before making 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, non-destructive and openWorld, so the safety profile is covered; the description adds the cost model the annotations cannot express — 1 request per data type, boards at 1 request per 10 rows, charges only for data types that answer, and requests_charged in the answer. It also discloses failure behavior: a plan-limit message when rate limited or the monthly quota is exhausted.

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 front-loaded sentences, each carrying distinct information: purpose and return shape first, then sibling routing, then cost accounting, then the quota-failure message. Nothing is restated from the schema and no sentence is 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?

With no output schema, the description still tells the agent what comes back (0-100 series, optional volume, requests_charged) and what a limit-hit response looks like, which is adequate for a read-only series tool. It stops short of describing series granularity/row shape or pagination, a minor gap given the rich input 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 100%, so per-source keyword formats, country/language/resolution restrictions and the 'all' option are already fully documented in the schema. The description adds only the aggregate cost implication of multi-source calls, which is billing context rather than deeper parameter meaning; baseline 3 applies.

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 ('Full historical series for one keyword on one or more sources') and immediately characterizes the output shape (0-100 values, plus volume). It also names the two sibling tools it is not, so an agent can distinguish it from get_top_trends and get_growth without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit fit statement ('Suited for charting or custom math') and routes alternatives: live boards go to get_top_trends, and 'get_growth answers most growth questions with less data' steers agents toward the cheaper tool. That is a clear when-to-use and when-not-to-use rule set rather than implied usage.

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 operation, and the description goes well beyond that by disclosing the billing model (1 request per data type, 1 per 10 rows), that only answering data types are charged, and that rate-limit/quota exhaustion returns a plan-limit message. The only gap is that it never hints at response shape beyond 'the answer says requests_charged'.

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 purpose, then scoping, then cost mechanics, so an agent can stop reading early. It is long and repeats the board list already present in the schema's type and category descriptions, which costs it a point, but there is no filler sentence.

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 seven-parameter aggregation tool with no output schema, the description covers what boards exist, how billing accrues, what happens on an uncollected board, and how quota errors surface. Nothing an agent needs to invoke it correctly is missing, and return values are not required since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning the schema only partially conveys: category is mandatory for an enumerated set of boards, window applies only when sort='rank_change', and country applies to a specific subset of types. The request-cost relationship between limit and board count is reinforced 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?

The opening sentence gives a specific resource (live top-trending boards) and scope (one feed type, several, or 'all'; no keyword), which immediately separates it from the keyword-based siblings. It further enumerates the concrete boards covered, so an agent knows exactly what is retrievable here.

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 explicitly routes the agent to alternatives: historical app data goes through get_growth or get_time_series with specific sources, and 'Live boards are only available here, not via get_time_series' draws the boundary in both directions. The rank_change/window pairing and the live-fetch fallback for uncovered boards are also stated as usage conditions.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavioral context not in the annotations: 'Free: does not use a request,' which matters for quota-awareness. It stops short of describing return format/pagination but no output schema exists.

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 sentences, zero waste, with the return contents front-loaded ahead of the invocation guidance. Nothing extraneous.

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 zero params and no output schema, the description fully covers what the tool does and what it returns (plan, used, left, reset time) plus the cost note. An agent has everything needed 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?

The tool takes zero parameters, so the baseline is 4. The schema is empty and there is nothing for the description to compensate for; no confusion is possible.

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?

Names a specific verb ('Shows') and enumerates the exact resource fields returned: plan, requests used, remaining, and reset time. An agent can clearly distinguish this diagnostic tool from the analytics siblings (get_growth, get_time_series, get_top_posts, get_top_trends).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions: 'when the user asks about their limit' and 'after a limit error.' Clear invocation context. It doesn't name when-not-to-use or an alternative, but the siblings are unrelated analytics tools so an exclusion is less necessary.

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