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

With no annotations provided, the description must carry the full burden. It discloses that the tool uses arXiv's `cat:` query syntax and supports multiple categories, which adds useful context. However, it does not mention the return format, default result count, or any constraints like invalid categories or rate limits. For a read-only listing tool, this is acceptable but not comprehensive.

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 concise sentences with no fluff. The primary purpose is stated first with a clear example, and the second sentence adds the multi-category capability and syntax detail. All information is relevant and efficiently delivered.

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

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

The tool is simple, but with no annotations, no output schema, and incomplete parameter documentation, the description leaves gaps. It covers the category parameter well but does not explain max_results or the expected output (e.g., list of paper titles/IDs). An agent could call it correctly for a basic case, but would lack clarity on optional behavior and response shape.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains the 'category' parameter with examples and comma-separated syntax, but completely omits the 'max_results' parameter, leaving its meaning and default unspecified. The description adds value for one parameter but not the other, resulting in partial compensation.

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 the verb 'List' and the resource 'most recently submitted arXiv papers' scoped by category. It differentiates from sibling tools like arxiv_paper_search_by_query (search by query) and arxiv_paper_detail_by_id (detail by ID) by specifying category-based listing. The examples and syntax note make the purpose 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?

The description makes it clear this tool is for listing by category, which distinguishes it from search and detail tools, though it does not explicitly name alternatives or state when not to use it. The category-centric purpose and the note on multiple categories provide sufficient context for an agent to choose this tool over siblings, but explicit exclusions are absent.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Get' weakly implies a read-only operation, but the description does not mention error behavior for invalid IDs, rate limits, authentication needs, or any other behavioral traits. It provides only the barest safety hint.

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 a single front-loaded sentence with no filler words. It efficiently states the core purpose, though its extreme brevity leaves out important context.

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 tool with no annotations, no output schema, and only a terse purpose, the description is incomplete. It does not explain what fields the returned metadata contains, what format paper_id takes, or that a search tool is the intended path to obtain the ID. An agent would lack critical information needed for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It only ties paper_id to 'a specific ArXiv paper,' which is a slight improvement over the raw schema, but it does not specify the expected format (e.g., arXiv ID like 2101.12345) or how the ID is obtained. This is insufficient for an agent to correctly construct the parameter.

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

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

The description uses a clear verb ('Get') and identifies both the resource ('a specific ArXiv paper') and the information type ('abstract/metadata'). It distinguishes itself from sibling search tools like arxiv_paper_search_by_query by implying a targeted lookup, though it does not explicitly mention 'by ID' or name the alternative.

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

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

No guidance is given on when to use this tool versus alternatives. It does not state that the paper_id is typically obtained from a search tool, nor does it mention any exclusions or prerequisites. The only implicit cue is 'for a specific ArXiv paper,' which is minimal.

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?

No annotations are provided, so the description must carry the behavioral burden. The description discloses that the query is passed verbatim, that field prefixes are supported, and that a bare title yields a loose full-text search. This adds valuable behavioral context beyond the schema. However, it does not mention any side effects (likely none for a read-only search), authentication needs, rate limits, or what the output format looks like (no output schema exists). The description is not misleading, but it leaves several behavioral aspects undisclosed.

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 concise and well-structured. It opens with a clear purpose statement, then immediately provides actionable details about query construction, including examples and a caveat. Every sentence adds value; there is no redundancy or fluff. The critical usage information is front-loaded, and the warning about bare titles is placed at the end to avoid distraction.

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 that there is no output schema and only two parameters, the description should explain what the tool returns and how to interpret results. It does not mention the return format, pagination, or how results are ordered. It also does not explain how `max_results` affects the response. The description is strong on query semantics but incomplete on output expectations and parameter effects, leaving an agent to guess at the result structure.

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

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

Schema coverage is 0%, so the description must compensate for both parameters. The description thoroughly explains the `query` parameter: it is passed verbatim, field prefixes work, and examples are given. This is excellent. However, `max_results` is not mentioned at all; its meaning is left to inference from the name and default value. Since the description covers only half of the parameters, it partially compensates for the lack of schema descriptions.

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

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

The description clearly states 'Search for papers in ArXiv using a query string.' This is a specific verb ('search') and resource ('papers in ArXiv'), and it distinguishes the tool from sibling search tools (e.g., pubmed_paper_search_by_query) by explicitly naming ArXiv. It also contrasts with arxiv_paper_detail_by_id, which is for detail retrieval by ID, and arxiv_latest_paper_list_by_category, which is category-based listing.

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 concrete usage guidance: it explains that the query is passed verbatim to arXiv and that field prefixes (ti:, au:, abs:, cat:) can be used to pinpoint a specific paper. It also warns that a bare title is a loose full-text query and may not reliably return the paper. This is helpful for an agent to decide how to construct queries. However, it does not explicitly compare to alternative search tools (e.g., when to use this vs. a Scopus query) or state when not to use this tool, so it falls short of full 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that include_stats and include_outputs each add an extra upstream request (performance cost) and are off by default, and it explains the best-effort sub-resource behavior: a sub-resource failure keeps ok=True and reports the error under the sub-key. These are concrete, non-obvious behavioral traits beyond the schema.

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

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

The description is three focused paragraphs: purpose, id sourcing/flag guidance, and error handling. Every sentence adds value, is front-loaded with the core purpose, and avoids redundancy. It is efficiently structured and easy to parse.

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 fetch-by-id tool with no output schema, the description covers the essential operational details: how to get the id, when to use the optional flags, and how failures are handled. There is no missing information an agent would need to call it correctly, and the error semantics are fully specified.

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

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

Schema description coverage is 0%, so the description must compensate. It explains provider_id as a numeric id and tells where to find it, and it explains include_stats and include_outputs in terms of their cost and default state. This adds meaning beyond the bare type information, covering all three parameters.

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 the verb 'Fetch' and the specific resource 'one CORE data provider' identified by numeric id. It distinguishes itself from sibling search tools by focusing on a single provider and explains how to obtain the id, making the tool's purpose unambiguous.

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

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

It explicitly instructs how to get the provider_id from core_data_provider_search_by_query or from a work record's data_providers field, establishing when this tool is appropriate. It also advises enabling include_stats and include_outputs only when needed, which is practical guidance. It doesn't explicitly exclude alternatives, but the context is clear.

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?

No annotations are present, so the description carries the behavioral burden. It usefully discloses a max_results cap of 200 and describes the shape of returned items as repository/journal sources rather than papers. However, it does not mention pagination, sorting, query syntax, authentication, or rate limits, which keeps this at a modest score.

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

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

The description is front-loaded with the core purpose, followed by item-shape clarification, downstream routing, and the max_results cap. Each sentence earns its place, but the long parenthetical about the buildlog verification is slightly more verbose than necessary.

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 no output schema and no annotations, the description covers the essential semantics: what is searched, what returned items look like, how to use the returned id, and the max_results limit. Minor gaps remain around pagination and exact query syntax, but it is adequate for tool selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It says query searches provider records and that max_results is capped at 200, with 50/100/200 explicitly accepted. This gives an agent enough to invoke both parameters correctly, even though query syntax details are not provided.

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 operation: searching CORE's data providers, specifically institutional repositories and journal sources. Explicitly says each item is not a paper, which distinguishes it from core_work_search_by_query and other literature-search siblings. Also names the downstream detail tool that consumes the returned id.

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

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

Gives clear routing context: take an id from this tool into core_data_provider_detail_by_id, or find provider ids via data_providers in core_work_detail_by_identifier/search results. It doesn't enumerate when-not-to-use cases, but the 'not a paper' framing and downstream references make the intended usage clear.

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?

No annotations are present, so the description carries the full burden. It clearly identifies the operation as a read-only 'Fetch', states that it returns a single item, explains the raw/de-duplicated nature of an output, and documents the numeric id requirement. It does not mention authentication, rate limits, or error behavior, but those are less critical for a simple lookup and the core behavior is transparent.

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

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

The description is front-loaded with the core purpose and then efficiently builds context: output-vs-work distinction, usage criteria, and id constraint. Every sentence adds actionable information; there is no filler or 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 one-parameter detail lookup with no output schema, the description is complete: it defines the resource, gives the selection criteria, names the alternative tool, specifies the required id type, and indicates a single-item return with useful example fields. Nothing essential is missing for correct invocation.

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

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

The input schema only provides `output_id` as a string with 0% description coverage, so the description must compensate. It does by explaining that `output_id` must be numeric and that it identifies a CORE output record. It could be more explicit about the exact integer format or how to obtain the id, but the essential semantic is clear.

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, resource, and access path: 'Fetch one raw CORE harvesting record (`output`) by numeric id.' It goes further to distinguish `output` from `work`, and names the sibling tool `core_work_detail_by_identifier` for the merged record, so an agent can tell this tool apart from related search/detail tools.

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

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

The description explicitly says to call this tool when per-repository detail is needed, provides concrete fields (`license`, `repositories`, `sdg`, `fulltext_status`, `source_fulltext_urls`), and directs users to the works tools for the paper-level record. This gives clear when-to-use and when-not-to-use 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?

With no annotations, the description carries the full burden and exceeds expectations. It discloses that outputs are not de-duplicated, that the same paper can appear multiple times, that upstream may return HTTP 500 for some query expressions (and that this server does not retry), that `max_results` is capped at 100, and that upstream `fullText` is stripped from the returned items. This gives an agent an accurate behavioral model.

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 longer than typical but every sentence earns its place: purpose, differentiation, usage guidance, error behavior, and result-shape notes. The most important scoping point ('outputs', not de-duplicated) is front-loaded, and the separation into paragraphs aids scanning without 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?

Given the tool's complexity (duplication semantics, upstream instability, result trimming) and the absence of annotations and an output schema, the description is remarkably complete. It explains the resource type, the difference from works tools, query syntax, error behavior, result content, and limits—everything an agent needs to invoke the tool correctly and interpret its outcome.

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

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

Schema description coverage is 0%, so the description must compensate and does. For `query`, it explains that CORE's own syntax is accepted and recommends field-qualified forms with concrete examples (`title:"..."`, `doi:"..."`), plus warns about problematic expressions. For `max_results`, it states the hard cap of 100. This adds meaningful semantics beyond the bare schema types.

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 CORE's raw harvesting records (`outputs`, not de-duplicated).' It also distinguishes itself from the sibling `core_work_search_by_query` by explaining the conceptual difference between `output` and `work`, making it immediately clear what this tool does and how it differs.

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

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

Explicitly states when to use this tool: 'Use this tool to find a specific repository's copy of a paper and inspect its `license` / `fulltext_status` / `repositories`; use the works tools for the paper itself.' Also recommends field-qualified query forms and warns against certain expressions, providing clear guidance on how to invoke it 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?

With zero annotations, the description carries the full behavioral burden and succeeds admirably. It discloses the counterintuitive response semantics ('count in the response is therefore the number of *dimensions* returned, not the number of papers'), the truncation behavior (top_n default 10, capped 50), the verbatim casing behavior (snake_case defaults vs camelCase explicit, both returned as-is), the upstream 100-bucket cap on total_buckets, and the token-cost impact. This is thorough behavioral disclosure that would prevent real mis-invocations.

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

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

Four tight paragraphs, each earning its place: one-line purpose, the critical facet-vs-list disambiguation, response and truncation semantics, parameter semantics, and a closing usage-cost warning. There is no filler or redundancy; the density is justified because schema coverage is 0% and there is no output schema, so the confusing points (count meaning, casing, caps) all need explanation.

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

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

Given 0% schema coverage, no annotations, and no output schema, the description is responsible for explaining parameters, return semantics, and safety/behavior — and it covers all of them. It explains the response shape, the meaning of top-level count, the bucket cap, and the cost profile. An agent reading this description can invoke the tool correctly and interpret its results without additional lookups.

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

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

Schema description coverage is 0%, so the description must compensate fully, and it does. It explains all three parameters: query syntax (deferred explicitly to the sibling), top_n (default 10, cap 50, what it truncates), and fields (optional, with concrete camelCase examples `["yearPublished", "authors", "publisher"]`, plus the verbatim casing and naming caveat). This exceeds what the bare schema provides and includes the semantic traps an agent would otherwise hit.

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

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

The first line names a specific verb and resource ('Summarise the distribution of CORE works matching a keyword query') and the second paragraph immediately disambiguates it from the sibling search tool: 'This is a facet/distribution view, NOT a result list.' This explicitly distinguishes it from core_work_search_by_query and the other search tools in the sibling list, leaving no ambiguity about what it returns.

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 final paragraph gives explicit when/when-not guidance: 'Aggregation queries cost more tokens than a plain search upstream; call it when you actually need a distribution, not after every search.' It also routes the agent to the correct alternative by declaring that 'query uses the same syntax as core_work_search_by_query,' and tells the agent when to leave fields unset versus pass explicit values.

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

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

With no annotations, the description must carry behavioral disclosure. It does: it warns about the DOI prefix returning 404, notes that outputs are URLs only (not expanded content), and clarifies that both identifier forms were verified. It does not mention rate limits or authentication, but for a read-only fetch this is acceptable. It also states the return shape ('returns a single item') and the extra fields present.

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 a compact paragraph where each sentence adds value: purpose, DOI format warning, verification note, field differences from search, output expansion pointer, and return shape. No filler or redundancy. It is well-structured with the purpose first and practical guidance following.

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 tool with no output schema, the description covers everything needed to call it correctly: identifier format, error behavior (404), what the response contains (single item, extra fields, outputs as URLs), and how to get expanded outputs. It also differentiates from siblings. 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 coverage is 0%, but the description fully explains the single parameter 'identifier'. It specifies the accepted forms (bare DOI or numeric CORE ID), gives a concrete example (10.1038/nature12373), and explicitly warns against the 'doi:' prefix. This goes far beyond the schema's bare 'string' type, making the parameter semantics crystal clear.

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

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

The description opens with a precise verb-resource pair: 'Fetch the full CORE record of one work by bare DOI or numeric CORE ID.' It also distinguishes itself from sibling search tools by noting the detail record includes dataProviders/outputs/identifiers that keyword search results do not include, and it states it returns a single item. This is unambiguous and clearly differentiates from core_work_search_by_query and core_work_outputs_by_id.

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 actionable usage guidance: it warns about the DOI prefix (doi:) causing a 404 and instructs to call core_work_outputs_by_id when outputs need expansion. It implies when to use this tool instead of search (when you need full record fields) but does not explicitly enumerate all alternatives. Still, the context is clear and helpful.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains that each item is a de-duplication *source record*, not the paper text, and lists the meaningful fields (download_url, license, fulltext_status, data_provider). It also discloses the 404 rejection for DOIs, which is a behavioral trait an agent needs to handle gracefully.

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

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

The description is compact and front-loaded: the purpose is stated in the first sentence, followed by the critical constraint and a usage alternative. Every sentence adds value, with no redundant or filler content.

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 tool with no output schema, this description is complete. It covers the input format, error behavior, and the nature of the response items, giving an agent everything needed to invoke and interpret the result correctly.

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

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

Schema description coverage is 0% and the schema only labels the parameter as 'Identifier' with type string. The description compensates fully by specifying that identifier must be a numeric CORE ID, providing an example, and clarifying that DOIs are invalid. This is essential semantic information the schema omits.

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

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

The description opens with a specific verb and resource: 'List the per-repository copies (`outputs`) CORE harvested for one work.' This clearly distinguishes it from sibling tools like core_work_detail_by_identifier (which returns work metadata) and core_output_search_by_query (which searches outputs across works).

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

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

It gives explicit, actionable guidance: identifier MUST be a numeric CORE ID, DOIs are rejected with a 404, and if only a DOI is available, it directs the agent to call core_work_detail_by_identifier first and extract the numeric id. This is a textbook example of when-to-use and when-not-to-use guidance with a named alternative.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses that only metadata and download links are returned, the fullText field is explicitly excluded, API key behavior and token/rate limits are described, and payload size/performance caveats are given. This goes well beyond basic disclosure, though it doesn't explicitly say 'read-only' or describe all possible response edge cases.

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

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

The description is dense but every sentence provides operational value: purpose first, then query syntax, then limits/performance, then authentication/rate limits. It is not overly verbose, but the backtick-dense query syntax section could be slightly more compact. Overall a well-structured, front-loaded 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?

Given the tool has 3 params, no output schema, and no annotations, the description covers the essential operational context: return type (metadata and download links), query syntax, limits, performance, and auth. It does not describe the exact output structure, but it gives a sufficient high-level view for correct invocation. The sibling context includes many similar search tools, and this description makes the tool's role clear enough.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is explained: query uses CORE's syntax with examples, max_results has a cap and default, offset controls paging. It also provides practical guidance on when to adjust defaults, giving the agent clear semantic understanding 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 uses a specific verb ('Search') and resource ('CORE'), clearly identifying it as a keyword search tool. It distinguishes from sibling tools for other databases but does not explicitly differentiate from other CORE search tools like core_work_aggregate_by_query or core_output_search_by_query, so it is not a full 5.

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

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

It describes how to use the tool (query syntax, paging, max limit) and includes practical performance/limit warnings, but it does not state when to choose this tool over alternatives or mention exclusions. The usage context is implied by the description, but explicit comparison to sibling tools is absent.

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?

No annotations are provided, so the description carries the full burden — and it discloses the key behavioral trait: it returns a single item containing only timestamp fields, with the rationale that this is all the upstream returns. It also notes the identifier flexibility was verified. It doesn't cover error/edge-case behavior for invalid identifiers, but for a simple fetch the return-shape transparency is strong.

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

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

Three tight sentences with the purpose front-loaded. The buildlog reference ('verified in buildlog step 69's F9/F9b') is a slightly tangential artifact for an agent but adds trust signal and is not harmful. No wasted words otherwise.

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?

Complete for a simple single-parameter fetch tool with no output schema and no annotations. It covers purpose, the returned fields, parameter accepted formats, the single-item return shape (substituting for a missing output schema), and differentiates from its sibling. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that the sole identifier parameter accepts either a bare DOI or a numeric CORE ID. This adds real meaning beyond the schema's bare 'string' type. It could specify DOI prefix requirements, but the core semantics are well covered.

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 ('Fetch') plus a precise resource ('lifecycle timestamps of one CORE work') and enumerates the exact fields returned (deposited / published / updated / accepted). It also explicitly contrasts with the sibling core_work_outputs_by_id, so an agent can distinguish them without opening either schema.

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

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

Names the sibling alternative (core_work_outputs_by_id) and gives the exact selection condition — this endpoint accepts a bare DOI and does NOT require a numeric id, unlike the alternative. This gives the agent an explicit when-to-use-this vs when-to-use-that rule.

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

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

With no annotations present, the description carries the behavioral disclosure burden. It adds one useful fact—no API key is needed—and implies a read-only, single-object retrieval, but it does not mention error handling, response format, or any limits. This is adequate but has clear gaps.

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 a single front-loaded sentence: it states the action and object first, then adds a useful prerequisite ('No API key needed'). There is no filler or redundant 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?

For a one-parameter lookup with no annotations and no output schema, the description is nearly sufficient for basic invocation: an agent knows what to call and that no key is required. But it omits expected return shape, DOI format guidance, and behavior for invalid or missing DOIs, leaving modest gaps.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented DOI parameter. It only restates 'by DOI' without providing a format, example, or validation hint beyond the property name already in the schema. The added semantic value is minimal.

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 the operation ('Look up'), the resource ('a single work'), the source ('Crossref'), and the lookup key ('DOI'). This distinguishes it from sibling tools like crossref_work_search_by_query, which searches by query rather than by a specific identifier.

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 'single work ... by DOI' implies the tool should be used when the agent already has a DOI and needs that specific work. However, the description does not explicitly mention alternatives, when not to use it, or how it differs from other detail/lookup siblings, so usage guidance is only implied.

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

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

With no annotations, the description must carry behavioral disclosure. It usefully states that no API key is needed and implies a read-only search, but it omits rate limits, result limits, pagination, and query-matching behavior. The added auth note provides some value, but the description remains thin on behavior.

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

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

The description is two concise sentences with no filler. The primary purpose is stated first, and the auth note adds useful context without bloating the text.

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

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

The tool is simple, with only two parameters and no nested objects, so the description is minimally viable. However, it does not explain max_results behavior or what kind of results the agent should expect, and there is no output schema to compensate for that gap.

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

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

Schema description coverage is 0%, so the description should compensate. 'By keyword' gives meaning to the query parameter, but max_results is entirely unaddressed beyond its raw schema definition, leaving its semantics and effect on the call undocumented.

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

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

The description states a specific action ('Search'), resource ('Crossref works'), and scope ('by keyword'), which clearly differentiates it from sibling search tools across other providers like scopus_document_search_by_query and from crossref_work_detail_by_doi. The audience 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?

No guidance is given on when to choose Crossref over the many sibling search tools, nor when keyword search is appropriate versus detail lookup. 'No API key needed' is an access benefit, not a usage rule, and no alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add the useful note 'No API key needed,' but it omits other behavioral aspects such as read-only nature, return format, pagination, or rate limits. This is minimal disclosure for an unannotated tool.

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

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

The description is a single, concise sentence that front-loads the primary purpose and includes a key operational detail (no API key). It contains no fluff or redundancy, achieving excellent conciseness.

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 search tool with no output schema and no annotations, the description lacks critical details such as return format, pagination behavior, sorting, or any limits. It is too sparse for an agent to reliably understand the full behavior and expected results.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only implicitly explains the 'query' parameter via 'by keyword,' but it does not explain 'max_results' beyond what the schema's name and default suggest. This is inadequate compensation for two parameters.

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 the tool's function: 'Search DOAJ ... for open-access articles by keyword.' It specifies a specific verb (search), resource (DOAJ), and object (open-access articles), which unambiguously distinguishes it from sibling tools that target other databases like Scopus, PubMed, or arXiv.

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

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

The description implies usage for finding open-access articles in DOAJ, but it does not explicitly compare with alternative search tools or state when not to use it. There is no guidance on selecting this tool over others, though the database name itself provides some 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?

With no annotations provided, the description carries the full burden and does well: it discloses that only the first page of results is returned, that ordering is by Europe PMC relevance ranking, and that no API key is needed. It does not explicitly state read-only behavior, but 'Search' implies no side effects, and these details are genuinely useful.

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

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

Three sentences, each carrying distinct information: the source and distinctness, the first-page and ordering behavior, and the auth requirement. No filler, front-loaded with the core purpose.

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 search tool with no annotations and no output schema, the description covers source, pagination, ordering, and auth. It is ambiguous about the relationship between max_results and 'first page', and it omits any details about the returned result format, but for a keyword search with two parameters, this is reasonably 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 0%, so the description must compensate for the two parameters. It only mentions 'by keyword', which maps to the query parameter, but says nothing about max_results semantics, query syntax, or how pagination interacts with max_results. This is a significant gap.

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

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

The description clearly identifies the tool as a keyword search over Europe PMC, specifies the resource aggregator (EBI's life-sciences aggregator), and explicitly distinguishes it from NCBI PubMed. This allows an agent to immediately tell it apart from the many sibling search tools.

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

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

The description gives clear context that this is for Europe PMC literature, and it explicitly notes it is distinct from PubMed, which helps direct an agent away from the PubMed tool. However, it does not name alternative sibling tools or provide explicit when-to-use/not-to-use rules beyond that one distinction.

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

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

With no annotations, the description carries the transparency burden and does meaningful work: it states no API key is required, flags a known intermittent HTTP 403, and advises that a network error may not be a tool bug. It omits obvious read-only/rate-limit details, but the operational caveat is valuable.

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 three short sentences, each adding distinct value: core purpose, authentication requirement, and known-error caveat. 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?

For a simple 2-parameter search tool, it covers purpose, auth, and error behavior, but it leaves gaps: no statement of return shape, no guidance on result limits, and no sibling comparison. It is adequate but not fully self-contained.

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

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

Schema description coverage is 0%, so the description must define both parameters. It provides only the phrase 'by keyword,' which maps to query, but says nothing about max_results' semantics, limits, or behavior. The parameter names are self-explanatory, but the description does not compensate for the missing schema documentation.

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

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

The description opens with a specific verb and resource: 'Search OpenAIRE (European open science aggregator) for research products by keyword.' It is clear what the tool searches over, but it does not explicitly distinguish itself from sibling search-by-query tools from other providers, so it falls just short of full 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?

No guidance is provided about when to choose this tool over sibling aggregator searches (Scopus, arXiv, CORE, etc.). The description only implies usage by keyword and notes API-key-free access; there are no exclusions, prerequisites, or alternative 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?

No annotations are provided, so the description carries the disclosure burden. It transparently explains that the tool queries NCBI Entrez, retrieves XML, and normalizes records, and it exposes the surprising behavior where quoted title tags cause zero results. It does not mention rate limits, authentication needs, or failure modes, but for a read-only search tool the disclosed behavior is substantial.

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 well-structured: the first sentence states the core purpose and pipeline, the second lists output fields, and a focused final paragraph gives a practical query-formatting caveat with an example. Every sentence adds useful information with no filler.

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

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

Given there is no output schema and no annotations, the description is largely self-sufficient: it explains the workflow, return fields, query syntax, and a key pitfall. The main omission is the effect/limits of `max_results`, and it does not discuss error conditions, but the essential information for calling the tool correctly is present.

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

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

With 0% schema description coverage, the description must compensate for both parameters. It thoroughly explains `query`: verbatim passing, field tags, MeSH terms, and the title-tag warning. However, `max_results` is never mentioned in the description; only its default value appears in the schema, so the description only partially compensates for the schema's lack of parameter documentation.

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

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

The description opens with a specific action and resource: 'Search PubMed by keyword via NCBI Entrez'. It also clarifies the internal pipeline (ESearch then EFetch) and the normalized output fields, which clearly distinguishes it from sibling tools that retrieve by ID or look up related articles.

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

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

The description gives concrete usage guidance for a common case: how to pin down a known paper using the `[Title]` tag without quotes, and warns against a quoting pitfall that returns zero results. However, it does not explicitly contrast this tool with sibling PubMed tools (e.g., summary lookup or related-article search) or state when not to use it.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses error handling (invalid PMIDs returned as per-item error fields), the batch limit (max 200, excess truncated), and performance characteristics (faster than a full fetch). It also lists the additional fields it provides.

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 concise (two sentences) and front-loaded with the core purpose, then adds behavioral details. No filler or 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 single-parameter lookup tool with no output schema, the description covers all essential aspects: purpose, performance, fields included, error behavior, and input limits. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the pmids parameter is a batch, enforces a maximum of 200 with truncation, and explains how invalid IDs are handled. This adds meaning beyond the bare array-of-strings schema.

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

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

The description clearly states the action ('Look up lightweight PubMed metadata') and the resource (batch of PMIDs via ESummary). It explicitly differentiates from the search tool by mentioning fields it lacks (pmcid, pubstatus, pmcrefcount, elocationid), making its role unambiguous among the sibling tools.

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

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

It provides clear context for when to use this tool: when you have PMIDs and need lightweight metadata, especially fields the search tool lacks, and it notes it's faster than a full fetch. However, it does not explicitly name alternative tools or state when not to use it, though the mention of 'the search tool' implies the distinction.

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

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

With no annotations, the description carries the disclosure burden. It signals a non-destructive 'look up', explains the two result groups are deliberately separated, and explicitly says both empty is normal rather than an error. It doesn't mention auth, rate limits, or output pagination, but these are not critical for a simple lookup.

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

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

Three compact sentences: purpose, return groups with inline clarification, and empty-result handling. No filler; the important disambiguation 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?

For a one-parameter lookup with no output schema, the description covers the main result groups and tells the agent that empty results are valid. It stays short of specifying exact response fields or parameter formatting, but the core invocation semantics are present.

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

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

The only parameter, `pmid`, is self-explanatory and the description reinforces it as the article identifier. However, schema_description_coverage is 0%, and the text gives no format/example (e.g., numeric string) or constraints, so it only partially compensates.

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

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

The description uses a specific verb ('look up') and resource ('PubMed Central linkages'), then disambiguates the meaning with two named return groups ('own_pmc_fulltext', 'cited_by_pmc_articles'). This makes it clearly distinct from sibling search/summary tools even without naming them.

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

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

The usage is implied by the output description: an agent would call this when it needs PMC full-text availability and citing articles for a PMID. But it never states when to choose this over pubmed_related_article_search_by_pmid or pubmed_paper_summary_lookup_by_pmids, nor provides 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?

With no annotations, the description carries the full burden. It discloses that the source PMID is excluded, that results are ranked by relevance, and that the underlying service is NCBI ELink. It does not mention error behavior, rate limits, or how max_results affects the response, which are important for a read-only network call. The provided details are useful but not exhaustive.

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

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

The two-sentence description is tightly written with no filler. The first sentence front-loads the core purpose and the second sentence adds a practical follow-up instruction. Every clause contributes value, matching the conciseness ideal.

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

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

Given the simple 2-parameter interface and no output schema, the description explains the return value (list of PMIDs, source excluded) and suggests a follow-up, which is helpful. Yet it omits the semantics of max_results and does not cover potential edge cases like invalid PMIDs or empty result sets, leaving a meaningful gap for an agent that must invoke the tool autonomously.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It makes no mention of max_results' meaning or default (10) beyond the schema default, and it only implicitly ties pmid to the primary input. The description's 'related PMIDs' phrasing hints at the output but does not clarify parameter semantics, leaving an agent with inferential gaps.

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

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

The description clearly states a specific action ('find PubMed articles topically related to a given PMID') and the underlying ELink mechanism, which distinguishes it from search-by-query tools. It also clarifies that the output is a list of related PMIDs, not full records, and suggests a follow-up tool. However, it does not explicitly contrast with pubmed_paper_search_by_query, so an agent must infer the intended use case from the PMID-based input.

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 when you already have a known PMID and want similar articles, and it gives an actionable next step ('Call pubmed_paper_summary_lookup_by_pmids'). It does not explicitly state when to avoid this tool or when to prefer a sibling like pubmed_paper_search_by_query, leaving some inference to the agent.

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

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

With no annotations present, the description carries the full burden of behavior disclosure. It transparently states that the tool does NOT download binary content and only returns metadata plus download links. It could add error/auth/pagination details, but the core behavioral boundary is clear.

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

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

Three short sentences, each earning its place. The purpose is front-loaded, the download limitation is stated immediately, and the identifier-type guidance is compact and useful. No redundant or vague wording.

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

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

The description is adequate for a simple metadata-list tool: it names what is returned, what is not returned, and which identifier types are likely to work. The missing treatment of the view parameter and lack of error or pagination details are minor gaps given the tool's simplicity.

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

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

The input schema provides no descriptions (0% coverage), so the description must compensate. It adds concrete, actionable semantics for identifier_type: doi or pii are verified working, while scopus_id/pubmed_id may also work. The identifier parameter is self-explanatory, but the view parameter remains unexplained, preventing a perfect score.

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

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

The description uses a specific verb ('Get metadata') and names the exact resource: figures/tables/supplementary materials attached to an article. It also lists the returned fields (filename, mimetype, type, download link) and explicitly distinguishes itself from binary download, which differentiates it from the sibling retrieval tool.

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

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

The description clearly scopes when the tool should be used: when you need metadata and download links for attached objects, not when you need the binary content itself. It does not explicitly name an alternative tool such as sciencedirect_article_retrieve_by_identifier, so the guidance is mostly implicit rather than fully prescriptive.

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

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

With no annotations, the description carries the behavioral burden and does it well: it discloses the default view (META), that it is unrestricted, and that full-text body only appears under entitlement-gated views. It also clarifies that the output is a normalized record with specific fields. This goes beyond what the schema reveals and is directly relevant to call expectations.

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

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

Two sentences with zero filler. The main purpose is front-loaded, and the view-related nuance occupies the second sentence. Every clause adds context about what the tool returns and how access is gated.

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

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

The tool has no output schema and no annotations, so the description is the only source of expectations. It lists the record contents and the META/full-text gating, which is good. But it lacks error behavior (e.g., not found), any request details like required authentication or rate limits, and does not contrast with the similarly named sibling sciencedirect_article_object_by_identifier, so an agent might not know which to pick.

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

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

Schema coverage is 0%, so the description must clarify parameters. It does add meaning by listing valid identifier_type values (pii, doi, pubmed_id, eid) and explaining the view default and gating. However, it does not specify the exact format for the identifier value (e.g., DOI format) nor enumerate possible view values beyond META, leaving ambiguity for a parameter with no enums.

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: 'Retrieve an article record by identifier type... and value.' It names the identifier types (pii, doi, pubmed_id, eid) and lists the return fields (title, authors, journal, identifiers, subjects). It does not explicitly differentiate from the sibling sciencedirect_article_object_by_identifier, but the core purpose 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?

No guidance on when to use this tool versus the many sibling retrieve/search tools. The only contextual hint is about view restrictions (META vs entitlement-gated), which is about behavior, not tool selection. The agent must infer when to prefer this over sciencedirect_article_object_by_identifier or scopus_abstract_detail_by_eid from the 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?

With no annotations, the description carries the full burden. It discloses the default view (META) and that the abstract body is only available under richer views subject to subscription. This is useful behavioral context, though it does not address potential errors, authentication, or the exact output structure beyond listing fields.

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

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

Two sentences with no filler. The purpose is front-loaded, and the view/subscription nuance is stated clearly. Every sentence adds value.

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

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

The description covers the main purpose, the view behavior, and the subscription dependency. However, it lacks error handling guidance, exact parameter values, and any mention of authentication or rate limits. Given the tool's moderate complexity and absence of annotations, it is reasonably complete but not exhaustive.

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

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

Schema coverage is 0%, so the description must compensate. It mentions the view concept ('Default view is META... richer views such as FULL/META_ABS') but does not explicitly document the parameters or their allowed values. The eid parameter is only inferred from the tool name and the phrase 'by EID', and no details are given about its format or constraints.

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 clear verb ('Get') and a specific resource ('Scopus document by EID'), and enumerates the returned fields. It distinguishes this tool from siblings like scopus_document_search_by_query by focusing on retrieval by EID rather than search.

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

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

The description implies usage when an EID is already known, but it does not explicitly mention alternatives or when not to use it. It lacks direct guidance on when to prefer a search or other Scopus tools, so usage context is only implied.

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

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

No annotations are provided, so the description carries the full burden. 'Check' implies a read-only, non-destructive operation, which is a useful behavioral signal. However, it does not disclose whether the call itself counts against rate limits, whether authentication is required, or what fields the status response contains. Core behavior is clear, but higher-level transparency is missing.

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

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

A single, front-loaded sentence with no filler. It states the action, target, and endpoint efficiently. Every word 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 zero-parameter status-check tool, the description identifies the resource and action. However, with no output schema and no annotations, an agent is left without any indication of the response shape (e.g., whether it returns raw HTTP headers, JSON fields, or error details). This is a minor gap but could affect how the agent interprets the tool's output.

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

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

The tool has zero parameters, so the baseline is 4. There is no parameter semantics burden on the description, and the schema correctly reflects an empty parameter object.

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

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

The description uses a specific verb ('Check') with a clear resource ('Elsevier API usage/rate-limit status') and scopes it via the Scopus endpoint. None of the sibling tools relate to usage status, so it is immediately distinguishable without needing to inspect schemas.

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

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

The description implies the intended use case: checking current rate-limit or usage status for the Elsevier/Scopus API. Since no sibling tool offers this capability, explicit exclusions or alternative routing are unnecessary. The context is clear, though it doesn't explicitly state when to use it (e.g., upon hitting rate limits).

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

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

With no annotations, the description carries full responsibility. It discloses key behavioral traits: query is passed verbatim, supports Scopus syntax, bare title behaves as loose keyword, and sort defaults to relevancy. Yet it omits other important behaviors such as pagination, rate limits, authentication requirements, or what the response contains. This is adequate but not comprehensive for a tool with no structured metadata.

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 short paragraphs, front-loaded with the primary purpose, followed by precise usage guidance. Every sentence adds value—no fluff. The examples are compact and directly illustrate the intended usage. This is exemplary conciseness.

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 no output schema, no annotations, and 0% schema coverage, the description needs to cover a lot. It does explain query handling and sort behavior, but leaves out other parameters (count, view), output format, error conditions, and any rate limits. For a search tool that could return large result sets, such details are important. The description is not complete enough for an agent to fully anticipate behavior without additional lookup.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains 'query' (verbatim, field syntax, bare-title behavior) and 'sort' (default relevancy, option for coverDate). It does not explain 'count' or 'view' parameters, which are left to the schema's generic names. Since it covers the two most critical parameters with rich detail and examples, it substantially adds value 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 explicitly states 'Search for documents in Scopus using a query string' with a specific verb and resource. It further differentiates by explaining Scopus's field syntax and giving concrete examples (TITLE, DOI, AUTHKEY), which clearly sets it apart from sibling search tools in other databases. This is unambiguous and actionable.

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

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

It provides clear usage guidance: use field syntax for precise single-paper lookup, and notes that a bare title yields loose keyword results. It also explains the default sort and how to change it. However, it does not explicitly mention when to avoid this tool or point to alternative sibling tools (e.g., crossref for DOI-based lookup), so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions the default view and a subscription-tier validation. It does not describe whether the operation is read-only, what happens for invalid or unknown ISSNs, how pagination or limits behave, or what the response structure looks like.

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 that are front-loaded with the tool's core purpose and then a short operational note. It is efficient and avoids filler, though the subscription-tier parenthetical is slightly niche.

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 tool with no output schema, no annotations, and 0% schema description coverage, the description is too thin. It does not cover the view parameter's options, ISSN formatting requirements, error behavior, or expected return shape beyond a high-level field list, leaving agents to guess at important call details.

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

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

Schema description coverage is 0%, so the description must compensate, but it only implicitly defines 'issn' as a lookup value and mentions the 'view' default without explaining allowed values or behavior. The listed metadata fields describe output, not parameter meaning, and the view parameter's semantics are left underspecified.

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 ('Get') and resource ('journal/serial metadata') with a clear lookup key ('by ISSN'), and lists the fields returned (title, publisher, Open Access status, coverage years, subject areas, homepage). This distinguishes it from the sibling scopus_serial_title_search_by_criteria, which searches by criteria rather than a specific ISSN.

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 alternatives like scopus_serial_title_search_by_criteria. The note about the default view working with a basic subscription tier is a minor operational hint, but it does not explain when to choose this tool over others or mention conditions like 'use when ISSN is known'.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the view-dependent subscription limitation ('ENHANCED/CITESCORE may require a higher subscription'), the maximum page size (max 200), page offset semantics, and the large-result warning for unfiltered queries. These go well beyond basic purpose and materially affect invocation.

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

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

The description is dense but every sentence earns its place. It front-loads the purpose and sibling distinction, then uses a compact labeled list for filters, and closes with a crucial usage warning. No filler or redundant restatement 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?

For a 10-parameter tool with no output schema and no annotations, this description is remarkably complete. It covers all filter semantics, allowed values, pagination, subscription constraints, and the large-result pitfall. It even tells the agent what the return contains: a list with SNIP/SJR metrics.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains every field: title as substring match, subj as subject abbreviation not numeric code, content with allowed values, oa with allowed values, start as page offset, count page size max 200, and view with subscription caveat. This adds significant meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Search journals/serials by multiple optional criteria (no ISSN required).' It explicitly contrasts itself with the sibling scopus_serial_title_by_issn, which looks up ONE journal by exact ISSN, making the search-by-criteria scope unmistakable.

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

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

It names the closest alternative, scopus_serial_title_by_issn, and states the deciding condition: one-journal-by-ISSN lookup vs. multi-journal list search. It also gives an explicit warning that passing no filter is allowed but browses all serials and will be huge, effectively telling the agent to supply at least one filter.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does disclose that scidir results include a parent_code for hierarchy while scopus results have null, which is useful. However, it does not mention output format, pagination, error behavior, or any side effects. For a lookup tool, this is moderate coverage.

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 concise, two sentences, with the purpose front-loaded and the parameter explanation in a compact list. Every sentence earns its place without redundant wording.

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 6 parameters, no output schema, and no annotations, the description covers the required parameter, optional filters, and the key behavioral difference between scopus and scidir. It doesn't describe the return structure, but for a lookup tool this may be acceptable. It is nearly complete for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It does this by listing optional filters (description, detail, code, abbrev, field) and clarifying that 'field restricts which fields are returned'. This gives enough semantic meaning to each parameter, though it lacks examples or format details. It compensates well for the schema gap.

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

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

The description clearly states a specific action ('look up'), a specific resource ('subject classification codes'), and its purpose ('to help build more precise search queries'). It also distinguishes the tool from siblings like document search or serial title lookups, so an agent can easily understand what this tool is for.

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 notes that `source` is required and must be either 'scopus' or 'scidir', which is a constraint. It also frames the tool's use as building search queries, but it does not explicitly state when to use this tool over alternatives (e.g., when you need classification codes vs. searching documents). The usage guidance is implied rather than explicit.

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