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

Annotations already cover readOnly/idempotent/openWorld, so the safety profile is set. The description adds non-obvious behavior beyond them: per-item failures are preserved rather than failing the whole call, progress is reported, and no durable background task is created despite async-sounding 'progress'.

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

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

Two tight sentences, front-loaded with the core action and capped by the most important caveat (no durable task). No filler.

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

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

An output schema exists, so return values need not be explained, and failure/progress semantics are covered. The main gap is silence on the format and providers parameters, which an agent must discover from the bare schema.

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

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

Schema coverage is 0%, so the description must compensate. It conveys the 20-identifier ceiling and order preservation, but says nothing about the 'format' enum (bibtex/ris/csl-json) or 'providers' selection, leaving two of three params semantically thin.

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 specific verbs (resolve, export) and the resource (identifiers→citations), plus a batch scope of up to 20. It is differentiable from single-item siblings like get-citation, though it doesn't name them explicitly.

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

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

The 'batch of up to 20' framing implies this is the multi-item counterpart to get-citation/enhance-citation, so batch usage is inferable. But there is no explicit when-to-use/when-not or named alternative, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds a genuine content-fidelity guarantee beyond the annotations: metadata is preserved and authors/awards/keywords are never fabricated. It stops short of describing normalization scope (e.g., field ordering, escaping) or input size limits.

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

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

Three short sentences, zero filler, with the core operation front-loaded and the limitation/alternative following in priority order. Every sentence carries distinct information.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Scope, constraints and the verify-citation handoff are present; the remaining hole is the unexplained 'template' option, which is the one thing an agent must decide before invoking.

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 description never mentions either parameter. The 'template' enum (default vs compact) and its formatting consequences are entirely unexplained, and the required 'bibtex' string's expected content/limits are left to inference. This is a clear case where the description should have compensated for the schema gap and did not.

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

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

The description gives a concrete verb+resource ('Normalize BibTeX formatting') and immediately bounds the operation ('while preserving supplied metadata'). It differentiates the tool from verify-citation by delegating fact-checking there. The only friction is the name 'enhance-citation' implying content addition, which the description partially counters with 'Does not invent authors, awards or keywords.'

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

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

It explicitly routes the agent to a sibling: 'Use verify-citation to check facts,' which is a clear when-not condition. It does not, however, state when to reach for enhance-citation over batch-citations or get-citation, so the routing is one-directional rather than a full alternative map.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive semantics, so the safety profile is covered. The description adds meaningful context beyond that: results are 'source-reported', Unpaywall enrichment is optional, and only links/licenses are returned with no full-text download.

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

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

Two sentences, front-loaded with the core action and followed by the two most decision-relevant constraints (enrichment optionality, no full-text downloads). No filler.

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

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

An output schema exists so return values need not be documented, and the annotations cover safety. However, for a tool whose only required input is an opaque 'identifier', the definition does not specify acceptable identifier forms or what 'providers' means, leaving a real gap for correct invocation.

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

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

Schema description coverage is 0% for two parameters. The description hints that Unpaywall enrichment is optional (pointing at 'providers') but never explains what identifier formats are accepted or what the providers list controls, leaving both parameters undocumented in structured data and prose.

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

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

States a specific verb ('Find') and resource ('source-reported open-access locations'), plus the distinctive behavior of returning links and licenses rather than full texts. It is clearly distinguishable from citation-centric siblings, though it never names an alternative 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 phrase 'without downloading full texts' implies the use case (locating OA copies rather than retrieving content), but there is no explicit when-to-use statement, no prerequisites, and no routing to siblings like resolve-paper or search-papers.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: required API keys (SERPAPI_API_KEY/SEARCHAPI_API_KEY), the paid-service cost model, and the critical caveat that the first result is not identity proof. That caveat is exactly the kind of reliability signal an agent needs.

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

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

Three compact sentences, each front-loaded with a distinct fact: capability/legacy status, return-shape caveat, and auth requirement. No filler.

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

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

An output schema exists, so return values need no explanation, and annotations plus the description cover safety, auth, and result trustworthiness. What remains missing is what the 'query' input should contain and how this differs concretely from sibling resolvers, which for a discovery tool is a real gap.

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

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

The single required parameter 'query' has 0% schema description coverage, and the description never explains what belongs in it (author name, paper title, affiliation). With one undocumented param, the definition does not compensate 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?

States a specific verb+resource: discovering Google Scholar cluster IDs, with the qualifier 'legacy' and the paid provider (SerpAPI/SearchApi). An agent can distinguish it from generic search siblings like search-papers or resolve-paper, though it never names an alternative directly.

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?

'Legacy' implies this is a fallback, which hints at when-not-to-use, but no sibling is named and no explicit condition selects this tool over find-open-access or resolve-paper. Usage must be inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds genuine value beyond that by disclosing 'deterministic' output, provenance inclusion, and missing-field warnings, which tell the agent what to expect in the response.

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

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

Two compact sentences that front-load the core resolve/export action before the legacy compatibility note. Every clause carries information; no filler.

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

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

An output schema exists, so return structure and missing-field warning format need not be restated. The description covers resolution, formats, and legacy input adequately; the only meaningful gap is the unexplained 'providers' parameter.

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

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

Schema description coverage is 0%, so the schema alone provides no parameter meaning. The description compensates for identifier (DOI/namespaced ID), format (three named encodings), and scholar_id (legacy), but says nothing about the 'providers' parameter, leaving one of four parameters unexplained.

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

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

The description states specific verbs and resources: 'Resolve a DOI or namespaced ID' and 'export ... BibTeX, RIS or CSL-JSON'. It clearly distinguishes this as a resolve-and-export tool, though it doesn't explicitly contrast with siblings like enhance-citation or verify-citation.

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

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

There is no explicit when-to-use guidance or named alternative among the ten siblings. Only the passing note that 'Legacy scholar_id remains accepted' hints at any invocation nuance, leaving the agent to infer when this tool is preferred over verify-citation or enhance-citation.

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

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

Annotations already declare the safe read-only profile (readOnlyHint, non-destructive, idempotent, closed-world). The description adds valuable context that it does not call vendors or expose secrets, which goes beyond the annotations and informs the agent about side effects and data sensitivity.

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

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

Two short, front-loaded sentences with zero waste. The first sentence clearly states what is listed; the second adds a useful safety caveat without verbosity.

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 parameters, a rich output schema, and full annotation coverage, the description provides sufficient context about what the tool returns and its safety. It could be stronger by indicating when to use it relative to siblings, but for a parameterless listing tool it is largely 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?

The tool takes zero parameters, so the baseline score of 4 applies. The schema is empty, and no additional parameter semantics are needed or expected.

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 'List' and enumerates the resources (sources, access tiers, availability, operations, setup variables). However, it does not explicitly differentiate from the paper-focused sibling tools, and omits the term 'providers' from the description, leaving a slight gap in mapping to the tool name.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The only sentence beyond the listing is a behavioral note ('Does not call vendors or expose secrets'), which does not help an agent decide between this and alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds useful context that results are observed provider counts rather than estimates, but says nothing about rate limits, provider-specific behavior, or partial failures.

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

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

Two compact sentences with zero filler. The core action and its scope boundary are front-loaded before the multi-provider tip.

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

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

An output schema exists, so return-value explanation isn't required. However, for a tool with two undocumented identifier parameters and no annotation-redundant guidance, the description leaves real gaps an agent must guess through.

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

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

Schema description coverage is 0% across three parameters. The description hints at the 'providers' parameter but leaves 'identifier' and 'scholar_id' entirely undocumented — including which one to use and whether either is required. Two of three params get no semantic help from either surface.

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 observed citation counts by provider and index.' The narrow scope ('never an estimated impact factor or sample length') further sharpens what this tool is and isn't. It does not explicitly name sibling tools like get-citation or batch-citations, so it falls short of a 5.

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

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

'Select multiple providers to compare coverage' implies the compare-use case, but there is no explicit when-to-use vs alternatives guidance (e.g., when to use this vs get-citation or batch-citations). Usage 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the provider backends supported and the hard constraint that offset must be a multiple of limit, which is the kind of operational rule annotations cannot express.

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

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

Three short sentences, front-loaded with the core action and zero filler. The provider list and offset rule are compactly stated rather than expounded.

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

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

An output schema exists, so return-value explanation is not required. The description covers direction, provider, and the offset constraint, but with 0% schema coverage the unaddressed identifier parameter and lack of pagination/termination guidance leave an agent under-informed for a 5-parameter tool.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It usefully clarifies direction values (citations vs references), enumerates provider options, and documents the offset/limit relationship, but leaves identifier entirely unspecified (format, which ID schemes are accepted).

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 (page through) and resource (citing papers or references in one provider's graph), which cleanly separates it from get-citation or search-papers. It does not name a sibling explicitly, so it lands just below the top tier.

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 establishes the context (paging citations/references within a single provider) and the provider set, but gives no when-to-use vs. alternatives guidance relative to siblings like get-citation or batch-citations. Usage is implied by the paging framing rather than stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered structurally. The description adds one behavioral note, 'validates returned identifiers', which is useful but left vague (what gets validated, what happens on failure), with no mention of auth or rate limits.

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

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

Two tight sentences with no filler; the input enumeration comes first and the routing hint second. Every clause earns its place.

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

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

An output schema exists, so return values need not be described. The identifier vocabulary is complete for the main input; the only gap is any explanation of the optional 'providers' parameter's effect on resolution behavior.

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% and there are two parameters. The description richly documents the accepted values for 'identifier' (DOI, arXiv ID, PMID, PMCID, OpenAlex, Semantic Scholar, Scholar, Scopus, WOS), which compensates well for the required param, but the 'providers' parameter is never mentioned and its purpose must be inferred.

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

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

Specific verb (resolve) plus an explicit enumeration of the identifier types accepted, so the agent knows exactly what inputs this tool consumes. It names search-papers as the tool for the adjacent case, giving partial sibling differentiation.

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

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

Gives a clear routing rule: use search-papers for titles, implying this tool is for known identifiers. No exclusions or preconditions for the resolve path itself are stated, so it stops short of full when/when-not coverage.

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

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

Adds substantial non-annotation context: concurrent querying, per-provider limit, pagination token usage, filters applying to fetched pages, partial failures remaining visible, and detail=compact omitting field_sources. Annotations cover read-only/idempotent safety, so this is rich supplementary 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?

Single dense paragraph front-loads purpose and defaults, then packs pagination, filter, failure, and detail guidance. Some terms like next_offsets assume output schema knowledge, but overall no wasted sentences.

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

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

For a 10-param, multi-provider search with output schema, the description covers key non-obvious behaviors and routing to resolve-paper. It omits explicit semantics for several filter/boolean params, though their names are suggestive, leaving minor 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% with 10 parameters, so the description must carry parameter meaning. It clarifies limit scope, detail behavior, and cursor/offset paging, but leaves providers, year_from, year_to, open_access_only, include_abstract, and query constraints unexplained. Partial compensation only.

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

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

States a specific verb 'Search' and resource 'scholarly sources', names default providers, and notes concurrent execution. It does not explicitly differentiate from sibling search tools like related-papers, but the core purpose is clear.

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

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

Explains pagination workflow (next_offsets vs next_cursors), notes limit is per provider, and directs to full or resolve-paper for field_sources. Lacks explicit when-not-to-use or broader alternatives beyond resolve-paper, but 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?

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context: title-only inputs yield ambiguous candidates, provider outages are not the same as missing records, and scientific claims are out of scope.

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

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

Four short sentences, front-loaded with the core operation and then progressively adding behavioral qualifiers. Every sentence adds distinct 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?

With rich annotations and an output schema present, the description does not need to explain safety or return values. It covers purpose, input modes, ambiguity, outages, and scope, though it leaves the optional 'providers' parameter undocumented.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'citation' can be an identifier or single BibTeX entry and that expected title/year are compared, but it says nothing about the optional 'providers' parameter or accepted formats.

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

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

The description gives a specific verb ('Verify') and resource ('identifier or single BibTeX entry') plus the comparison scope ('supplied title/year'). It also clarifies scope boundaries ('Does not validate scientific claims') so the agent can distinguish this from citation retrieval or enhancement 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 states input-mode behavior ('Title-only input returns ambiguous candidates') and operational distinctions ('Provider outages are distinct from missing records'), which help an agent set expectations. It lacks explicit when-to-use guidance versus sibling tools such as get-citation or enhance-citation.

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