SiteCheck Web Intel

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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely useful context beyond that: the feed is public with no key, each successful call costs $0.002 in USDC via x402, and failed calls are not charged. That is exactly the kind of cost/auth disclosure an agent needs, though nothing is said about rate limits or result ordering beyond 'latest'.

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?

Everything is packed into a few front-loaded fragments: what it is, the filter scope, the recency constraint, then auth and price. The telegraphic style ('Latest items only.') is efficient, though the pricing sentence is dense enough to slow parsing slightly.

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 only two optional params, full schema coverage, an output schema, and safety annotations, the remaining burden is cost/auth and scope, both of which the description covers. It stops short of describing pagination or result freshness windows, but nothing needed 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 coverage is 100%, so the schema already documents q and limit, making 3 the baseline. The description's claim that the keyword filter spans title/summary/categories slightly conflicts with the schema's 'title or summary' wording, and it adds no syntax or format detail beyond that.

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 the specific resource (Al Jazeera articles), the source (public RSS feed), and the matching behavior (keyword filter on title/summary/categories), so an agent knows exactly what it retrieves. Sibling differentiation is implicitly handled by the publisher-specific name, but the description never explicitly contrasts itself with alternatives like search_google_news.

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 phrases 'Latest items only' and 'keyword filter' imply the use case (recent Al Jazeera coverage matching keywords), but there is no explicit guidance on when to pick this over a sibling such as search_ap_news_articles or search_news_across_the_web, nor any stated exclusion beyond recency.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it explains the data path (Google News public RSS index because apnews.com blocks automated clients), warns that links are Google News redirects rather than direct apnews.com URLs, limits scope to headlines with no article text, and discloses cost ($0.002 USDC per successful call, x402 on Base/Solana/Arc) with the key detail that failed calls are not charged. That pricing and link-format disclosure is exactly the context an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense but well-ordered passage that leads with what the tool returns, then source mechanics, then link caveats, then price. Every clause carries non-redundant information — nothing is repeated from the schema or annotations.

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?

All three parameters are optional with zero required inputs, and the description makes clear the tool works with no arguments (defaults apply). An output schema exists so return structure need not be described, and the payment model, link format, and content limits are all 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 description coverage is 100%, so the schema already documents q, days, and limit with ranges and defaults. The description reinforces the semantics ('optionally matching search words', 'from the last 1-30 days', 'newest first') but adds no syntax, format, or edge-case guidance beyond what the schema already carries, so the 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+resource pair plus the exact returned fields (headline, publisher, publish time, link), ordering (newest first), and scope (last 1-30 days). An agent can distinguish this from siblings like search_google_news or search_reuters_articles purely from the text, since it names AP News as the source site.

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?

Clear context is given for when this is appropriate: latest AP headlines from a bounded 1-30 day window, with an optional keyword filter. The line 'Headlines only, no article text' implicitly steers an agent toward a full-text extractor when body content is needed, but no sibling alternative is named explicitly and there are no stated 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the cost model ($0.002 USDC per successful call via x402 on Base, Solana, or Arc), that failed calls are free, paywall limitations, and a technical dependency on <article>/<main> markup. These are material operational details an agent needs before invoking a paid external fetch.

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 dense with useful information: first defines scope and output, second states read/paywall constraints, third covers pricing and billing edge cases. No sentence is redundant, and the core purpose is front-loaded.

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 output schema exists (so return fields need not be described in depth) and annotations cover safety, the description fills in the remaining critical gaps: cost, failure billing, paywall behavior, and extraction dependency on semantic HTML. An agent has enough to call this correctly and understand the transactional risk.

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%, with both url and maxChars fully documented in the input schema, including the default (8000) and range (500–40000). The description does not add syntax or format detail beyond what the schema already provides, so the baseline of 3 is correct.

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 precise verb and resource: 'Extracts one article from a public news or blog page,' and enumerates exactly which fields are returned (headline, author, times, description, Markdown body). It also distinguishes itself from the many 'search_*_articles' siblings by clarifying 'Reads the page you name only,' so an agent can tell it is an extractor, not a search 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?

Usage conditions are clear: it works on a single named public article page, paywalled text is excluded, and body extraction depends on <article> or <main>. However, it does not explicitly name sibling alternatives (e.g., 'use search_bbc_news_articles to find articles first'), leaving the broader tool-selection context 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?

Beyond the readOnly/openWorld annotations, the description discloses that the feed is public with no key, that only headlines and summaries are returned, and that pricing is $0.002 USDC per successful call via x402 with no charge for failed calls. This is exactly the kind of auth, cost, and failure-billing context an agent needs.

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: source and content scope come first, followed by the full-text limitation, access/pricing details. Every element earns its place 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?

With only two optional parameters, full schema coverage, an output schema, and clarifying annotations, the description supplies everything else an agent needs: source scope, content limitations, authentication requirements, and billing behavior on success versus failure.

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 mentions keyword filtering on title/summary and 'latest items,' but it does not add syntax, matching behavior, or format details beyond what the schema already documents for q and limit.

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 source (BBC News RSS feed), scope (top stories, latest items, headlines and summaries only), and filtering behavior (keyword filter on title/summary). It clearly distinguishes itself from full-text article tools, though it does not explicitly name a sibling news search tool as 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?

The description implies usage for BBC headline/summary retrieval and signals a limitation with 'no full article text,' but it does not explicitly say when to choose this over the many sibling news search tools or name an alternative for full-text needs.

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 supply readOnlyHint/openWorldHint, but the description adds substantial behavioral context: 10 posts per page newest-first, the q filter applies only within the current page, post bodies are excluded, no API key needed, and x402 pricing ($0.002/successful call, failures not charged). These are non-obvious traits an agent needs before invoking.

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?

Opens with the resource and data returned, then tacks on access/pricing details, so key information is front-loaded. It's a dense single run-on sentence, which is slightly hard to parse but nearly every clause 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?

Given an output schema already defines the return shape, the description still covers identification, pagination, filtering scope, access requirements, and cost—everything an agent needs to call it correctly. Nothing material 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 coverage is 100%, so all three parameters are already documented in the schema, including the page-only scope of q. The description largely restates these constraints rather than adding syntax or format detail beyond the schema, so the 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 resource (a beehiiv newsletter's post archive) and enumerates exactly what it returns: name, total posts, per-post title/subtitle/URL/publish time/authors/tags/reading time. This unambiguously separates it from the many other search_* verticals, which all target different sources.

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 identifying key (beehiiv subdomain like superhuman, or the newsletter's own domain) and the page-based paging model, giving clear context for when this tool applies. It doesn't name exclusions or alternatives, but the sibling set is orthogonal source-specific searches, so this is a minor gap.

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?

Goes well beyond the annotations: discloses that results are newest first, capped at 100, offer no paging into older news and no full article text, require no key, cost $0.002 USDC per successful call via x402, and that failed calls are free. These are material behavioral and cost details an agent needs before invoking a paid, open-world search.

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 resource and returned fields, then follows with filtering, limitations, and pricing. Every sentence carries useful information, though the single dense paragraph could be more scannable with minor formatting.

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 the presence of an output schema and full input-schema coverage, the description supplies the remaining critical context: source scope, supported filters, coverage limits, auth model, and pricing. An agent has enough information to call the tool 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 100%, so the baseline is 3. The description reinforces parameter meaning ('filter by stock tickers and/or words in the headline/teaser') and gives an example (AAPL,TSLA), but adds no syntax or constraint detail beyond what the schema already documents.

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 (Benzinga financial news, the public JSON feed behind benzinga.com) and lists the returned fields, so an agent can distinguish it from other news-source siblings by name. However, it never explicitly names an alternative or states the source as the selection criterion, leaving sibling differentiation 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?

The description implies usage through the source name ('Benzinga financial news') and mentions filtering by tickers or headline/teaser words, but provides no explicit when-to-use/when-not-to-use guidance or alternative tools. An agent must infer that this is the right tool specifically for Benzinga-sourced financial news.

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?

Beyond the readOnly and openWorld annotations, it adds meaningful behavior: no API key, only the first page, no paging, no ad or SERP-feature data, paid per successful call, and failed calls not charged. It still does not cover rate limits or latency expectations.

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: provider, result fields, ordering, limitations, and pricing are all stated without filler. Every sentence 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?

With an output schema present and annotations covering safety, the description provides enough operational context: scope, no paging, and payment behavior. The main remaining gap is explicit routing guidance versus sibling search tools.

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 q and limit parameters are already documented. The description reinforces the one-page limitation but does not add significant meaning to the query or limit parameters 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 clearly states a specific provider and resource: Bing web search results with title, URL, and snippet. It is distinguishably a web search tool, though it does not explicitly contrast itself with sibling search tools such as search_google_search.

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 by the provider and output format. The description does not say when to choose Bing over another search tool, nor does it name alternatives or 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?

Goes well beyond the annotations (readOnlyHint/openWorldHint) by disclosing authentication requirements (none), cost model ($0.002 USDC per successful call via x402 on Base, Solana or Arc) and the failure-charging rule (failed calls are not charged). These are behaviors an agent cannot infer from any structured field and directly affect whether/how it should invoke the 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?

Two sentences, front-loaded with what the tool returns, then the operational caveats. Pricing and payment details are compressed into a single clause with no filler, and every sentence carries information the agent needs.

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; what remains (source, scope, auth, cost, failure semantics) is fully covered. For a one-parameter public data lookup this leaves nothing an agent would need unanswered before calling.

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

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

Schema coverage is 100%, and the schema itself documents the symbol format, so the baseline is 3. The description adds only an example value ('BTC-USDT') that largely restates the schema's own example; no extra constraint (case sensitivity, fallback when omitted despite the param being optional) is supplied.

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 ('BingX perpetual swap market ticker') and enumerates exactly which fields are returned (last price, 24h change, high, low, open, base/quote volume, last candle close). The scope is pinned to 'one symbol such as BTC-USDT' and 'no trading', making it unambiguous even though no sibling covers the same data.

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?

Clearly frames the context: read-only market data, public open API with no key, one symbol per call, and explicitly excludes trading. It does not name an alternative or state when a different tool would be preferred, but there is no sibling offering equivalent ticker data, so the practical gap is small.

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 and openWorldHint, so safety is covered. The description adds genuinely useful facts beyond them — Google News RSS as the data path, redirect-style links, no article body, and per-call pricing with charge-on-success semantics — but those details carry a lower behavioral weight than, say, auth or rate-limit facts, so this is solidly above baseline rather than exceptional.

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 front-loads the resource and returned fields, then layers provenance, limitations and pricing in a compact block. The sentences are dense and semi-colon chained, which slightly hurts scannability, 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?

Source provenance, link behavior, content boundary (headlines only), date window, cost model and failure-charge policy are all present, and an output schema exists to cover return structure. An agent has everything needed to decide and invoke correctly.

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

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

Schema coverage is 100%, so the schema already documents q, days and limit with examples and defaults. The description only repeats the 1-30 day range and the optional keyword idea, adding no syntax or constraint detail the schema lacks; 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?

The description names a specific resource (Bleacher Report articles), the fields returned (headline, publisher, publish time, link), ordering (newest first), and scope (last 1-30 days). It is immediately distinguishable from siblings like search_google_news or search_article_extractor by its single-site focus.

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 tool is for site-scoped article headline retrieval with optional keyword matching, and implicitly routes full-text needs elsewhere via 'Headlines only, no article text'. It doesn't explicitly name an alternative tool (e.g. search_article_extractor) or exclusion conditions, so it falls short of 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 only cover readOnly and openWorld; the description adds real operational context an agent could not otherwise know: no API key needed, pay-per-call at $0.002 USDC via x402 across Base/Solana/Arc, and failed calls are free — that is material for deciding whether to call. It stops short of ordering, rate limits, or what happens on an empty keyword match, so it is not exhaustive.

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 with zero filler: source and scope first, freshness constraint second, payment/auth last. Nothing is repeated from the schema at length and every sentence carries information the agent needs.

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 read-only feed with an output schema and full schema coverage, the description covers what the tool returns, its freshness limit, auth requirements, and cost model. Minor gaps remain around result ordering and behavior when the keyword matches nothing, but nothing essential 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 100%, so the schema already defines both q (all words must appear, max 200 chars) and limit (1–30, default 10). The description restates the title/summary matching for q but adds nothing about limit or result-count behavior, so it sits at the baseline.

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), a specific resource (CNBC top news) and the exact source (CNBC's public RSS feed) with a note that filtering applies to title/summary. The publisher is named explicitly, which is the only thing that separates it from the dozens of sibling search_*_articles tools, so an agent can route to it without opening the 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?

"Latest items only" implies a freshness constraint and the keyword behavior implies when it is appropriate, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as search_google_news or the other publisher feeds. The agent must infer that this is the CNBC-specific choice rather than a general news search.

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 value beyond the readOnlyHint/openWorldHint annotations: unknown packages yield 404, and each successful call costs $0.002 USDC via x402 (Base, Solana, Arc) with failures uncharged. That cost and error-profile disclosure is exactly what an agent needs before calling. It stops short of mentioning rate limits or result size, so not 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?

Two dense sentences, front-loaded with the source and field list, then error and pricing behavior. The field enumeration is partly redundant given an output schema exists, which is minor waste but not harmful.

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 single-parameter, read-only lookup with an output schema, the description covers source, coverage, error behavior, and payment model. The redundant field list and lack of keyword-search caveats are small gaps rather than blockers.

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

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

Schema coverage is 100% and the schema already documents 'name' as an exact CRAN package name with an example (ggplot2). The description adds no format guidance beyond that, so the 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 resource (CRAN R package metadata via the crandb JSON mirror) and enumerates the returned fields, so an agent knows exactly what data it gets. It doesn't differentiate itself from adjacent metadata sources like search_crossref or search_pubmed_article_metadata, and the name says 'search' while the behavior is an exact-name lookup.

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 notes the source is public and keyless, which is useful context, but never says when to pick this tool over a sibling metadata source or what its limits are (exact match only, no keyword search). No explicit when/when-not guidance is given.

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 and openWorldHint, so the description's value-add is the commercial model: $0.002 USDC per successful call via x402 across Base/Solana/Arc, with failed calls not charged. That is genuinely useful pre-call context an agent cannot infer from schema or annotations. It stops short of noting rate limits or result-ordering/relevance 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?

Three tight sentences: capability first, limitation second, cost third. Every sentence carries information, with no filler. The field list is slightly dense but front-loads what matters most.

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 structure need not be explained, and the pricing/auth model is disclosed. The main missing piece is sibling routing against search_crossref_academic_paper; otherwise an agent has what it needs to call this 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 100% for both parameters (q with a 1-200 char bound, rows with a 1-20 bound and default 5), so the schema does the heavy lifting. The description adds nothing about query syntax, field scoping, or sorting, so baseline 3 is warranted.

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 (Crossref works search) and enumerates the record fields returned (DOI, title, type, container, year, authors, link), so an agent knows exactly what comes back. However, it never distinguishes itself from the near-identical sibling search_crossref_academic_paper, which is a real ambiguity in this sibling set.

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: 'Metadata only; abstracts are not always present' warns what not to rely on, and 'no key' signals low-friction access. There is no explicit when-to-use or when-to-prefer-an-alternative statement, which matters given the overlapping Crossref sibling and the many other scholarly search tools (PubMed, DataCite, Europe PMC, Unpaywall).

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?

Goes well beyond the readOnly/openWorld annotations: it discloses that the source is a public REST API with no key, that unknown DOIs produce 404, that each successful call costs $0.002 in USDC via x402 on Base/Solana/Arc, and that failed calls are free. The only omission is latency/rate-limit behavior for a paid 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?

Three dense clauses front-load the resource and return shape, then error semantics, then price. Every sentence carries information, though packing the pricing/payment rail detail into the same breath as the data fields makes it slightly dense to scan.

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 single-parameter read with annotations and an output schema present, the definition covers what an agent needs: the data returned, the failure mode, and the cost. A brief pointer to search_crossref as the alternative would close the only 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?

With a single required parameter at 100% schema description coverage (including a DOI example), the baseline is 4. The description correctly frames the parameter as identifying exactly one paper rather than adding redundant format detail already present in 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?

States a specific verb and resource ('Crossref DOI lookup') and scopes it to 'one paper', which differentiates it from a bulk/list search. It does not name the near-identical sibling search_crossref, so the agent must infer which to call from position alone.

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 implicit trigger (you already have a DOI) is clear from 'DOI lookup ... for one paper', and the 404 behavior on unknown DOIs is stated. However, there is no explicit when-not guidance and no mention of the obvious alternative (search_crossref), leaving the sibling choice ambiguous.

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 readOnly and openWorld; the description adds substantive context the agent cannot get elsewhere: it is a public page requiring no key, costs $0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls are free, and missing values come back as null.

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 single dense but well-ordered block: resource and scope first, then field list, then filtering, then data semantics, then pricing. Nothing is redundant, though the run-on structure makes the key facts slightly harder to scan.

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 and 100% parameter documentation, the description need only carry cost, access and data-quality semantics, which it does. The only gap is sibling differentiation, which matters here given the crowded rankings/news namespace.

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 all three parameters and their defaults are already documented in structured form. The description adds value at the result level (USD values, null semantics) but contributes little parameter-specific meaning beyond what the schema states.

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/retrieve rankings) plus resource (DappRadar's top-50 dapp rankings) and enumerates the returned fields, so an agent can distinguish it from the many news/academic/ranking siblings instantly.

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 context is implied (a public, paid rankings lookup), and chain filtering is described, but there is no explicit 'use this instead of X' routing or statement of when not to use it. The agent has to infer that this is the dapp-metrics source rather than a general crypto search.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the payment model: $0.002 USDC per successful call via x402 on Base, Solana, or Arc, with failed calls not charged. That is exactly the kind of cost/auth context an agent needs before invoking a paid tool. It stops short of a 5 because rate limits, result ordering, and pagination behavior are unmentioned.

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 resource and returned fields, then the API/key status, then pricing in a single trailing sentence. Every sentence carries information, though the payment clause is dense enough to be slightly harder to parse than the rest.

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 needn't explain return values, and it correctly focuses on scope and billing. For a paid read-only search tool the essentials are covered; only pagination/ordering behavior beyond the 25-record limit is left unstated.

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%: 'q' (1-200 chars) and 'limit' (1-25, default 5) are both fully documented in the input schema. The description adds no query syntax, matching behavior, or interpretation hints beyond that, so the 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+resource (DataCite DOI search) and enumerates the returned fields (DOI, title, publication year, resource type, publisher, creators, landing page) plus the covered output types (datasets, software, research outputs). It does not differentiate itself from adjacent siblings like search_crossref, search_unpaywall, or search_figshare_articles, which is the only thing keeping it from 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?

'Metadata only' implies a scope boundary (no full-text or file access) and 'public REST API, no key' signals readiness to call. But there is no explicit guidance on when to prefer this over search_crossref or search_figshare_articles, and no stated exclusions, so usage must be inferred from the field list.

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 read-only and open-world nature; the description adds genuinely non-obvious behavior: recency is capped to latest items, excerpts are truncated to feed content, no API key is required, and each successful call costs $0.002 via x402 while failed calls are free. That cost/failure model is material for an agent deciding to invoke it. It does not disclose result-count behavior or ordering beyond what the schema says.

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 source and mechanism, then constraints, then pricing — each clause carries information. It is dense but not padded; a slightly clearer separation of scope vs. billing would improve scanning.

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-optional-parameter feed search with full schema coverage, an output schema, and annotations, the description covers source, freshness, truncation of content, auth, and cost. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so both parameters are already documented, establishing a baseline of 3. The description adds a little filter context ('title/summary/tags') but that actually conflicts slightly with the schema's 'title or summary', and the limit range (1–30, default 10) is left entirely to 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?

Names a specific source (Defector) and resource (articles) and states where they come from — the public RSS feed — plus what the query filters on. An agent can distinguish it from the dozens of other search_*_articles siblings by source alone, though it never explicitly contrasts itself with 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?

'Latest items only' and 'keyword filter on title/summary/tags' imply the intended use (recent-defector-content lookups with an optional keyword), but there is no explicit when-to-use or when-to-prefer-another-source guidance. With ~60 sibling news/article search tools, a routing hint would have been valuable.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses no key is needed, the exact price ($0.002 USDC per successful call via x402, listing supported chains), and that failed calls are not charged. Cost and payment mechanics are behavioral facts the schema cannot express and are critical before invocation.

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 dense sentences: capability and returned fields first, then the search-mode limitation and the pricing model. No filler, and the constraint that most affects invocation appears before the cost note.

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, yet the description's field list still helps an agent judge relevance quickly; combined with the auth-free/payment disclosure and the tag-only constraint, nothing needed to call this 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 coverage is 100%, so the baseline is 3; the description adds the meaningful constraint that exactly one tag is accepted and that free-text queries are impossible, which shapes how `tag` must be filled. The `limit` bound remains schema-only, but that is adequately documented there.

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 (latest dev.to articles for one tag) and enumerates the returned fields, so an agent can distinguish it from the many other `search_*_articles` siblings without opening the schema. The scope limit — tag-only, no free-text — is stated up front.

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 says the public API supports tag search only and has no free-text search, which prevents a common misuse (passing a query string). It does not name an alternative sibling for keyword-based article search, so the routing guidance is clear but not complete.

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 and openWorldHint, and the description adds genuinely useful context beyond them: no API key required, a per-call price of $0.002 USDC and the x402 payment rails, and the important limitation that only the latest items are covered (no historical archive), with failed calls not 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?

Source and scope are front-loaded, followed by freshness and cost/auth details in a compact block with no filler. The billing clause is dense but each element (price, rails, failure policy) carries real decision value.

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 needn't be explained, and the description covers source, freshness, auth, and cost. Remaining minor gaps (pagination beyond the 30-item cap, result ordering beyond 'latest') are handled by the schema or are inconsequential for a feed lookup.

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 schema already documents both q and limit fully. The description only restates that filtering applies to title/summary and adds no matching syntax, multi-word logic, or limit guidance beyond the schema, so 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?

Names a specific verb and resource (US DOJ press releases from the justice.gov RSS feed) plus the filtering mechanism (keyword on title/summary) and recency scope ('latest items only'). This clearly separates it from the many sibling press-release tools (pr_newswire, prnewswire_press_releases, press_release_multi_wire) by source.

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?

'Latest items only' and the keyword-on-title/summary note imply when the tool applies, but the description never explicitly routes the agent to alternatives such as search_press_release_multi_wire or search_prnewswire_press_releases for broader wire coverage, nor states 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?

Goes well beyond the readOnly/openWorld annotations: discloses that results are headlines only with no article text, that links are Google News redirect links rather than canonical drive.com.au URLs, the data provenance, and the exact pay-per-call cost model including that failed calls are not charged. These are material facts an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the payload (what is returned, ordering) before provenance, limitations, and pricing, so an agent can stop reading early. It is a dense run-on block and pricing could be one clause shorter, but every sentence carries decision-relevant 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?

Annotations cover the safety profile, an output schema exists so return shapes needn't be narrated, and the description fills the remaining gaps: paywall/cost, headlines-only limitation, redirect-link behavior, and the reason for the proxy source. Nothing an agent needs to call 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 coverage is 100%, so the schema already documents q, days (1-30, default 7) and limit (1-100, default 20). The description restates the date window and the optional keyword matching but adds no syntax, format, or edge-case detail beyond that. 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 (search/retrieve) plus a precisely scoped resource (Drive.com.au articles via Google News RSS), and enumerates the returned fields with ordering ('newest first'). It is clearly distinguishable from the broad sibling search_google_news and from other publisher-specific siblings like search_reuters_articles.

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 optional 'q' overlap and the 1-30 day window, and it explains why this route is used ('the site blocks automated clients'). However, it never names an alternative tool or states when a caller should pick search_google_news or a different publisher search instead.

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 and open-world, but the description adds substantial behavior beyond them: a per-call price ($0.002 USDC via x402), the billing rule that failed calls are free, the partial-enrichment cap (only the first 5 matches get summary/author/last-reviewed/paywall), and the login-driven content limitation. These are exactly the facts an agent needs before spending money or expecting richer payloads.

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, then the details toggle, the scope ceiling, and finally pricing — a sensible order with no filler. The pricing sentence is long but every clause (currency, networks, failure policy) carries decision-relevant 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, the description need not explain return values, and it doesn't. It still covers the pieces the schema cannot: indexing source, the metadata-only ceiling, partial enrichment on details, and the payment model — everything needed to call this correctly and knowingly.

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 parameters are already fully documented, giving a baseline of 3. The description merely restates the title-word filter and the 'first 5' behavior of details without adding format, syntax, or matching semantics 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?

States a specific verb and resource ('Medscape eMedicine clinical articles by specialty') plus the exact fields returned (title, topic category, article id, URL) and the filter mechanism (words in the title). Against a fleet of sibling search_*_articles tools, this distinguishes itself by source, domain (clinical specialty index) and by explicitly capping scope to metadata.

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?

Clear usage context: specialty is the entry point and q narrows by title words, and the 'Metadata only, no article text (Medscape articles need a free login)' clause tells the agent when this is not the right tool for full text. It does not, however, name an alternative sibling (e.g. search_pubmed_article_metadata) or state when to prefer another source, so it stops short of explicit routing.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the API is public with no key, that results include specific metadata fields, that abstracts are excluded, that each successful call costs $0.002 in USDC via x402 on multiple chains, and that failed calls are free. These are material operational and cost details an agent needs before invoking a paid 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 description is dense but front-loaded with the core purpose and then layers in coverage, omissions, return fields, and pricing. Every clause carries useful information, though the run-on structure could be slightly more scannable.

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 search tool with readOnly/openWorld annotations and an output schema, the description covers the remaining essential context: source type, coverage limits, no key requirement, and payment model. 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 100%, so the schema already explains both q and limit fully. The description adds no syntax, formatting, or edge-case guidance for the parameters beyond what is already in the schema, which is the baseline expectation.

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 uses a specific verb ('search') and resource ('Europe PMC literature'), and it clarifies scope by naming the content covered (life-science papers, preprints) and excluded (abstracts). An agent can distinguish this from sibling literature-search tools by its Europe PMC-specific indexing and return fields.

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 implies usage through coverage details ('life-science papers including preprints; abstracts are not included'), which helps an agent decide when this source is appropriate. However, it names no alternatives and gives no explicit when-to-use/when-not-to-use guidance against the many sibling search tools such as search_pubmed_article_metadata, search_crossref, or search_unpaywall.

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 and openWorldHint, and the description adds substantive context beyond them: the API needs no key yet costs $0.002 USDC per successful call via x402 (Base, Solana or Arc), and failed calls are not charged. That billing/auth detail is exactly the kind of behavior an agent must know before invoking. It stops short of describing pagination or response behavior, but an 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?

It is front-loaded with the data payload, then the default-date behavior, the men's-only scope, and finally the pricing constraint — each sentence carries information. It is dense for three sentences but nothing is pure filler; the parenthetical about a keyless public API could be trimmed as it is partly implied by the pricing note.

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-optional-parameter, read-only lookup with an output schema, the description covers the essentials an agent needs: dataset scope, date selection, and the paid-call model. The only remaining gaps (limit semantics, result ordering, pagination) are either handled by the schema or unnecessary given 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?

With 100% schema coverage the baseline is 3, and the description earns above that by explaining what a dateId actually represents (a ranking date listed on FIFA's site) and confirming the default is the latest date at build time. The 'limit' parameter is left entirely to the schema, so it isn't a full 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 names a specific verb and resource ('FIFA men's national team world ranking') and enumerates the returned fields (position, team, country code, points, previous rank), so an agent can tell it apart from the other ranking siblings (owgr golf, world rugby, Leiden, etc.) at a glance. 'Men's ranking only' further narrows the scope against a possible women's dataset.

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 concrete usage context: the default date is the latest listed on FIFA's site, and 'pass dateId to read another listed date' tells the agent exactly how to switch dates. It doesn't name a specific alternative tool for women's rankings or when NOT to call it, so it falls short of an explicit when/when-not/alternative rule.

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?

Goes well beyond the readOnlyHint and openWorldHint annotations by disclosing the access model (public API, no key), the coverage limit (titles and metadata only, no file contents), and a precise billing contract: $0.002 USDC per successful call via x402 on Base/Solana/Arc with failed calls uncharged. That payment/rate context is exactly what an agent needs before calling a paid endpoint.

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 tight sentences with zero filler: scope and returned fields first, then the coverage boundary, then cost. Each sentence carries distinct decision-relevant 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?

Even though an output schema exists, the description still names the returned fields, and it covers the two facts an agent cannot get from structured data: no authentication is needed and calls incur a small per-success charge. Nothing material for correct invocation 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 100%, documenting q (1-200 chars) and limit (1-25, default 5). The description adds only the implication that q matches titles and metadata rather than full text; it gives no syntax, operator, or pagination guidance beyond the schema, so the baseline of 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?

Names a specific verb+resource (Figshare public article search) and enumerates exactly what is returned: id, title, DOI, publication date, item type and page link for articles, datasets and figures. It also draws a clear boundary against full-text tools by stating file contents are not returned, which separates it from sibling search_* academic sources like crossref or datacite.

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?

Provides useful context — public API, no key required — and implicitly frames usage as metadata/title lookup rather than full-text retrieval. However, it never states when to choose this over the many sibling academic search tools (search_crossref, search_datacite_metadata, search_pubmed_article_metadata) or any exclusions, so routing is left to inference.

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

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

Goes well beyond readOnlyHint/openWorldHint: it discloses that no API key is required, that the feed is truncated to the latest few items, and that each successful call costs $0.002 in USDC via x402 with failed calls free. Pricing and truncation are non-obvious behavioral facts an agent must weigh before calling.

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 compact sentences, each carrying distinct payload: source/purpose, filter scope, coverage limitation, auth and pricing. Purpose is front-loaded and nothing is redundant.

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 no explanation, and the annotations cover the safety profile. Coverage limits, auth requirements, cost, and filter semantics are all supplied, leaving no material gap for a two-optional-parameter search 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 100%, so both q and limit are already documented. The description only adds that the keyword filter also covers categories (beyond the schema's title/summary), which is marginal and slightly inconsistent with the schema wording; 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 source (FreightWaves) and a specific mechanism (public RSS feed with keyword filtering), so the agent knows exactly what this returns. It is distinguishable from the many other news siblings by source name, though it never explicitly contrasts itself with them (e.g. search_google_news).

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?

'Feed carries only the latest few items' is an explicit scope limitation that tells the agent when this tool will underperform. It stops short of naming an alternative for historical or deep coverage, so it is clear context rather than full when/when-not routing.

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?

Beyond the readOnly/openWorld annotations, the description discloses that no key is needed, full articles are paywalled and not returned, the exact x402 price per successful call, accepted payment chains, and that failed calls are not charged. These are substantive behavioral details an agent needs before invoking a paid read-only search.

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 four compact sentences, front-loaded with the FT headline purpose, then moves through filtering, content limits, access, and payment. Each sentence carries useful information with no repetition or 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?

Given the output schema, read-only/open-world annotations, and full parameter coverage, the description covers the essential context: source, filtering, content limitations, access model, and cost. Nothing critical is missing 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 100% and the schema already describes q, limit, and section. The description reinforces that keywords filter title/summary and that section accepts homepage or section/topic slugs, but it adds little beyond the schema and does not mention the limit parameter.

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 (Financial Times headlines from public FT RSS feeds) and scope (international homepage or any section/topic stream, with keyword filtering). It also distinguishes this tool from other news-search siblings by naming the FT source and limiting output to headlines/standfirsts.

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 gives clear context that this is for FT headline retrieval, not full articles or general web search, because it mentions the RSS source and paywall limitation. However, it does not explicitly name alternatives or say when to prefer other news search 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 only declare readOnly/openWorld, but the description adds genuinely non-obvious behavior: no API key required, a $0.002 USDC charge per successful call via x402 on Base/Solana/Arc, and that failed calls are not charged. Payment and auth requirements like these are exactly what an agent needs before invoking the 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?

Three compact sentences: what it is and its filter scope first, then the 'latest items only' constraint, then access/cost terms. Nothing is redundant or buried.

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 and the input schema fully documents both parameters, so the description's remaining burden is access, cost, and scope — all covered. An agent can decide and invoke correctly from this.

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 both parameters are already documented; the schema even specifies that all words must appear and the 1-30 range. The description only restates the filter fields, and its mention of 'categories' is slightly broader than the schema's 'title or summary' — marginal added value, so baseline 3.

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 source (gCaptain maritime news) and its retrieval channel (public RSS feed), with a keyword filter scoped to title/summary/categories. That is specific enough to separate it from the many other news-search siblings, though the verb is implied by the tool name rather than stated.

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?

'Latest items only' and the keyword-filter scope imply when the tool fits, but there is no explicit when-to-use or when-to-prefer-an-alternative guidance (e.g., vs. search_google_news or search_news_across_the_web for broader coverage). Usage must be inferred from the niche source.

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?

Goes well past the readOnly/openWorld annotations: discloses the 503 behavior when GDELT is rate-limited or slow, the fallback API, the coverage limitation, and full pricing terms including which payment rails are accepted and that failed calls aren't charged. This is exactly the context an agent needs before spending money on a call.

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 and how, then limitations, then cost — a sensible order. It is dense but nearly every clause carries information; the pricing/payment sentence is the only part that could be trimmed for some audiences.

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 paid, rate-limited, open-world search tool the description covers the gaps that matter: recency, coverage caveats, failure mode, cost and payment. An output schema exists, so listing return fields is supplementary rather than required.

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 schema carries the basics and baseline is 3. The description adds real value by showing GDELT query syntax ("exact phrase", sourcelang:english, domain:bbc.co.uk) for the q parameter, which the schema 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 ('Recent news articles ... that match a query'), scopes it to the last ~72 hours and names the exact upstream source (GDELT Context 2.0 with DOC 2.0 fallback). That scope immediately separates it from sibling news tools like search_google_news or search_bbc_news_articles.

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 72-hour recency window and 'covers the sources GDELT monitors, not every outlet' give clear context for choosing this over other news search siblings. It stops short of naming a specific alternative to use instead, so routing is inferential rather than explicit.

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 real behavioral context beyond the readOnly/openWorld annotations: values are read as published with no verification of operator correctness, and it discloses the paid x402 pricing model including that failed calls are free. It stops short of describing pagination, size limits, or failure modes for non-German/non-Impressum pages.

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, front-loaded with what is read and what is returned, with caveats and pricing trailing. Dense but each clause carries information; the pricing parenthetical is slightly long but relevant to cost-aware agents.

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 single-parameter read-only tool with an output schema, the description covers the resource, the returned fields, the accuracy caveat, and the billing model. Nothing an agent needs in order to decide to call or to interpret charges 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?

Only one parameter and schema coverage is 100%, so the schema already documents the url field fully. The description restates the same constraint ('at the page URL you give') without adding format, validation, or redirect-handling detail 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?

Uses a precise verb ('Reads') with a narrowly defined resource ('the Impressum ... at the page URL you give') and enumerates the exact fields returned (e-mail, phone, postal address, notice text as Markdown). The German-Impressum specificity makes it trivially distinguishable from the generic crawling and news-search siblings.

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

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

The description implies the precondition that the URL must point at an Impressum page, but it names no alternatives and gives no explicit when-not guidance (e.g. versus search_website_content_crawler for general page text). 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-schema behavior: a $0.002 USDC charge per successful call via x402 on Base/Solana/Arc, with failed calls not billed. It does not cover pagination or how the approximate total ad count relates to the limit parameter.

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 data source and the two modes, and the pricing clause is placed last. It is dense with parenthetical field lists that partially duplicate the output schema, which costs a little efficiency but nothing is misleading or wasted on 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?

Output schema exists, so the enumerated return fields are redundant but harmless; the description still supplies the mode selection, optional region filter and payment model an agent needs. The only real gap is no mention of pagination or how limit interacts with the approximate ad count.

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 schema already documents all five parameters and the baseline is 3. The description adds value by mapping parameters to outcomes — name/domain for advertiser search versus advertiserId/domain for ad listing, and region as an optional country narrowing — which the flat schema does not connect.

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 (Google Ads Transparency Center) and enumerates the two distinct modes: advertiser lookup by name/domain and ad listing by advertiserId/domain. An agent can tell exactly what the tool returns, including fields like creative ID, format, shown dates and preview URL.

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 makes the mode split explicit (search advertisers vs. list ads) and notes the region filter is optional, which is enough to pick the right parameter. It never names a competing tool or states when-not-to-use, so an agent must still infer that this is the right choice versus seo_linkedin_ad_library or the general news/search siblings.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations: no API key needed, English/US edition only, results are redirect links rather than article bodies, and it discloses billing ($0.002 USDC per successful call via x402 on Base/Solana/Arc) plus the crucial fact that failed calls are not charged. That is exactly the cost/behavior an agent needs before invoking a paid 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?

Two sentences, front-loaded with purpose and source scope, then a second sentence covering return format and payment. No filler; even the payment details earn their place for a per-call paid tool.

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 read-only search with a full schema and an output schema, the description covers source, language edition, return shape, and pricing/failure semantics. Nothing an agent needs to call 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 100%, so both q and limit are already documented with ranges and a default. The description adds nothing about parameter meaning or syntax, so the 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 (Google News search), the exact source type (public Google News RSS feed, English/US edition), and the fields returned (headline, publisher, publish time, link). That scoping separates it from the many sibling news-source tools such as search_ap_news_articles or search_gdelt_news without needing to name 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?

It makes clear this is a keyless public RSS search over the newest matching stories and that article text is not returned, which implicitly routes full-text needs to an extractor sibling. It does not explicitly name an alternative or state when-not to use it, so it stops short of 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?

Beyond annotations, it discloses important behavior: pricing at $0.002 USDC per successful call, x402 payment on Base/Solana/Arc, and no charge for failed calls. It also clarifies result scope (first page, no ads or SERP features) and lists returned 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 description is front-loaded with the core purpose and remains reasonably concise, but it packs many return fields and billing details into a dense sentence. No sentence is clearly wasted, though the return-field enumeration is somewhat redundant given the output schema.

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 annotations, full schema coverage, and an output schema, the description covers what the agent needs to call the tool: provider, scope, cost, payment mechanics, filters, and result characteristics. It lacks only comparative usage guidance against sibling search tools.

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 schema already documents q, limit, country, and freshness in detail. The description adds only a brief mention of optional country and freshness filters, which does not materially extend parameter semantics.

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 states a specific verb and resource: organic web search results from the Brave Search API. It also distinguishes the provider from Google despite the confusing tool name/title. It does not explicitly differentiate from sibling search tools such as search_bing_search, so it falls 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?

The description implies general web search usage but gives no guidance on when to use this tool instead of search_bing_search, search_google_news, or other sibling search tools. There are no exclusions or alternative-selection 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses sorting behavior, the 404 failure mode for unknown symbols, data version (v8), and a full pricing model ($0.002 per successful call via x402 on Base/Solana/Arc, failed calls not charged). This is exactly the context an agent needs before invoking a paid, open-world call.

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 dense sentences with the core behavior front-loaded and pricing/payment trailing. Every clause carries substantive information; no filler, though the payment details run long in a single clause.

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 and readOnly/openWorld annotations covering the safety profile, the description fills the remaining gaps: payment model, error behavior, data version, and sort order. Nothing essential to invoking 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 coverage is 100%, so both parameters are documented at the schema level. The description reinforces the singular-gene scope and the GENCODE matching behavior, but adds no detail about the limit parameter beyond what the schema already provides.

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 ('GTEx Portal gene expression'), plus exact scope: median TPM of one gene in human tissues, sorted highest first, with matched GENCODE id. It is unmistakable against the sibling set, which is dominated by news/article searches and security lookups.

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 useful calling context (public API v2, no key, GTEx v8, unknown symbols 404), which tells the agent what inputs succeed. However, there is no explicit 'use this when…' framing or exclusion guidance versus alternatives; usage is inferred from the self-evident gene-expression purpose 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 readOnlyHint and openWorldHint, so safety is covered; the description goes beyond that with the payment model ($0.002 per successful call via x402 on Base/Solana/Arc, failed calls free), the fact that no API key is needed, and the result set restriction to stories. It does not cover pagination or result-count behavior beyond the limit param.

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 tight sentences: what it searches, what comes back, then cost. The API provenance and no-key detail are front-loaded, 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 an output schema present, the description needn't explain return shape, and it correctly focuses on source, scope, ordering, and billing. The one gap is sibling differentiation against `search_hackernews_items`, which matters in a list this dense.

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 `q` and `limit` are already fully documented with types and ranges, establishing the baseline 3. The description adds nothing about query syntax, matching behavior, or why `limit` is typed as a string, so it does not exceed what the schema provides.

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 (Hacker News story search) plus the backing API and the returned fields, so an agent knows exactly what this pulls. It does not differentiate from the sibling `search_hackernews_items`, which sounds like it covers the same source, leaving ambiguity about which to pick.

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 context is implied only: 'Returns stories only' and 'most relevant first' hint at scope and ordering, and the pricing note implies a pay-per-call cost model to weigh. There is no explicit when-to-use or when-not-to-use guidance, and no routing versus the near-identical Hacker News sibling.

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?

Beyond readOnlyHint/openWorldHint, the description discloses the upstream source (official Firebase API, public, no key required), the failure mode (deleted or unknown ids return 404), and a concrete cost model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls not charged). Cost and billing behavior is exactly the kind of information annotations cannot 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?

Two tight sentences, front-loaded with the operation and source, followed by the failure mode and price. The only waste is the enumerated field list ('type, title, author, time, score…'), which an output schema already carries.

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 and annotations covering safety, the description fills the remaining gaps an agent needs: auth (no key), error behavior (404), and payment requirements. Rate limits and the relationship to search_hacker_news are the only unaddressed items.

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

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

Schema coverage is 100% and the schema already documents the single 'id' parameter with an example (8863). The description only reinforces that ids are numeric and that unknown ids 404; it adds no format nuance such as string-vs-integer coercion. 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?

The description states a specific operation on a specific resource: fetch one Hacker News item by numeric id from the official Firebase HN API, and it enumerates the fields returned. That is far clearer than the tool name suggests ('search_hackernews_items' actually fetches by id rather than searching). It does not, however, distinguish itself from the closely named sibling search_hacker_news, which an agent could easily pick instead.

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 phrase 'by numeric id' signals this is a lookup tool used when you already have an id. There is no explicit 'use this when…/use X instead' guidance and no mention of the sibling search_hacker_news that performs actual searching.

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?

Goes well beyond the readOnly/openWorld annotations: discloses the pay-per-call model ($0.002 USDC), the payment rails (x402 on Base, Solana, Arc), and that only successful calls are charged. That billing behavior is exactly the kind of risk context an agent needs before invoking.

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 dataset identity and scope before the pricing note; every clause carries information. It is dense but one long sentence, which slightly taxes scanning, keeping it off 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 8 fully documented params, zero required, an output schema, and price/auth details included, an agent has enough to invoke correctly. Sorting/ordering of results and pagination semantics are the only remaining gaps, and the output schema likely covers them.

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

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

Schema coverage is 100% and every parameter already documents defaults and enums inline. The description only loosely restates the field/dimension/period surface, adding no syntax or constraint detail the schema does not already carry, so 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?

Names the exact source (CWTS Leiden Ranking Open Edition 2025, publication-based, OpenAlex, ~2,800 universities) and the exact output (rank, name, country, dimension indicators). An agent can distinguish this from search_shanghai_arwu_rankings or search_university_rankings_mega_pack purely from the 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?

Usage is implied by the resource itself and by the 'for a country or continent, field and period' framing, but there is no explicit when-to-use/when-not or routing to sibling rankings tools (ARWU, GRAS, mega pack). The agent must infer selection from data-source names 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 only cover read-only and open-world; the description adds the things an agent cannot infer: no API key required, a per-call price of $0.002 USDC, the accepted payment rails (x402 on Base/Solana/Arc), and that failed calls are not billed. That cost/authorization disclosure is exactly the kind of behavioral context annotations cannot 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?

Three compact sentences, front-loaded with what it searches and returns, followed by the scope limit and pricing. The field enumeration in the first sentence is dense but every element (payment rail, non-billing on failure) 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?

Covers source, search field, scope limit, key requirement, and billing model; return values are further backed by an output schema, so nothing an agent needs before calling 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 100%, so 'title' and 'limit' are already fully documented with constraints (1-100 chars, 1-20 results, default 5). The description only restates that search is by title and adds no format or syntax guidance, so 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?

Names a specific verb and resource ('search Mangadex manga by title') plus the source (MangaDex public API) and the returned metadata fields. That makes it trivially distinguishable from the many other source-specific search_* siblings.

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

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

'Metadata only; no chapter pages' gives an explicit scope limit that steers the agent away when full chapter content is needed. It stops short of naming an alternative tool or stating prerequisites beyond the no-key note, so it is clear context but not full when/when-not routing.

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?

Beyond the readOnly/openWorld annotations, the description discloses that the underlying API is public with no key required, that results are unvetted ('quality is not checked'), and the full cost model with payment rails (x402, Base/Solana/Arc) and the fact that failed calls are not charged. That is exactly the economic and quality context an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the purpose followed by return fields, quality caveat, then pricing. Every sentence carries information, though the return-field enumeration is somewhat redundant with the output schema.

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 only two optional params, full schema coverage, an output schema, and readOnly annotations, the description covers the remaining unknowns: data provenance, unvetted quality, authentication model, and cost. Nothing needed to call 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 100%, so both parameters (q, limit) are already fully documented in the schema. The description adds no search-syntax hints or semantics for q/limit beyond what the schema states, so 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 (npm registry search), a specific resource (MCP servers that convert Markdown to PDF), and enumerates exactly which fields come back (name, version, publisher, downloads, link). An agent can distinguish this from generic web/news search siblings immediately.

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 ('MCP servers that convert Markdown to PDF', public npm search API) implies when the tool applies, but there is no explicit when-to-use/when-not guidance and no reference to near-neighbor siblings such as search_cran_r_packages or the general web search tools. Usage must be inferred from the domain wording.

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?

Goes well beyond the readOnly/openWorld annotations: discloses de-duplication key (headline), sort order (newest first), per-engine status, that only headlines/snippets are returned with no full text, that Google URLs are redirects, and that billing is $0.003 USDC via x402 on Base/Solana/Arc with failed calls not charged. These are the exact operational facts an agent needs before calling.

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 single front-loaded block where each sentence supplies distinct value: sources, merge logic, item shape, limitation (no full text), link caveat, and price. No filler and no repetition of the title.

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 three-parameter aggregator with an output schema already present, the description covers everything else an agent would need — coverage sources, dedup/sort semantics, result limitations, and payment terms. Nothing material 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 coverage is 100%, so q, limit and engines are already fully documented including ranges and defaults. The description only indirectly reinforces the engines parameter by naming the three providers and noting they are public/no-keys; it adds no format or edge-case guidance beyond the schema, so 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 (search news across the web) and enumerates the three backends it fans out to (Google News RSS, Bing News RSS, GDELT Context 2.0), plus merge/de-dup/sort behavior. This clearly separates it from single-source siblings like search_google_news, search_bing_search and search_gdelt_news.

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 phrase 'in one call' and the explicit list of three sources implies this is the aggregator to prefer over per-source siblings, and the pricing line tells the agent when the cost is warranted. It stops short of explicitly naming alternatives or stating exclusions (e.g. 'use search_google_news for Google-only queries').

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 real context beyond the annotations: it is a public keyless feed and each successful call costs $0.002 USDC via x402 across Base/Solana/Arc, with failed calls uncharged. That billing and auth detail is exactly what annotations cannot express. It stops short of noting rate limits or result freshness/refresh cadence.

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 resource and source, then scope limits, then cost. Dense but every clause carries information; the pricing sentence is long but is genuinely decision-relevant for an agent that must consider spend.

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 readOnlyHint/openWorldHint annotations, an output schema, and full schema coverage, the description only needs to add source scope, access model, and cost — all of which it does. Nothing essential for correct invocation is missing, though freshness characteristics of the RSS feed would round it out.

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 both parameters are already documented and the baseline is 3. The description adds a filter-surface hint, but it says the keyword filter runs over 'title/summary/categories' while the schema's q only covers title or summary — a small mismatch rather than added clarity; limit is not mentioned at all.

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?

Specific verb-plus-resource: New York Times home page headlines pulled from the public NYT RSS feed, with an explicit keyword filter over title/summary. It also bounds scope (latest items, headlines and abstracts only), so an agent can distinguish it from full-article extraction tools and from the other single-source news siblings.

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

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

Usage context is implied rather than stated: 'headlines and abstracts only' signals it is not for full article text, and the RSS-feed framing signals recency-oriented lookup. There is no explicit when-to-use or when-to-prefer-a-sibling guidance (e.g. versus search_article_extractor or search_google_news) and no exclusions 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 the read-only and open-world profile, yet the description adds genuinely useful behavior: data lag (~2 months behind), sort order (largest first), licensing ('Open Government Licence, no key'), and the x402 payment model with 'failed calls are not charged'. That billing detail is material to invocation decisions, though there is no explicit rate-limit or row-count ceiling.

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 resource and source dataset, then grouping, then licensing and price — a sensible priority order with no filler sentences. It is dense and slightly run-on in places, but every clause carries information an agent needs.

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 read-only filtered data query with a full schema and an output schema, the description supplies everything else that matters: provenance, freshness, units, sort order, access terms, and cost. Nothing required to call 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 coverage is 100%, so 3 is the baseline, but the description reinforces semantics the schema only sketches — 'grouped by region, ICB, GP practice or product presentation' maps the groupBy options to their meaning, and 'largest first' clarifies results ordering. It stops short of explaining default-month behavior or the interaction between area and groupBy.

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+resource (NHS England primary-care prescribing data for a drug), the source dataset (NHSBSA EPD), and the exact measures returned (items, actual cost in GBP, quantity) plus grouping dimensions. It is unmistakable against the sibling search tools, which are all news/web/academic search endpoints.

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 explains the matching rule ('match on BNF chemical substance or presentation name') and defaults, which implies when the tool fits, but it never states when not to use it or names an alternative for related needs. No sibling is a close substitute, so the gap is mild rather than harmful.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses two high-value facts: no API key required, and a paid usage model ($0.002 USDC per successful call via x402, failures not charged). This is meaningful behavioral context an agent needs before calling. It doesn't add rate limits or pagination behavior, keeping it below 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?

Front-loads the data source and returned fields, then adds scope limit and pricing. Three tight sentences with little waste, though the field enumeration is slightly list-heavy.

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 covering return values and annotations covering safety, the description fills in the remaining essentials: data scope, no-key auth, and cost model. Complete enough to call correctly.

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

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

Schema coverage is 100% and the single 'limit' parameter is fully documented (1–50, default 10) in the schema. The description adds no further parameter meaning, so the baseline 3 is appropriate.

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), a specific resource (OWGR men's golf ranking) and enumerates returned fields (position, name, country, points, average, last week). Clearly distinguishes itself from the ranking siblings (FIFA, World Rugby, Leiden, etc.) by naming the exact data source and its scope.

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?

Establishes scope clearly with 'current ranking only; no tour or event history', which tells the agent when this tool applies and implicitly when not to use it. It does not name an explicit alternative, so it falls just short of the top band.

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?

Goes well beyond the readOnly/openWorld annotations: discloses ordering, de-duplication, per-item wire tagging, that only headlines/links/dates/summaries are returned, that it is public RSS requiring no key, and the exact cost model ($0.003 USDC per successful call via x402 on Base/Solana/Arc, failures uncharged). That pricing and billing-failure detail is exactly the kind of context an agent cannot infer.

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?

Single front-loaded paragraph that opens with what the corpus is before listing ordering, filtering, fields and price; nearly every clause carries information. It is dense to the point of being a run-on, and the field-restriction note slightly overlaps the output schema, 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?

Covers sources, ordering, dedup, filtering, returned fields, auth model and payment terms for a read-only search tool, which is everything an agent needs before invoking it. An output schema exists, so return-value structure need not be described.

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 all three parameters are already documented, making 3 the baseline. The description corroborates the filter behavior (keyword match on title/summary, per-item wire tags) but adds no syntax or format detail for limit or the comma-separated wires list beyond what the schema states.

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 concrete verb+resource and pins down scope precisely: press releases merged from three named wires (PR Newswire all-news, Business Wire M&A, Newswire.com). That merged scope differentiates it from single-wire siblings such as search_pr_newswire and search_prnewswire_press_releases.

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 merged-source scope plus 'keyword filter on title/summary' and 'newest first, de-duplicated' clearly signals when this is the right tool (broad multi-wire coverage rather than one publisher). However, it never explicitly says to prefer a single-wire sibling when only one publisher is needed, nor names any 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 mark it read-only and open-world, while the description adds substantive behavior: public RSS feed, no API key, USDC x402 payment on Base/Solana/Arc, and failed calls are free. It does not cover pagination or rate limits, but pricing and auth are well disclosed.

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 source and filter, then content and cost. The 'Press release headlines and summaries' sentence is mildly redundant with the first sentence, but overall it is appropriately brief and well structured.

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 simple two-parameter read-only search with an output schema and annotations, the description covers source, filter, auth, and cost sufficiently. It omits explicit sibling routing, which is the main missing context.

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?

Both parameters are fully described in the schema, including q matching title/summary and limit range 1-30 with default 10. The description only echoes the keyword-filter concept and adds no new syntax or semantics 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 states a specific source (PR Newswire), resource (latest news-release list), and mechanism (public RSS feed), with keyword filtering. It does not explicitly distinguish this from the near-duplicate sibling search_prnewswire_press_releases or search_press_release_multi_wire, so it falls 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?

It implies use for latest PR Newswire headlines with optional title/summary keyword filtering and notes that no key is needed. However, it gives no explicit when-not guidance or routing to alternative tools for broader or multi-wire press release search.

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 and openWorldHint, so the safety profile is covered, and the description adds genuinely non-obvious context: it is a public feed needing no key, each successful call costs $0.002 in USDC via x402 on Base/Solana/Arc, and failed calls are not charged. That payment/failure-charging detail is exactly the kind of behavioral trait annotations cannot express. It stops short of rate limits, pagination, or what 'latest' concretely means in time.

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 dense sentences with zero filler: source and scope first, then freshness, then auth, then cost. The telegraphic style ('Public feed, no key.') delivers maximum information per token and the most decision-relevant constraint (paid per successful call) is not buried.

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-optional-param read tool with an output schema, the description covers scope, freshness, auth, and billing, which is close to complete. The remaining gaps are the undefined recency window behind 'latest items only' and the absence of any routing versus the sibling PR-wire tools.

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%, with both q (max 200 chars, all words must appear in title or summary) and limit (1-30, default 10) fully documented in the schema. The description adds only the redundant note that filtering is on title/summary, so the 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?

The description names a specific resource with a narrowing scope: PR Newswire press releases in the health category, pulled from its public RSS feed with a keyword filter on title/summary. That is meaningfully more specific than a tautology, but it never distinguishes itself from the sibling tools search_pr_newswire and search_press_release_multi_wire, so an agent cannot tell from the description alone whether this is the narrower or broader wire 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?

Usage is only implied: 'Latest items only' signals recency scope, and 'keyword filter on title/summary' signals how to search, but there is no explicit when-to-use or when-not-to-use statement. Crucially, no alternative is named – the sibling search_pr_newswire is an obvious substitute and the description gives no rule for choosing between them.

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?

Beyond the readOnly/openWorld annotations, it discloses that the source is NCBI E-utilities, that no API key is required, that only summary fields are returned, and the exact per-successful-call price with failed calls uncharged. The payment model is unusually transparent; rate limits are the main omitted operational 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?

The description is two tight sentences, front-loading what the tool returns and then the commercial/operational constraints. Every clause carries useful information for deciding or calling.

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 one fully documented parameter, an output schema, and readOnly/openWorld annotations, the remaining burden is operational context—source, scope, price, and billing behavior—which the description covers. An agent has enough to invoke this correctly without needing return-shape details in the description.

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 single parameter is fully described in the schema, including comma-separated format and the 1–20 ID limit. The description repeats the 'up to 20 ids' constraint but adds little syntax or meaning beyond the schema, so baseline 3 is appropriate.

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 ('PubMed article metadata by PMID') and lists the exact fields returned (title, journal, publication date, authors, DOI). This clearly distinguishes it from generic article-search siblings because it is PMID-keyed and summary-only.

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 usage context: callers must supply PMIDs, up to 20, and should expect summary fields only with no abstracts. It does not explicitly name alternative tools such as Europe PMC or Crossref when abstracts or broader searching are needed, so it stops short of full when-to-use/when-not 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?

Although annotations already declare readOnlyHint=true and openWorldHint=true, the description adds substantial behavior: public sitemap/no key, newest-first limited recent coverage, headline/link-only payload, and exact x402 payment cost with failed calls not charged. This is valuable operational context 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?

The description is four short sentences with no filler. Scope, return contents, limitations, and payment are front-loaded and easy to scan.

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 read-only news search with annotations and an output schema, the description supplies source, recency scope, content limitations, and payment details. Nothing critical for correct invocation or cost awareness 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 100%, and the schema already documents both parameters including the 200-character keyword limit and default article count. The description only restates the optional headline keyword filter and does not mention the limit parameter or its default, so it adds little 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?

States the specific resource and operation: latest Reuters articles from Reuters' public news sitemap, with returned fields and newest-first ordering. It also explicitly limits scope to headlines and links with no article text, which distinguishes it from full-text extractor and other news-source siblings.

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

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

Makes the use case clear: recent Reuters headlines, optional headline keyword filter, no key required. It also sets exclusions by saying only the most recent sitemap items are covered and only headlines/links are returned, but it does not name alternative tools for full text or historical search.

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