Research papers

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

Annotations already cover read-only, idempotent, and non-destructive semantics, so the bar is lower. The description adds two behavioral facts annotations cannot express: a per-call price ($0.001 USDC via x402, i.e. payment/auth requirement) and a hard batch ceiling of 20 ids.

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 compact sentences: returned fields first, cost constraint second. No filler, and the most decision-relevant content (scope + price) 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?

With an output schema present, return values need not be re-explained, and the cost and batch-size facts round out what an agent needs to invoke it. Missing only error/partial-failure behavior for invalid or nonexistent ids.

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

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

Schema coverage is 100% so baseline is 3, but the description adds the batch limit ('up to 20') that the schema's 'comma-separated' note does not state, giving concrete guidance on how far the id parameter can be pushed.

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 ('Full metadata for ... arXiv ids') and enumerates exactly what metadata is returned. This clearly distinguishes it from siblings like arxiv__search and arxiv__recent, which discover papers rather than resolve known ids.

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 id-based lookup shape ('for ... arXiv ids'), and the 20-id batch hint suggests bulk use. However, it never explicitly says when to prefer this over arxiv__search or arxiv__recent, nor what happens for unknown ids.

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

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

Annotations already cover readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is free. The description adds a genuinely non-derivable fact: a $0.002 USDC per-call cost via x402. It stops short of noting any rate limits, ordering guarantees, or freshness/latency of 'newest'.

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 short sentences, zero filler, with the core purpose front-loaded and the cost caveat second. Nothing is redundant with the title or 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?

An output schema exists, so return-shape explanation is unnecessary, and the schema carries parameter detail. For a two-parameter read tool the description plus structured fields are close to sufficient; only the routing-versus-siblings question is left unaddressed.

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

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

Schema description coverage is 100% — both 'limit' (max 50, default 25) and 'category' (e.g. math.PR) are documented in-schema. The description adds nothing about parameter syntax or validity, 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 (newest submissions) and scope (any arXiv category). 'Any category' implicitly separates it from the hard-coded sibling category tools like arxiv__recent-cs-ai, though it never names them, so the differentiation is inferred 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?

No guidance on when to choose this over arxiv__recent-cs-ai (a fixed category) or arxiv__search (keyword queries). The agent must infer routing from the sibling names alone, which is exactly the gap the description should fill.

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, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational context not present in the annotations: a per-call cost of $0.002 USDC via x402, which matters for invocation decisions.

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 short sentences with no waste. Purpose is front-loaded and the cost caveat follows, so it reads efficiently.

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

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

An output schema exists, so return values need not be explained, and the cost and read-only/idempotent nature are established. For a simple latest-listings tool the only notable gap is guidance on category selection versus siblings.

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 (limit) with 100% schema description coverage, including the max of 50 and default of 25. The description adds nothing 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?

States a specific resource (newest arXiv submissions) and narrows it to the astro-ph category, which differentiates it from the many category-specific 'recent-*' siblings. It does not explicitly name those siblings or the generic arxiv__recent, but the category scoping makes the tool's identity clear.

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?

No guidance on when to choose this over arxiv__recent (all categories) or arxiv__search, nor any note about prerequisites. The agent must infer usage from the category name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: the $0.002 USDC per-call cost via x402, which is a real behavioral consideration for an agent deciding whether to spend. It does not mention rate limits or result-set freshness lag.

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 short sentences, with the substantive purpose front-loaded and the cost disclosure second. Nothing is padded and the title is not restated verbatim beyond what is needed to identify the category.

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 read-only browse tool with an output schema and a fully documented single parameter, the description covers purpose and the cost/payment model. The only real gap is the absence of any routing hint against the many sibling arxiv__recent-* and arxiv__recent 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?

There is one optional parameter and schema description coverage is 100% ('Results, max 50 (default 25)'), so the schema fully documents limit including its cap and default. The description contributes nothing additional about the parameter, which is the expected baseline when the schema does the work.

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

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

States a specific verb (newest submissions) and resource (arXiv cs.AI), so the agent knows exactly what it returns. However, it never explains how it differs from the sibling arxiv__recent (which presumably takes a category) or why the cs.AI-specific variant exists alongside arxiv__search; the distinction rests entirely on the tool name.

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?

Recency ('newest') implies a browse-what's-new use case versus arxiv__search for topical lookup, but this is inferred rather than stated. There is no explicit when-to-use, no exclusion, and no mention of the near-identical arxiv__recent sibling that would let an agent pick correctly.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context the annotations lack: the $0.002 USDC per-call cost and x402 payment mechanism. That cost disclosure is valuable and goes beyond structured data.

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 short sentences, both front-loading the essential information (category/scope, then cost). Every sentence earns its place with no redundancy 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?

With an output schema present, the description needn't explain return values, and annotations cover the safety profile. The category scope and cost are both addressed. The only gap is the absence of any routing guidance versus the sibling recent/search tools, which is minor for a single-parameter listing tool.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented in the schema (max 50, default 25). The description adds nothing about the parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

The description names a specific resource and scope: the newest arXiv submissions in cs.CL (Computation and Language/NLP). This clearly separates it from the many sibling arxiv__recent-* tools by category. It loses the top score only because it never uses an explicit verb like 'list' or 'fetch', relying on the title to imply the action.

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 what the tool returns but gives no when-to-use guidance, no condition selecting it over arxiv__recent or arxiv__search, and no indication of when not to use it. The agent must infer the category routing on its own.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait the annotations omit: a per-call cost of $0.002 USDC via x402. It omits pagination/rate behavior, but an output schema exists and the feed is capped at 50 results.

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 short sentences, front-loaded with what the tool returns and followed by the cost disclosure. Every clause earns its place; there is no filler.

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

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

For a read-only category feed with zero required parameters and an output schema, the description covers purpose and cost adequately. It would be fully complete if it hinted at how it differs from the sibling feeds or the pagination cap, though neither is strictly required to call it correctly.

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

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

Schema description coverage is 100% for the single `limit` parameter ('Results, max 50 (default 25)'), so the schema already carries the semantics. The description adds nothing about limit, which is the correct baseline 3 when structured fields do the heavy lifting.

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

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

States a specific resource (newest arXiv submissions) with the exact category code and human-readable expansion (cs.CR, Cryptography and Security). This lets an agent distinguish it from the twelve sibling category feeds (cs.AI, cs.CL, astro-ph, etc.) without opening any schema.

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

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

The description gives no when-to-use guidance, no exclusions, and never mentions the alternatives. It does not say to use arxiv__paper for a specific paper or arxiv__search for keyword queries, leaving routing entirely to inference from the name.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered elsewhere. The description adds a genuinely new behavioral fact: a per-call cost of $0.002 USDC via x402, which an agent needs before invoking. It omits ordering/pagination behavior, so not quite 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 short sentences, purpose front-loaded, cost disclosure second. Zero filler and nothing repeated from 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?

Return shape is covered by the output schema and safety semantics by annotations, so the description only needs scope plus cost — both present. Minor gap: it doesn't say whether results are ordered by submission date or include abstracts, but nothing essential to 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?

Single `limit` parameter with 100% schema description coverage ("Results, max 50 (default 25)"), so the schema fully documents it. The description adds no format, ordering, or interaction detail beyond that, making the baseline 3 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?

States a specific resource and scope: newest arXiv submissions in cs.CV. The category scoping (cs.CV) is what separates it from the twelve other arxiv__recent-* siblings, so an agent can pick the right one without opening the schema. It stops short of an explicit sibling reference (e.g. arxiv__search for keyword queries), keeping it at 4 rather than 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 newest submissions in cs.CV" implies the use case (recency feed for computer vision) but gives no explicit when-to-use/when-not, no mention of arxiv__search for topic queries, and no prerequisites. Usage is inferable from scope alone, which is the definition of an implied-usage 3.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context absent from structured fields: the per-call cost of $0.002 USDC via x402, which matters for an agent deciding whether to invoke it.

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

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

Two short sentences, zero filler, with the purpose front-loaded and the cost constraint following. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained. For a zero-required-parameter, single-optional-parameter feed, purpose plus cost is nearly complete; only routing guidance relative to siblings 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% for the single 'limit' parameter (max 50, default 25), so the schema fully documents it. The description adds no additional semantics about the limit, which matches the baseline of 3 when structured data carries the burden.

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 with a scoping qualifier: 'newest arXiv submissions in cs.LG (Machine Learning).' The category qualifier implicitly distinguishes it from siblings such as arxiv__recent-cs-ai and arxiv__recent-stat-ml, though it never explicitly contrasts with the generic arxiv__recent feed.

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

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

The description says what the tool returns but gives no guidance on when to choose it over the many sibling category feeds or the arxiv__search tool. It states no prerequisites, exclusions, or alternatives, leaving routing entirely to the agent's inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful non-annotation context: a per-call cost of $0.002 USDC via x402, which affects how freely an agent calls it. No rate limits or result freshness window are given.

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

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

Two tight sentences with zero waste: purpose first, cost second. Nothing redundant or padded.

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 one-optional-param tool with an output schema and rich annotations, the description covers purpose, category scope, ordering ('newest') and cost. It need not explain return values since an output schema exists; only freshness/pagination nuance is left implicit.

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

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

Schema description coverage is 100% and the single 'limit' parameter (max 50, default 25) is fully documented in the schema. The description adds nothing about limit semantics, 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?

States a specific verb+resource with an explicit scope: 'newest arXiv submissions in cs.RO (Robotics)'. The category label is what distinguishes it from the dozen recent-* siblings, so an agent can route correctly, though it never names an alternative explicitly.

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

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

Usage is implied by 'newest submissions' – fetch the latest robotics papers – but there is no when-to-use vs when-not guidance and no pointer to arxiv__search or arxiv__recent for broader queries. Adequate but not 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the per-call cost of $0.002 USDC via x402, which matters for an agent deciding whether to invoke it. It does not discuss pagination or how 'newest' is ordered/refreshed.

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 short sentences, zero filler, with the identity/scope stated first and the billing caveat second. Nothing is redundant with the title or 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?

For a simple single-parameter feed with an output schema, the definition covers what the tool returns (newest econ submissions) and the unusual payment requirement. The only minor gap is the absence of routing guidance relative to arxiv__recent and arxiv__search, which a family this large would benefit from.

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?

There is a single optional 'limit' parameter with 100% schema description coverage ('Results, max 50 (default 25)'), so the schema already carries the meaning. The description adds nothing about the parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific resource and scope: 'newest arXiv submissions in econ (Economics)'. That is enough to separate it from the many sibling category feeds (recent-cs-ai, recent-quant-ph, etc.) and from arxiv__search, but it does not explicitly name which sibling it supersedes or how it differs from arxiv__recent.

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 category label - an agent can infer this is for browsing the latest econ papers rather than searching. There is no explicit when-to-use statement, no exclusion (e.g. use arxiv__search for topical queries), and no guidance on when to prefer arxiv__recent with an explicit category argument.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond the annotations: the $0.002 USDC cost per call via x402, which alerts the agent that invoking this tool incurs a payment. It stops short of describing pagination or result volume 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?

Two short sentences with zero waste. The purpose is front-loaded, and the cost constraint follows immediately. Nothing is redundant or padded.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description adds the critical payment note. It could be slightly more complete by clarifying ordering (newest-first) or relationship to the general arxiv__recent tool, 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% with a single 'limit' parameter (max 50, default 25) fully documented in the schema. The description adds no parameter detail beyond that, so the baseline of 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 and resource ('newest arXiv submissions in q-bio (Quantitative Biology)') and names the exact category, which distinguishes it from sibling category tools like arxiv__recent-cs-ai or arxiv__recent-stat-ml. An agent can pick the right category feed 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?

The category scope implies when this tool is appropriate, but there is no explicit guidance on when to choose it over arxiv__recent (the general feed) or arxiv__search. No exclusions or alternatives are named, so selection relies on inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-structured context that the annotations do not carry: a per-call price of $0.002 USDC via x402, which is material to an agent deciding whether to invoke it. It does not mention ordering, result freshness windows, or behavior on empty results.

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 short sentences, both load-bearing: the first gives purpose and scope, the second gives the cost constraint. Purpose is front-loaded with zero filler.

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

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

For a read-only, single-optional-parameter feed with an output schema available, the description covers purpose, scope and the paid-invocation requirement. Missing only minor operational details such as sort order or pagination, which an agent could reasonably want when deciding how to use limit.

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 optional parameter (limit) and schema coverage is 100%, with the schema itself documenting the max 50 and default 25. The description adds no syntax, format, or trade-off information 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 and scope: newest arXiv submissions restricted to the q-fin category, which cleanly separates it from arxiv__recent (general) and the other arxiv__recent-* category tools. The parenthetical expansion of q-fin removes any ambiguity. It stops short of explicitly naming the sibling it differs from, so it is clear but not fully self-differentiating.

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 name and the word 'newest' — an agent can infer this is the recency feed for quantitative finance — but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as arxiv__recent or arxiv__search. The agent must infer the selection rule from the tool name alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world). The description adds genuinely new behavioral context not in the structured fields: the $0.002 USDC per-call cost via x402, which matters for an agent deciding whether to invoke it. Rate limits and freshness window are still unstated.

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 short sentences, front-loaded with the resource scope and immediately followed by the cost note. No 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?

For a simple, single-optional-param feed with an output schema and full annotations, the definition is nearly complete. The only gap is that the freshness window ('newest') is never quantified.

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% (the single 'limit' param is fully documented with max and default), so the schema carries the semantics. The description adds nothing about the limit parameter, 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?

States a specific verb (newest submissions) and resource (arXiv quant-ph), so the agent knows exactly what it returns. The category name itself differentiates it from the many other recent-* siblings, but there is no explicit routing language naming those alternatives.

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 'newest submissions in quant-ph' — an agent can infer this is for latest quant-ph papers — but there is no explicit when-to-use guidance, no mention of when to prefer arxiv__search or the all-category arxiv__recent, and no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: a per-call cost of $0.002 USDC via x402, which an agent needs for budget decisions and which no structured field conveys.

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

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

Two tight sentences with zero waste. The category/scope statement is front-loaded and the cost caveat follows, so the most important selection signal comes first.

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

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

An output schema exists, so return values need not be explained, and the one parameter is fully documented in the schema. The description covers category scope and the payment requirement, leaving only minor gaps such as ordering guarantees or refresh cadence.

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 single 'limit' parameter is fully documented in the schema (max 50, default 25), so the baseline is 3. The description adds no additional parameter meaning, but none is needed.

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+scope: newest arXiv submissions in the stat.ML category. This cleanly distinguishes it from the many sibling recent-* tools (cs-ai, cs-cv, quant-ph, etc.) and from arxiv__recent/arxiv__search without needing to open a 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?

Usage is implied by 'newest submissions' and the category, so an agent can infer when it applies, but there is no explicit guidance on when to prefer this over arxiv__recent (the generic feed) or arxiv__search for topical queries, and 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered structurally. The description adds genuinely non-obvious behavioral context beyond that: a per-call cost of $0.002 USDC via x402, which materially affects whether an agent should invoke it. It does not describe pagination or result volume, but the output schema carries the return shape.

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 tightly written sentences, front-loaded with the core capability and followed by the sorting options and the cost caveat. No filler, and the pricing detail earns its place because it is not available in any structured field.

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 the description need not explain return values, and annotations fully cover the safety profile. What is supplied — query dimensions, sort semantics, and cost — is sufficient to invoke the tool correctly; only pagination behavior for start/limit is left to the schema, which is acceptable.

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

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

Schema description coverage is 100%, so every parameter already has documentation and the baseline is 3. The description restates the searchable dimensions (keywords, title, author, category) and mentions relevance-vs-newest sorting, but adds no syntax, format, or constraint detail beyond what the schema entries ('all must match', 'max 50', 'default 20', 'cs.CL') already provide.

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 ('Search arXiv') and enumerates the searchable fields (keywords, title, author, category), which distinguishes it from retrieval siblings like arxiv__paper and the arxiv__recent-* feeds. It stops short of explicitly naming those siblings, so an agent must infer the boundary rather than being told it.

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 verb 'search' and the enumerated query fields, so an agent can reasonably conclude this is the general query tool. However, there is no explicit statement of when to prefer this over arxiv__paper or the topic-specific arxiv__recent-* tools, and no exclusions or prerequisites are 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: the rate/allowance model and the x402 per-call charge, which is important for an agent deciding whether to invoke it repeatedly.

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 short sentences, both earning their place: the first enumerates the payload, the second covers the cost model. Front-loaded and free of filler, though the field list is somewhat 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 present, return values need not be explained again, and the pricing disclosure covers the main non-obvious behavior. The missing piece is routing guidance versus sibling tools (crossref__search, crossref__journal), which is the only meaningful gap for a one-parameter 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?

There is a single required parameter and schema description coverage is 100%, so the schema does all the work. The description adds no format or normalization guidance for the DOI beyond what the schema states, which is the expected baseline here.

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 resource (DOI metadata) and enumerates the returned fields (title, authors, journal, dates, references count, licence), so the agent knows exactly what a call yields. It is specific but does not explicitly differentiate itself from siblings like crossref__search or crossref__journal, which matters given the crowded scholarly-tool namespace.

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

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

There is no statement of when to use this tool versus crossref__search (query-based lookup) or the other crossref__* endpoints. The only guidance given is commercial (free tier, then $0.002 via x402), which tells the agent about cost but not about selection.

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, idempotentHint, openWorldHint, and non-destructive behavior, so safety is covered. The description adds genuinely new operational context the annotations lack: a free daily allowance and a $0.002 USDC x402 charge after it, which matters for call budgeting. It doesn't note result limits or pagination, keeping it short of a 5.

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

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

Two tight sentences: the capability is front-loaded and the cost model follows. Every clause earns its place, with no boilerplate or restatement 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 single-parameter lookup with an output schema already present, the description covers capability, return content, and cost. Only minor gaps remain — result limits, pagination, and how name matching works — which are low-stakes here.

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 exists and schema coverage is 100% ('q: Funder'), so the schema already carries the load. The description's 'by name' adds a small hint that q is a name-based query rather than an ID lookup, but nothing about matching behavior or expected input format. 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 gives a specific verb+resource ('Research funders') and states the return content ('with Funder Registry ids'), which clearly distinguishes it from crossref__members, crossref__journal, and crossref__search as a funder-lookup tool. It stops short of naming or contrasting those siblings explicitly, so it lands at 4 rather than 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 says what it is but never says when to reach for it over the other crossref or ror__search tools, nor does it state any prerequisites (e.g., that 'q' must be a funder name rather than a DOI or member). Usage is only inferable from the tool name and resource.

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

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

Annotations already declare readOnly, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds genuinely useful context beyond them: a free daily allowance, then $0.002 USDC per call via x402, which tells the agent about throttling and cost before invoking. It does not contradict any annotation.

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 short sentences, both earning their place: the first states the resource and payload, the second states the cost model. The most decision-relevant content 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Combined with the pricing disclosure, the definition is nearly complete; only error behavior for invalid or unknown ISSNs is unaddressed.

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

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

Schema description coverage is 100% for the single ISSN parameter, so the schema already carries the semantics and baseline 3 applies. The description reinforces that the lookup is keyed by ISSN but adds no format, validation, or normalization 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?

The description names the specific resource (journal), the key (ISSN), and the returned fields (title, publisher, DOI counts), which is more than a restatement of the title. It is clearly distinguishable from siblings like crossref__doi or crossref__search, though it does not explicitly 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?

There is no explicit when-to-use guidance, no prerequisites (e.g., valid ISSN format), and no routing to alternatives such as crossref__doi when a DOI is known. The pricing sentence is invocation-relevant but is cost information, not usage guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely new operational context: a free daily allowance followed by $0.002 USDC per call via x402, which an agent needs before invoking it repeatedly.

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 short sentences, front-loaded with the resource and lookup key, with zero filler. Every clause carries information the agent does not get from structured fields.

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

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

An output schema exists, so return values need not be described, and the cost model is disclosed. The main gap is the absence of routing guidance relative to the sibling Crossref lookup tools, but for a single-parameter search this is otherwise complete.

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

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

Schema description coverage is 100% for the single 'q' parameter ('Publisher'), so the schema already carries the parameter meaning. The phrase 'by name' loosely reinforces that q is a publisher name but adds no syntax or format 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?

The description names the specific resource (Crossref member publishers) and the lookup key (name), which separates it from crossref__journal, crossref__funders, and crossref__doi. It is a noun phrase rather than a clean verb+resource, but the intent is unambiguous.

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

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

There is no guidance on when to choose this tool over its Crossref siblings (e.g. funders vs journal vs members) and no stated preconditions beyond the required query. The pricing sentence describes cost, not usage context.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot carry: a metered cost model with a free daily allowance and per-call overage pricing. It stops short of describing result limits or pagination.

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 short sentences with zero filler; the core purpose is front-loaded and the cost caveat follows. 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?

For a one-parameter search tool with an output schema present, the description covers purpose and the notable cost dimension, so an agent can call it correctly. The remaining gap is routing guidance against the many sibling search tools, which is not strictly required to invoke this one.

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?

There is a single parameter 'q' and schema description coverage is 100%, so the schema already documents it. The description adds no syntax or field-targeting detail (e.g., author:, title:, DOI-style queries), leaving parameter semantics 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?

States a specific verb and resource: 'Bibliographic search across Crossref works.' An agent knows this searches the Crossref corpus rather than fetching or listing other entity types. It does not, however, distinguish itself from the sibling crossref__doi (lookup by identifier) or crossref__journal, so the differentiation is left to naming.

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 only explains billing ('free within the daily allowance, then $0.003 USDC per call'). It gives no guidance on when to search with this tool versus resolving a known DOI via crossref__doi, or versus the PubMed/arXiv/Semantic Scholar 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description meaningfully adds the cost and rate-limit model ('a few free samples a day, then $0.002 USDC per call via x402'), which an agent needs before invoking a paid endpoint. Return-format disclosure is unnecessary since 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?

Two short sentences, zero filler, and the scope statement is front-loaded ahead of the cost note. Every sentence carries distinct 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?

Safety, parameters, and return shape are covered by annotations, the schema, and the output schema respectively. The notable gap is sibling differentiation: with both pubmed__search and clinical-trials__search present, the description should say when this narrow clinical-trial-filtered endpoint is preferred.

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 documents the sole 'term' parameter including the '[pt] filter' hint. The description adds no syntax or semantics beyond the schema, so the baseline of 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 resource and a narrowing scope: 'PubMed citations that are clinical trial reports for a query.' This functionally distinguishes it from the broader pubmed__search, though it never names that sibling explicitly. Purpose is clear, but routing between the two pubmed search tools still takes inference.

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

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

There is no guidance on when to use this tool versus pubmed__search or pubmed__pmc-search, despite those siblings existing. The only conditional information given is the pricing model, which is not a usage-selection rule. An agent must guess based on the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: a daily free-sample quota and a per-call cost via x402. It does not detail how payment is authorized or what happens when the free quota is exceeded, but the cost disclosure is meaningful.

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 short sentences, front-loaded with the purpose and followed by the cost model. Every sentence earns its place; there is no filler or repetition.

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 a single required parameter, rich annotations, and an output schema, the description covers what the tool returns (article IDs) and the cost model. It omits usage context relative to sibling tools, but that is the main gap rather than a missing critical detail.

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% for the single 'term' parameter, which is documented as 'Query'. The description does not add any parameter-level semantics, so the baseline of 3 applies when the schema already carries the full burden.

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 resource and scope: 'Free full-text article ids in PubMed Central.' This differentiates it from sibling pubmed__search (general PubMed) and other PubMed tools by focusing on PMC full-text article IDs. The verb 'search' is absent from the description itself, though the tool name and title supply it.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as pubmed__search or pubmed__clinical-trials-search. The pricing model implies a paid search but does not state conditions for choosing this tool over 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema context: a free-sample quota and a per-call price ($0.002 USDC via x402), which matters for agent call budgeting. It stops short of describing result format or pagination.

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 what is returned before the cost caveat. 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 an output schema present, the description needn't explain return values, and it covers input syntax and cost. It is adequate for a 1-parameter tool, with only sibling differentiation and result-count/limit behavior left unaddressed.

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

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

Schema coverage is 100% and the single 'term' parameter is described only as 'Query'. The description adds real value by noting support for PubMed query syntax, which tells the agent the accepted input format beyond the schema's minimal label.

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?

Clearly states it returns PubMed ids matching a query, which is a specific verb+resource+return type. However, it does not differentiate itself from close siblings like pubmed__pmc-search, pubmed__clinical-trials-search, or pubmed__summary, so an agent must infer the distinction from names 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?

There is no guidance on when to use this versus the many sibling search tools (PMC, clinical trials, summary). Usage is only implied by the mention of PubMed query syntax; no prerequisites or exclusions are stated.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior. The description adds pricing/rate-limit context ('A few free samples a day, then $0.002 USDC per call via x402'), which is genuinely useful behavioral information beyond annotations. However, it doesn't disclose failure modes for invalid IDs or output format details. With annotations handling safety, a 3 is reasonable.

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 concise sentences front-loading the return fields and input format, then pricing. No wasted words, though the pricing sentence could be seen as slightly tangential to core function.

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 format details are not needed. The description covers input format, output fields, and pricing. It lacks workflow guidance (e.g., get IDs from search) but is otherwise complete for a simple lookup 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%, and the single parameter is documented as 'PMIDs, comma separated'. The description confirms the comma-separated format, reinforcing the schema. For a single well-documented parameter, this is sufficient. Baseline 4 for 0-1 params with high coverage.

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: returns article metadata (title, authors, journal, date, DOI) for given PubMed IDs. Distinguishes itself from sibling pubmed__search by being an ID-based lookup rather than a search. It doesn't explicitly name siblings, but the input shape (comma-separated IDs) makes its role clear.

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?

No guidance on when to use this versus pubmed__search or pubmed__pmc-search. The pricing note implies it's for metadata retrieval, but it doesn't say to call search first to obtain IDs. An agent must infer the workflow.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuine context beyond them: the return shape (confidence flag plus candidate organisations) and the pricing/billing behavior (free within daily allowance, then $0.001 USDC via x402). That billing detail is material and not encoded anywhere else.

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

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

Two sentences, zero waste, and front-loaded: the core operation comes first, then the behavioral/billing addendum. 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?

An output schema exists, so return values need not be spelled out, and the description still summarizes them. For a one-parameter, read-only lookup, the description plus annotations plus output schema cover everything an agent needs to invoke it correctly, including cost.

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 a single parameter, so the schema already documents 'affiliation'. The description slightly enriches it by clarifying the expected format is a free-text string as printed on a paper, but this is marginal beyond the schema. 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: converting a free-text affiliation into the matching organisation. This is clearly distinguishable from siblings like ror__search (query-based lookup) or ror__organisation (ID lookup) because it names the exact input ('as printed on a paper') and output (match with confidence flag and candidates).

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 'as printed on a paper' implies the use case (resolving raw affiliation strings from publications), but no alternatives are named and no explicit when-not guidance is given against ror__search or ror__organisation. Usage context is inferable but not stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds valuable behavioral context about cost: free within the daily allowance, then $0.001 USDC per call via x402. It does not contradict annotations and meaningfully supplements them.

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 sentences, front-loaded with the tool's purpose and followed by the pricing model. Every sentence earns its place with no redundancy.

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 single-parameter lookup with a full output schema and safety annotations, the description covers what an agent needs: purpose, accepted identifier types, and cost. Nothing critical 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 the single 'id' parameter with the same list of identifier types. The description adds no additional syntax, format, or example beyond what the schema provides, 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?

The description states a specific verb and resource: 'Find the organisation' and enumerates the accepted external ID types. This distinguishes it from siblings like ror__search and ror__organisation by input domain, though it does not name those alternatives explicitly.

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

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

Usage is implied by the accepted input types: use this when you have a GRID, ISNI, Wikidata QID, or Crossref Funder ID. There is no explicit guidance on when not to use it or which sibling to prefer for other lookup scenarios.

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

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

Annotations already declare this as a read-only, idempotent, open-world, non-destructive operation, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond that: the payment model (free within a daily allowance, then $0.0005 USDC per call via x402), which affects how aggressively an agent should call it.

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

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

Two tight sentences with the record contents front-loaded and pricing second; virtually no filler. The opening fragment 'Full record:' is slightly clipped as a standalone sentence but carries real information density.

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 document return shape, yet its field enumeration still helps the agent decide relevance at a glance. Annotations cover safety, and the cost model is disclosed; the main missing piece is guidance on when this beats its ror__ siblings.

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 single id parameter is documented in the schema with an example format. The description adds no further meaning about the id parameter, 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?

The description enumerates exactly what the tool returns (names/aliases, types, status, founding year, location, website, domains, external ids), which makes it clear this is a full-record lookup keyed by ROR id, matching the title. It does not, however, explicitly contrast itself with siblings like ror__search, ror__relationships, or ror__external-id, so the agent must infer the distinction.

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

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

There is no statement of when to use this tool versus ror__search (to find an id) or ror__relationships/ror__external-id (for narrower views). The only context offered is the pricing sentence, which informs cost but not tool selection.

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, idempotentHint, non-destructive and open-world behaviour, so the safety profile is covered. The description adds genuinely new behavioural context not present in structured fields: a quota ('free within the daily allowance') and a per-call price once exceeded, which materially affects an agent's willingness to call repeatedly. It stops short of noting behaviour on unknown or deprecated ROR ids.

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 short sentences, no filler, and the substantive content (what is returned) is front-loaded before the pricing note. Nothing could be trimmed without losing 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 return shape need not be described, and the cost model is supplied. What is missing is routing guidance against the closely related ror__organisation tool, which is the main decision an agent faces for a one-parameter 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?

There is a single required parameter and schema coverage is 100%, with the schema itself giving a concrete format example (052gg0110 or the full URL). The description adds no further meaning beyond that, 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?

The description names a specific resource and the exact relationship set returned ('Parent, child and related organisations of a ROR record'), which is more informative than the title alone. It does not explicitly contrast itself with ror__organisation or ror__search, so an agent must infer that those return the record itself rather than its graph neighbourhood.

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

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

There is no statement of when to prefer this tool over ror__organisation or ror__search, nor any prerequisite or exclusion. The only guidance offered is commercial (free tier then per-call price), which tells the agent nothing about selection.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: the cost model (free within a daily allowance, then $0.001 USDC per call via x402), which an agent should know before invoking. It stops short of stating result limits or pagination.

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: the search capability and filters come first, the pricing caveat second. Every clause carries information and nothing is padded.

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

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

An output schema exists, so return values need no explanation, and the description covers purpose, filter dimensions and cost. The only gap is operational detail such as result limits, pagination or match behavior for ambiguous queries.

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 every parameter is documented in-schema (q as name/acronym/keyword, country as 2-letter code, type as a fixed list). The description mirrors those same fields without adding format or syntax detail, 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 ('Find research organisations') plus the three match fields (name, acronym, keyword), so an agent knows exactly what it retrieves. It does not, however, differentiate itself from the adjacent scholarly__institutions-search sibling, which covers a similar resource.

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 only restates capability ('optionally filtered by country and type'); it never says when to use this tool versus ror__organisation (single lookup) or scholarly__institutions-search, nor any preconditions or exclusions. No routing guidance is present.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: a cost/quota model (free within the daily allowance, then $0.002 USDC per call via x402), which is valuable for invocation planning.

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 short, front-loaded sentences with no waste. It is efficient, though almost too terse to carry the usage guidance a fresh agent might want.

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 trivial single-param lookup with a full output schema and complete annotations, the description covers the identity, scope, and cost model. Nothing critical for correct invocation is missing, though routing guidance versus the search siblings 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?

Only one parameter with 100% schema coverage, where the schema already documents the accepted 'OpenAlex id or orcid:…' format. The description restates the accepted id types but adds no 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 verb+resource: fetch 'One researcher by OpenAlex id or ORCID'. The singular 'One researcher' implicitly distinguishes it from the plural sibling scholarly__authors-search, though it never names that sibling explicitly.

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

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

There is no explicit when-to-use guidance or named alternative. The singular phrasing weakly implies a direct-lookup use case versus the search siblings, but the agent must infer when to pick this tool over scholarly__authors-search or scholarly__autocomplete.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema behavior: a metered payment model (free within daily allowance, then $0.002 USDC per call via x402), which tells the agent there is a cost/auth consideration before calling. It stops short of any rate-limit or result-shape detail, but that is largely carried by the output schema.

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

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

Two short telegraphic fragments, front-loaded with the resource and its returned metrics, then the pricing caveat. Efficient, though the first fragment is a noun phrase with no explicit verb, which slightly reduces clarity for no length savings.

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 fields need not be detailed and the annotations cover the safety profile; the description correctly spends its words on the one thing structured fields can't express — the paid-metering model. For a one-parameter, read-only lookup tool this is complete.

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

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

There is a single required parameter with 100% schema description coverage ('Author name'), so the schema already does the heavy lifting and the baseline is 3. The description adds nothing about name format (e.g. full name vs. surname, boolean syntax) that would go 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 identifies the resource (researchers/authors) and the payload returned (h-index, works, citation counts), and the title supplies the search verb. It is clear enough to distinguish author search from works-search or sources-search, but it never contrasts itself against the singular sibling scholarly__author, so sibling differentiation is only implied.

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?

No when-to-use guidance is given: nothing says whether to reach for this versus scholarly__author (ID lookup) or scholarly__autocomplete (typeahead), nor what input form the 'search' value should take. The only contextual statement is about cost, not selection.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful pricing context ('Free within the daily allowance, then $0.001 USDC per call via x402'), which is beyond what annotations provide and relevant for agent decision-making on cost.

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 short sentences, front-loaded with capability then pricing details. No wasted words.

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

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

An output schema exists, so return values needn't be explained. The description covers purpose, performance characteristic, and pricing. It could mention the autocomplete UX expectation (prefix matching, limited results) but is complete enough for a single-param 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?

Only one parameter with 100% schema description coverage ('Partial title'), so the baseline is 3, but the description adds the word 'title' contextually which reinforces the parameter's scope as titles specifically.

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: 'Fast title autocomplete across works.' The adverb 'Fast' signals latency characteristics relevant for autocomplete. However, it doesn't differentiate from siblings like scholarly__works-search, which could be confused with a title autocomplete scenario.

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?

No guidance on when to use autocomplete vs full search (scholarly__works-search) or when partial-title matching is appropriate. Pricing info is provided but that informs cost, not tool selection.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds genuinely new behavioral context beyond that: a cost/allowance model ('Free within the daily allowance, then $0.003 USDC per call via x402'), which is the kind of rate/billing detail the annotations do not convey.

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

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

Two short sentences, zero filler, and the core purpose is front-loaded ahead of the cost note. 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, the description need not explain return values, and the annotations carry the safety profile; the description covers purpose and cost. The main gap is the absence of any routing guidance relative to the many sibling search/work 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 coverage is 100% and there is only one parameter, so the baseline is 3. The description adds the meaning that the value is an OpenAlex work id, but the schema's own example ('cites:W2919115771') uses a filter syntax that the description does not reconcile, leaving mild ambiguity about the exact expected format.

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 relationship: 'Works that cite a given OpenAlex work id.' This clearly distinguishes it from sibling scholarly__work (a single work) and scholarly__works-search (general search) by naming the citation relationship, though it does not explicitly name those alternatives.

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

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

There is no when-to-use, when-not-to-use, or alternative-routing guidance. The pricing sentence informs about cost but does not tell the agent when this tool is the right choice versus scholarly__works-search or scholarly__work.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value by disclosing the cost model (free within daily allowance, then $0.002 USDC via x402), but says nothing about result limits, pagination, or what 'output stats' actually contains.

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 resource and then the cost caveat; nothing is redundant. It loses a point only because the primary purpose is expressed as a noun phrase rather than an explicit action.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. However, for a search tool sitting among several institution/organization search siblings, the absence of any matching-scope or alternative-routing detail leaves a real gap.

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

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

Schema description coverage is 100% for the single 'search' parameter, so the schema already carries the semantics. The description adds no query-syntax or matching-behavior detail, 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?

The description identifies the resource precisely ('Universities and research institutions with output stats'), and the tool name supplies the search verb. It is clear what domain is queried, but it never distinguishes itself from the obvious sibling ror__search, which also resolves organizations/institutions.

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?

No when-to-use, when-not-to-use, or alternative routing is provided. The only guidance is commercial (free allowance then x402 pricing); an agent gets no help deciding between this and ror__search or ror__organisation.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context — the free daily allowance and the $0.002 USDC per-call x402 fallback — which is material to an agent deciding whether to invoke it. It stops short of describing result shape or pagination limits, which keeps it from a 5.

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

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

Two short sentences, no filler, with the resource identity front-loaded and cost information second. Every clause carries information the agent cannot get from the schema alone.

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

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

Output schema exists, so return values and impact-stat fields need no explanation here, and annotations cover the safety profile. What remains thin is query construction for the sole parameter, but overall the definition is complete enough for a one-parameter lookup tool.

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

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

Schema description coverage is 100% and the single 'search' parameter is required, so the schema fully documents input. The description adds nothing about how to phrase the query (journal title vs. ISSN vs. publisher), so the baseline of 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 names the resource precisely ('journals and repositories with impact stats'), which maps to the OpenAlex 'sources' concept and cleanly distinguishes it from scholarly__works-search, scholarly__authors-search, and scholarly__institutions-search. It never states the verb 'search' explicitly, but the noun phrase plus the tool name leaves no real ambiguity.

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

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

There is no when-to-use guidance, no mention of when to prefer this over crossref__journal or scholarly__works-search, and no prerequisites or input conventions given. The only operational note is pricing, which is cost information rather than usage 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety/trait disclosure is largely covered. The description does add genuinely useful behavioral context absent from annotations: the free daily allowance and the $0.002 USDC per-call x402 charge. It still says nothing about result limits, pagination, or throttling 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?

Two compact sentences with no padding, and the core purpose leads. The pricing sentence is short and earns its place by disclosing cost, though it is the less critical half of the definition.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains missing is any sibling differentiation or guidance on how topic search relates to works/sources/autocomplete search, but the core call contract is otherwise 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?

There is a single required parameter documented at 100% schema coverage, so the schema already carries the semantics. The description adds nothing about the 'search' string (syntax, matching behavior, field scope), which is the baseline-3 case.

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 phrase 'Research topics and fields' identifies the resource but never states a verb; the search action is only inferable from the tool name. It gives no signal distinguishing it from siblings like scholarly__works-search, scholarly__sources-search, or scholarly__autocomplete.

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

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

There is no indication of when to use this tool versus the many other scholarly search endpoints, nor any prerequisites or exclusions. The pricing sentence describes cost, not usage context.

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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by disclosing the cost model: free within a daily allowance, then $0.002 USDC per call via x402. It does not describe error handling for invalid IDs, but the pricing disclosure is a meaningful addition.

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 short sentences with zero waste: the first states what is returned and the accepted identifier formats, the second discloses the cost model. The most important information is front-loaded and 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?

For a simple single-resource lookup tool with full schema coverage and an output schema, the description supplies the essential identifier formats and the pricing model. It omits error behavior for unknown IDs and does not mention the output structure, but the latter is covered by the output schema. The description is nearly complete for the tool's complexity.

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 single id parameter is already documented as 'OpenAlex id or doi:…'. The description adds concrete prefix examples ('W…' and 'doi:10.…'), but this is marginal value beyond the schema. The baseline of 3 is appropriate when the schema already does the heavy lifting.

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

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

The description clearly states it returns a single scholarly work identified by OpenAlex ID or DOI, which distinguishes it from the sibling scholarly__works-search tool. However, it does not use a direct verb like 'retrieve' and does not explicitly name the alternative search tool, so it falls just short of full sibling differentiation.

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 by specifying the required identifier formats, but it never states when to use this lookup versus scholarly__works-search or crossref__doi. There is no explicit guidance on when this tool is preferred over alternatives, leaving the agent to infer the context.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: the cost model (free within a daily allowance, then $0.003 USDC per call via x402), which is material for an agent deciding whether to call it. It stops short of describing result limits or pagination.

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 purpose and followed by the cost constraint. No filler or repetition of the tool name.

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

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

An output schema exists, so return values need not be explained, and the description confirms the shape of results. Combined with the pricing note, an agent has enough to call it, though limits on result volume and the daily allowance size are 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?

There is a single parameter with 100% schema coverage, so the schema already documents it. The description adds nothing about query syntax, supported operators, or field targeting, which is the baseline-worthy 3 given high coverage.

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 ("full-text search of scholarly works") and even previews what results contain (citations, authors, open-access links). It does not, however, differentiate itself from sibling work-retrieval tools such as scholarly__work or scholarly__citing-works, so an agent must infer the boundary.

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

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

Usage is implied by the phrasing (search when you want papers by keyword), and the description adds a practical constraint about the free daily allowance and per-call pricing. There is no explicit statement of when to prefer this over scholarly__work or the crossref/pubmed/arxiv search siblings.

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