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

The annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds behavior the agent cannot infer: identifiers fan out across three upstream sources, so large batches take a long time and return a job handle rather than records. It also discloses the OpenAlex fallback shape (same keys as S2 for the requested fields, with paperId null), which is exactly the kind of non-obvious result detail an agent needs.

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

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

The description is front-loaded with purpose and then layered with the fallback and job-handle behavior, so an agent can stop reading early if it only needs the basics. A few parentheticals repeat the schema's own examples (EP1234567A1, ISBN: prefix), which is mild redundancy rather than bloat.

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?

This is a moderately complex multi-source aggregator, and the description covers fallback behavior, identifier routing, and the async job-handle path, while an output schema handles return shapes. What's left out is when the batch flips from direct records to a job handle and how partial failures or unresolvable IDs surface.

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

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

Schema coverage is 100%, so the baseline would be 3; the description earns more by explaining the identifier grammar as a whole (auto-detected patents, ISBN: prefixes) and by clarifying that the fields preset applies only to paper results. It still doesn't say which fields each preset contains or what happens to unresolvable identifiers in the list.

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 ("Resolve a list of ... identifiers to full records") and names the entity types covered — papers, patents, books — which separates it from single-record siblings like get_paper or get_book. It also names get_job_result as the follow-up tool, so the agent can place this tool in the workflow without opening any schema.

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

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

The description gives concrete routing rules: plain or DOI-prefixed DOIs and S2 IDs go to the S2 batch endpoint with an OpenAlex fallback, patent numbers are auto-detected and sent to the EPO OPS API, and ISBN-prefixed values go to Open Library. It also says that large batches return a job handle to poll with get_job_result. It does not explicitly say when to prefer this over per-record calls such as get_paper for a single identifier, so the contrast is implied rather than stated.

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

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

Annotations already indicate read-only and non-destructive behavior; the description adds useful details about caching and background job handling. It does not disclose potential rate limits or failure modes, but 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?

Three concise sentences cover purpose, resolution, caching, and async behavior without redundancy. The structure is focused 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?

Given the output schema exists, the description adequately covers what the agent needs: input semantics, behavior, and async result retrieval. No critical context appears 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?

Both parameters are fully described in the schema, with identifier format and valid field options explicitly listed. The description reinforces identifier semantics by mentioning DOI resolution.

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

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

Clearly states the tool fetches OpenAlex metadata to supplement Semantic Scholar data, using a specific verb and resource. The distinction from siblings like get_paper and search_papers is evident through the OpenAlex enrichment focus.

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

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

Describes the enrichment purpose and the asynchronous behavior with get_job_result, giving practical usage context. It could more explicitly contrast with nearby tools like get_paper, but the enrichment scope is clear enough.

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

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

Annotations only establish that this is a safe read (readOnlyHint/destructiveHint false); the description adds the substantive behavior the agent cannot infer — asynchronous job-handle return, throttling deferral semantics, and partial-result handling with `partial`, `failed_requests`, and `warning` keys. It goes further to warn that a partial found:false is not proof of no path and a partial found:true path may not be shortest, which is exactly the kind of correctness caveat annotations cannot carry.

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

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

Purpose leads, then mechanism, then async behavior, then failure semantics — a sensible front-loaded progression where each paragraph earns its place. It is on the long side and the throttle paragraph is dense, but no sentence is filler.

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

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

For a long-running, potentially partial graph search, the description covers the async contract, throttling recovery, and degraded-result interpretation, and an output schema already exists to carry return shapes. An agent has everything needed to call it and to interpret what comes back.

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

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

Schema description coverage is 100% and every parameter (source_id, target_id, direction, max_depth) is documented inline with defaults and an enum. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource — 'Find the shortest citation path between two papers' — and immediately explains the mechanism (BFS over the citation/reference graph). This clearly separates it from single-hop siblings like get_citations and get_references and from get_citation_graph.

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 strong operational routing: the search 'commonly runs long and returns a job handle to poll with get_job_result rather than the path itself,' which tells the agent exactly what downstream call to make. It does not, however, explicitly contrast this tool with the closest alternative, get_citation_graph, leaving that choice 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?

Beyond the readOnly/openWorld/destructive annotations, the description discloses non-obvious behavior: papers are resolved through Semantic Scholar with optional OpenAlex enrichment, and critically that the response may be a job handle instead of citations for large batches. That polymorphic return is exactly the kind of trait an agent cannot infer from annotations or 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?

Four short sentences, front-loaded with purpose then output formats, then the async caveat. Nothing is padded and no sentence repeats structured data verbatim beyond naming the format set once.

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

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

An output schema exists and parameter coverage is complete, so the description needn't enumerate return fields. It covers the remaining critical gap (async job-handle responses) but does not state whether the job handle is returned above a specific size threshold, leaving the agent to discover the trigger empirically.

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

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

Schema coverage is 100%, so the schema already documents paper_ids, citation_format and the enrich default. The description adds indirect meaning by explaining that enrichment fans out per paper (i.e. the cost driver behind the enrich flag, which triggers OpenAlex calls when a DOI exists), but it never ties that explanation to the parameter name or the 100-item cap.

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 ("Generate formatted citations for one or more papers") and immediately names the output formats (BibTeX, CSL-JSON, RIS), which distinguishes it from sibling lookup tools like get_citations or get_references that return raw citing/cited records rather than formatted bibliography entries.

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 actionable runtime guidance: for large batches the call returns a job handle that must be polled with ``get_job_result`` rather than read directly. What it lacks is an explicit statement of when to prefer this tool over enrich_paper or get_citations for a single paper, so the routing against siblings is only partially covered.

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

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

Goes well beyond the readOnly/openWorld annotations: it discloses pagination semantics (limit/offset, next_offset presence), the caveat that Semantic Scholar may list fewer publications than paperCount so the last page can end short, and the long-running fallback that returns a job handle to poll with get_job_result. That last point is critical operational knowledge an agent could not infer from the annotations.

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

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

Front-loads the core behavior in the first line, then branches cleanly into direct-lookup and pagination detail. The paperCount caveat is slightly tangential but genuinely useful, so nothing is seriously wasteful.

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

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

An output schema exists so return values needn't be explained, and the description covers the remaining ambiguities: the two modes, candidate count, pagination, and the async job-handle fallback. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning by explaining that identifier's format determines which mode runs and that limit/offset apply only to direct ID lookup, reinforcing the intent behind the parameters rather than merely restating them.

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 (fetch author profile and publications) plus a second mode (search by name), and the opening sentence names the dual behavior so an agent can tell it apart from a pure search tool like search_papers.

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 the branch condition: numeric-looking identifier means direct ID lookup, otherwise a name search returning up to 5 candidates for disambiguation. It does not name sibling alternatives (e.g. resolve_standard_identifier for other ID types) to route to, which keeps it short of a 5.

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

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

Annotations already cover read-only/open-world/destructive flags, but the description adds the non-obvious operational trait that a rate-limited call may return a job handle rather than the record. That is genuinely new behavioral context; what's missing is any hint about how to tell the two response shapes apart.

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 purpose and followed by the single operational caveat worth knowing. Nothing is padded.

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

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

Return values are covered by the output schema, and the one surprising behavior (job-handle fallback) is disclosed. Slightly more detail on how to recognize a job-handle response versus a record would make it complete.

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

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

Schema description coverage is 100% and the schema already documents identifier forms, cover_size variants, and download_cover/cache behavior. The description adds nothing beyond it on parameters, so the baseline of 3 applies.

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

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

Names a specific verb and resource ("Fetch book metadata") and the accepted identifier schemes, which distinguishes it from search_books and get_book_excerpt. It stops short of explicitly naming the sibling used when no identifier is known.

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

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

The implicit precondition is clear (you must already hold an ISBN or Open Library ID), and the description explicitly names get_job_result as the alternative path when the call is throttled. No explicit exclusion such as "use search_books when you only have a title".

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

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description builds on that with genuinely new behavioral detail: the upstream API does not expose full chapter text, and the error taxonomy is split into terminal ('not_found') versus retryable ('rate_limited' with 'retryable', 'upstream_error'). This is exactly the retry/permission context an agent cannot get from structured fields.

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

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

The core capability is front-loaded in the first sentence, with the API limitation and error semantics following in descending priority. A few phrases are slightly padded ('A lookup that never got an answer says so instead'), but no sentence is filler.

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

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

Given a single-parameter, read-only lookup with an output schema, the description supplies the two things structure cannot: the ceiling on what data exists (no full text) and the recovery policy per error code. Nothing needed to call it correctly or interpret a failure is missing.

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

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

Schema coverage is 100% and the single 'isbn' parameter is documented as ISBN-10 or ISBN-13, so the schema carries the parameter burden. The description adds only indirect meaning by tying 'not_found' to a specific ISBN ('stop asking about that ISBN'), with no extra format, normalization, or hyphenation guidance.

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 ('Get a book excerpt and preview info from Google Books') and enumerates what comes back: publisher description, text snippet, and a preview link. It never names the sibling get_book or search_books, so an agent must infer that this tool is the excerpt/preview variant rather than the full metadata lookup.

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

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

Usage context is clear and actionable: it sets expectations that full chapter text is unavailable and explains exactly how to react to each failure mode ('not_found' means stop; 'rate_limited'/'upstream_error' are worth retrying). What it lacks is an explicit when-to-use-this-vs-get_book or search_books statement, so sibling selection is left to inference.

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

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

Far beyond the readOnly/openWorld annotations: it discloses one rate-limited request per node, job-handle-based returns, throttle resume behavior, and the crucial partial-vs-truncated distinction with stats.failed_requests and the warning key. It also warns that a throttled resume does not mark requests as partial, a non-obvious behavioral trait.

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?

Purpose is front-loaded, then cost, then failure modes in a sensible order, with no filler sentences. The poll-the-job-handle instruction is stated twice (throttle paragraph and cost paragraph), which is mild redundancy in an otherwise tight description.

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

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

Given an output schema exists, the description need not enumerate return fields, yet it still explains the two stats flags an agent must interpret to avoid treating missing edges as absent. Every operational risk for this read-only, open-world, potentially long-running traversal is covered.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning to *depth* and *max_nodes* by tying them to cost and truncation semantics rather than just numeric bounds. It does not add anything for direction or the year/citation filters, which the schema already covers.

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 sentence states a specific verb and resource ('Traverse the citation graph from one or more seed papers') and the second clarifies it is a BFS up to *depth* hops returning nodes and directed edges. That multi-hop framing implicitly separates it from single-hop siblings like get_citations and get_references, though no sibling is named 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?

It tells the agent that any non-shallow traversal runs long and should be polled via get_job_result rather than awaited, naming the alternative tool explicitly. It lacks an explicit 'use this instead of get_citations when...' contrast, which keeps it below a 5.

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

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

Adds real behavior beyond the readOnly/openWorld annotations: a hard 1000-result cap that silently truncates larger limit values, the escape hatch via offset, and the fact that deep min_citations paging escalates into a background job returning a handle for get_job_result. These are non-obvious async and truncation semantics an agent could not infer from annotations or 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?

Three short paragraphs, front-loaded with what the tool does, then limits, then the async escape hatch. Every sentence carries actionable information; no restatement of the title or 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 an 8-parameter paginated read tool with an output schema, the description covers the two things an agent must know to call it correctly: truncation/capping behavior and the background-job escalation path. Return value shape is handled by the output schema, so nothing material is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: that limit is capped at 1000 (schema says 'max 1000' but not that oversized values are silently clamped) and that offset is the paging mechanism for that cap and for filtered results. Other parameters (year_start, year_end, fields_of_study) are left entirely to the schema, which already documents them well.

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 ('Fetch papers that cite the given paper') and immediately disambiguates direction with '(forward citations)', which cleanly separates it from the sibling get_references (backward citations). No ambiguity about what is returned.

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 concrete operational guidance: page with offset past the 1000 cap, and poll get_job_result when a min_citations call continues in the background. It does not explicitly say when to prefer get_citation_graph or generate_citations instead, so the alternative-selection guidance is implicit rather than complete.

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

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

Adds material behavior beyond the readOnly/non-destructive/idempotent annotations: job records expire so results must be fetched promptly, status is tri-state, results can come back as either a payload or an error, and throttling defers work with a reason attached to the handle. The expiry warning is exactly the kind of non-obvious constraint 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?

Front-loaded with the core purpose, status values, and the expiry caveat before the supporting detail. The middle sentence enumerating specific slow operations (docling conversion, EPO traffic light, graph traversal) is somewhat long-winded, but each item justifies why a job handle exists rather than a result.

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

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

With an output schema present and 100% parameter coverage, the description only needs to supply the operational context, and it does: triggering conditions, status semantics, expiry, and inline fallback. The only minor gap is no guidance on polling cadence or backoff while a job is still 'working'.

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 job_id parameter is fully documented in the schema, and the description's framing ('a long-running tool returned when it continued in the background') largely restates it. The surrounding context about how job_id values originate from deferred or slow calls is mildly useful but does not add format or validation detail beyond the schema.

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

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

States a specific verb and resource ('Get the status of a background job') and immediately enumerates the observable outcomes (working, completed or failed, with result or error). This is distinguishable from every sibling tool, which are all paper/author/standard lookups rather than job-handle polling.

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 frames when this tool is the right call ('Those calls commonly answer with a job_id rather than a result') and when it is not needed ('a cache hit answers inline, with no job'). It also enumerates which upstream operations produce job handles (PDF download, docling conversion, EPO traffic light, citation formatting, graph traversal, throttling), which lets an agent recognize the trigger conditions.

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

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

Annotations only declare readOnly/openWorld/non-destructive; the description adds the non-obvious behavioral facts that a cached paper returns immediately, that a miss triggers a fetch-plus-enrichment, and that the response can be a job handle instead of the paper. That last point is a return-type surprise an agent could not infer from the safety hints alone, and it is disclosed with the follow-up tool named.

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, front-loaded with the operation, then the cached path, then the slow path and its escape hatch. Every sentence carries information the agent cannot get from structured fields.

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

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

An output schema exists, so return-value explanation is not needed, and the description covers the async branch and its polling tool. It falls slightly short on two points the agent would still want: what "enriched" entails and why that differs from the separate enrich_paper tool, and whether the background path eventually yields the same metadata the direct path would.

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

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

Schema description coverage is 100%, so the identifier parameter's accepted formats (DOI, S2, ARXIV:, ACM:, PMID:) are already documented in the schema. The description adds no format, casing, or resolution behavior beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ("Fetch full metadata") plus an explicit scope ("a single paper"), which cleanly separates it from search_papers, batch_resolve, and get_book in the sibling list. An agent can identify the operation without opening the schema.

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

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

The description routes the agent to get_job_result when the fetch runs long, which is genuine usage guidance for the async case. However, it gives no guidance for the primary case: nothing explains when to call this versus resolve_standard_identifier (which likely normalizes the same identifier formats) or enrich_paper (whose purpose overlaps with the "enriched" record mentioned here).

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 establish readOnly/openWorld/non-destructive, but the description adds genuinely new behavior: the hard 1000-result cap, the requirement to page with offset beyond that, and the fact that long calls fall back to an async job handle polled via get_job_result. That last detail is the kind of trait an agent cannot get from the schema or annotations alone.

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 paragraphs, front-loaded with the purpose, then limits, then the async behavior. Slight redundancy: 'Returns at most 1000 references per call; a larger limit is capped at 1000' repeats the same fact and echoes the schema's '(max 1000)'.

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

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

An output schema exists, so return values need no explanation, and the description covers the two non-obvious operational facts (cap/pagination and async job fallback). What remains unstated is how it differs from get_citation_graph for multi-hop traversal, a minor gap for a tool this simple.

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

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

Schema coverage is 100%, so all four parameters are already documented, including 'Max results (max 1000)'. The description restates the cap and mentions offset paging but adds little semantic detail beyond the schema — baseline 3 applies.

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

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

States a specific verb and resource — 'Fetch papers referenced by the given paper' — and the parenthetical '(backward references)' pins the direction, which is what separates it from get_citations. It stops short of naming the sibling outright, so the agent must infer the contrast rather than being told.

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

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

Usage is implied by direction: this is the backward-traversal tool versus get_citations' forward traversal. There is no explicit 'use this when...' statement and no guidance on when get_citation_graph or find_bridge_papers would be the better choice for graph-shaped questions.

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?

Consistent with readOnlyHint=true — it is a pure diagnostic read with no side effects. Beyond the annotation it discloses the return contents (server/client versions, supported protocol revisions, this connection's revision and client, upstream service version only when configured), which is the useful behavioral detail here.

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?

One sentence, front-loaded with the action and its subject, followed by the use condition. The middle enumeration of returned fields is dense but each item is informative rather than filler.

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

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

For a zero-parameter, read-only diagnostic with an output schema already present, nothing an agent needs is missing: it knows what the tool reports, the conditional nature of the upstream version, and when to call it.

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 applies; there is no input semantics to explain and the description correctly does not invent any.

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 ("Report the version information of scholar-mcp") and then enumerates exactly what comes back, so the agent can distinguish it from the retrieval/citation siblings without opening the schema.

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

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

Gives an explicit use condition: "when asked which version or build is running or which protocol revision is in use." No alternative tool is named, but none of the siblings overlaps with this capability, so there is nothing to disambiguate against.

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

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

Annotations only declare readOnlyHint, openWorldHint and destructiveHint=false; the description goes well beyond them by disclosing that docling conversion takes minutes and returns a pollable job handle, that failures still return the record with full_text_error and full_text_url, and that a missing full_text plus missing error means nothing was on offer. It also explains the per-revision cataloguing quirk that produces spurious not_found results.

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

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

Front-loaded with purpose and fuzzy resolution, then layered into conversion behavior, error taxonomy, and pagination — each block carries distinct operational value. It is long, and the fetch_full_text/docling conversion is introduced twice (once as capability, once as latency/job-handle consequence), which costs a point.

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 four-parameter tool with an output schema, this covers everything an agent needs: latency expectations, job-handle indirection, error classification, retry decisions, and multi-call pagination. Nothing about calling it correctly is left to inference.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns above that by tying parameters to behavior the schema cannot express: fetch_full_text changes the return shape (job handle vs record), text_offset pairs with the returned next_offset, and max_chars=null is only safe for clients that accept a whole document. The 20,000-character cap is restated from the schema, which is the only redundancy.

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 a standard by identifier") and immediately scopes the identifier domain to canonical-or-fuzzy. The mention of search_standards for revision enumeration separates it from the sibling search tool, so an agent can route 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?

Gives explicit routing rules: use get_job_result when fetch_full_text returns a job handle, use search_standards to find revisions, and use text_offset with next_offset for pagination. It also spells out retry policy per outcome — not_found is terminal, rate_limited and upstream_error are retryable — which is exactly the when/when-not guidance the dimension asks for.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: errors are non-fatal and empty on success, and runs is empty when no sync has ever run, which tells the agent how to interpret a blank result.

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 purpose before the return shape. Every clause carries information: the row fields, the meaning of errors, and the empty-state condition, 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?

For a zero-parameter read tool with an output schema, this is complete: it names the rows, defines each field's semantics including error and empty cases, and requires no further inference to call correctly.

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

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

The tool takes no parameters, so the baseline is 4. Schema coverage is 100% and there is nothing for the description to disambiguate at the input level.

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 (report the last standards sync run) and scopes it to each standards body. An agent can distinguish this from search_standards or get_job_result without opening the schema.

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

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

Usage is only implied: an agent infers 'call this to check sync health before relying on standards data'. There is no explicit when-to-use, when-not-to-use, or pointer to a contrasting sibling such as get_job_result.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the ranking mechanism (edition count as a popularity proxy) and the underlying subject API, but says nothing about failure modes, rate limits, or how sparse subjects are handled.

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

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

Two short sentences, front-loaded with the action and the source, with no filler. There is mild redundancy between "via Open Library" and "Uses the Open Library subject API", which is the only wasted phrasing.

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

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

With only two fully documented parameters and an output schema present, the description need not explain return values, and it covers the essential behavior: source, ranking logic, and topic scope. Only the relationship to the sibling recommendation/search tools is left unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, and the description goes slightly beyond by clarifying that 'subject' is a topic fed into the subject API and that results are popularity-ranked rather than arbitrary. The 'limit' cap is left entirely to the schema, which is acceptable given full coverage.

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

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

States a specific verb and resource ("Recommend books for a subject") plus the upstream source (Open Library), which is unambiguous on its own. It does not distinguish itself from the nearby siblings search_books or recommend_papers, so an agent must infer the difference from the ranking note alone.

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

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

Usage is implied by "find popular books on a topic" and "sorted by edition count", which hints this is a popularity-ranked recommendation rather than a keyword search. There is no explicit when-to-use guidance and no mention of when search_books or recommend_papers would be the better choice.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: a hard 500-result ceiling and an async continuation path that returns a job handle polled via get_job_result. It does not discuss rate limits or how recommendations are ranked, keeping it short of a 5.

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

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

Front-loaded with the core purpose and kept to three short sentences with no filler. The 500 cap is stated twice ('at most 500 recommendations; a larger limit is capped at 500'), a small redundancy that costs it a point.

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

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

With an output schema present, return values need no explanation, and full schema coverage handles parameters. The description covers the cap and the async job path, which are the main surprises for this tool. Only ranking/scoring behavior for the recommendation itself is unexplained, which is a minor gap.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the 500 max on limit and the 1-5 positive_ids guidance. The description's only additional semantic framing is the 'negative' steering intent, which the schema already conveys with 'steer away from'; baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Recommend papers based on positive (and optionally negative) examples') and immediately signals the example-based input model, which distinguishes it from query-driven siblings such as search_papers and from the different-resource recommend_books. An agent can identify the right tool without opening the schema.

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

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

It gives clear usage context: normal calls answer directly, long-running calls return a job handle to poll with get_job_result, explicitly naming the sibling to use in that case. It does not state when to prefer recommend_papers over search_papers (e.g., 'use when you already have example papers'), so it falls 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?

Beyond the readOnly/non-destructive annotations, the description discloses real behavior: local matching avoids network calls, a cold catalogue triggers an index download that exceeds the soft deadline and returns a job handle, and ambiguous input yields multiple candidates. It also explains the critical null ``record`` + ``warning`` failure semantics, which the annotations cannot convey.

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

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

The purpose is front-loaded in one line, followed by tightly grouped paragraphs on fallback, cold-cache behavior, and result interpretation. Each paragraph earns its place, though the cold-catalogue paragraph is slightly verbose relative to its point.

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 tool with an output schema and read-only annotations, the description covers everything an agent needs: expected latency on a cold cache, the job-handle branch, and how to interpret ambiguous or failed lookups. The output schema handles return shape, so nothing material is missing.

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

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

Schema coverage is 100% and the single ``raw`` parameter is already documented as the citation string as it appears in a reference. The description restates this as a 'messy standard citation string' without adding format, length, or example guidance, so the schema does the work.

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

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

The first sentence gives a precise verb and resource: normalise a messy standard citation string to its canonical form. That is clearly distinguishable from search_standards or get_standard, though the description never names a sibling to reinforce the contrast.

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

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

It explains the internal escalation path (local regex first, source APIs as fallback) and explicitly tells the agent to poll with ``get_job_result`` when a job handle is returned instead of a result. What is missing is guidance on choosing this tool over search_standards when the agent is unsure whether the citation is already canonical.

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 read-only, open-world, non-destructive behavior, and the description adds two traits they cannot express: the upstream is Open Library with politeness rate limiting, and a busy moment may return a job handle instead of results. The one gap is that it doesn't say how to tell a job-handle response apart from a result set, or what happens if the handle expires.

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 action, then the index preference, then the async caveat — each carrying distinct information with no restatement of the title or schema. Nothing could be removed without losing routing or behavioral signal.

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

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

An output schema exists, so return-shape explanation is unnecessary, and the description instead spends its words on the one non-obvious runtime behavior an agent must handle: a possible job handle requiring polling. With zero required parameters and full schema coverage, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds rationale the schema lacks: title and author hit dedicated indexes and return far better results, which explains why the schema marks them "recommended." The ``limit`` parameter is left entirely to the schema, which is acceptable given full coverage.

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

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

States a specific verb and resource ("Search for books") and enumerates the three search axes (title, author, free text), which cleanly separates it from search_papers and search_standards among the siblings. An agent can identify the right tool without opening the schema.

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

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

Gives an explicit preference ordering — use ``title``/``author`` over ``query`` — with the reason (dedicated indexes, better results), and names the fallback path when the service is rate-limited (poll with ``get_job_result``). That is concrete when-to-use and alternative routing rather than implied guidance.

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

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

Annotations cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely new behavior beyond them: typical latency of a few seconds, a hard 100-result cap, the recommendation to paginate with offset, and a background-job degradation path with the specific polling tool named. An output schema exists, so return format need not be restated. This is exactly the kind of operational context annotations cannot carry.

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

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

Three short paragraphs, front-loaded with purpose, then operational limits, then the async fallback — each paragraph serves a distinct need. Minor waste in 'a larger limit is capped at 100' duplicating the schema's max-100 note, and the blank-line-heavy formatting is slightly loose, but nothing is bloated.

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 read tool with full schema coverage, an output schema, and safety annotations, the description supplies what structured fields cannot: latency, the result cap, pagination strategy, and the job-handle fallback. The filtering parameters (venue, years, min_citations, fields_of_study) are left entirely to the schema, which is acceptable given 100% coverage. Nothing critical to invoking it correctly is missing.

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

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

Schema description coverage is 100%, so every one of the ten parameters is already documented, including enums for sort and fields. The description's only added parameter meaning is that limit values above 100 are silently capped and that offset is the pagination lever, which largely restates the schema's 'max 100' and 'Pagination offset'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource plus the backing service: 'Search Semantic Scholar for papers matching a query.' An agent can distinguish it from resource-specific siblings like search_books, search_standards or get_paper by the noun. It stops short of naming a nearest alternative such as recommend_papers, so the differentiation is implicit rather than explicit.

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 operational guidance for the async case ('Should the call run long it continues in the background and returns a job handle to poll with get_job_result'), which tells the agent what to do with the result. However, it never says when to prefer this tool over recommend_papers, get_paper or other siblings, and offers no exclusions or prerequisites. Usage context is implied, not stated.

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

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

Goes well beyond the readOnly/openWorld annotations: it discloses that a cold catalogue causes the first call to exceed a soft deadline and return a job handle for ``get_job_result`` instead of results. It also documents the result contract (``partial`` always present, ``failed_bodies`` and ``warning`` when true) and explains why partial is intentionally not an error. This is exactly the kind of latency and response-shape context the schema cannot carry.

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

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

Front-loaded with purpose, then source scoping, then cold-start behaviour, then result semantics, in four tight paragraphs. Every sentence carries distinct, actionable information and none restates the schema verbatim for filler.

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

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

For a federated search tool with an output schema already describing return fields, the description covers the remaining gaps an agent needs: source coverage, the single-source filter, cold-cache latency and job-handle fallback, and how to interpret partial results. Nothing needed to call or interpret it is missing.

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

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

Schema coverage is 100%, so all three parameters (query, body, limit) are already documented with their allowed values and defaults. The description restates the body filter and the identifier/title/free-text query modes but adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

The opening sentence gives a specific verb (search) plus resource (technical standards) and enumerates the matching modes (identifier, title, free text), and the second sentence names the covered corpora (NIST, IETF, W3C, ETSI). That is enough for an agent to distinguish this discovery tool from the fetch/resolve siblings like get_standard or resolve_standard_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 description gives operational guidance on when to constrain via ``body`` and, importantly, tells the agent to treat a partial answer as usable and possibly worth re-asking rather than as a failure. It does not explicitly compare against siblings such as resolve_standard_identifier or get_standard, so no exclusion guidance is present.

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