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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's 'on arXiv' confirms an external lookup. It adds useful output-shape detail (style name on the line above each citation, one .bib entry) but says nothing about behavior on invalid IDs, unversioned papers, or network 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?

The core purpose is front-loaded in the first clause, followed by input enumeration and a concrete example. It runs long for a two-parameter tool and repeats the arXiv ID format already in the schema, 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 read-only, two-parameter lookup with no output schema, the description supplies enough: supported styles, the 'all' response layout, and the bibtex variant. Gaps remain on the ris style (only in the schema) and on error behavior for malformed or nonexistent IDs.

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

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

Schema coverage is 100%, so the baseline is 3. The description does add meaning beyond the schema by explaining the 'all' output layout ('each one with its style name on the line above it') and the bibtex use case, but it also lists fewer styles than the schema (it omits 'ris'), creating a partial mismatch.

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: 'Look up an arXiv ID on arXiv and format the preprint citation' plus the exact list of supported styles. The arXiv-ID resource inherently separates it from siblings like cite_from_doi or cite_from_isbn, though no sibling is ever named.

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?

An example prompt ("Cite arXiv 1706.03762 in APA.") and the note that 'bibtex' should be passed for a reference manager give implied usage guidance. However, it never states when to prefer this over cite_from_doi, cite_from_url or format_citation, so an agent must infer routing from the resource type alone.

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

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

Annotations already declare readOnlyHint and openWorldHint, so this is a known-safe external lookup. The description adds real value on top: the result shape is determined by the Crossref record type, and multi-style output is laid out with the style name on the line above each entry. Auth, rate limits, and failure behavior on unknown DOIs are unaddressed.

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 and Crossref-dependent output shape come first, then parameters, then modes, then examples — a sensible front-loaded order. The two example prompts at the end are marginally redundant with the preceding sentences but demonstrate realistic invocation 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 no output schema, the description carries the burden of describing returns and does so for both single-style and 'all' modes, plus the BibTeX special case. The 'ris' omission and lack of error behavior for unresolvable DOIs are the remaining 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 coverage is 100%, so the schema already documents both parameters, making 3 the baseline. The description adds example prompts and the 'all' vs 'bibtex' distinction, but its style list omits 'ris', which the schema documents — a minor inconsistency that prevents credit above baseline.

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

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

States a specific verb and resource chain (look up a DOI on Crossref and format the citation) and enumerates the record shapes it can produce. The DOI-specific scope implicitly separates it from cite_from_url, cite_from_arxiv, and cite_from_isbn siblings.

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

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

Gives clear context for invocation (DOI in hand, optional style selection) and explicit instructions for special modes: pass 'all' for three styles, pass 'bibtex' for a .bib entry. It never names an alternative sibling or states when-not to use it, 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 declare readOnlyHint=true and openWorldHint=true, and the description usefully names Open Library as the external source and describes the reply shape (style name on the line above each citation). It adds no error behavior for an invalid or unknown ISBN, no rate-limit or latency note for the external lookup, and its "all three styles" claim is internally inconsistent with the six styles it lists.

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 inputs then output conventions; every sentence is functional and the example prompt is a cheap way to show a real invocation. Minor deduction because "all three styles" is a misleading compression of the six style choices enumerated one clause earlier.

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 no output schema, the description supplies the missing return-format detail (each citation labeled with its style name, bibtex yielding a single .bib entry), which is exactly what an agent needs. It stops short of covering failure modes for a bad ISBN or divergence between the style list here and the schema's ris option.

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

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

Schema description coverage is 100%, so the schema already documents both params, including the ris alias. The description restates the dash tolerance and style values almost verbatim and even omits the ris option the schema offers, so it adds little meaning beyond structured fields.

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 ("Look up an ISBN on Open Library") plus the resource and the transform applied (format book citation in APA 7, MLA 9, Chicago author date, Harvard, IEEE or BibTeX). The ISBN input alone distinguishes it from cite_from_doi, cite_from_url and cite_from_arxiv 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?

Gives in-tool guidance for parameter choices ("Pass all to get all three styles", "Pass bibtex to get one .bib entry for a reference manager") and an example prompt. It never says when to pick this over the sibling citers (DOI/URL/arXiv) or what happens if the ISBN is unknown, so routing across the family 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?

Annotations already cover read-only and open-world behavior, and the description still adds useful context: it reads title, site name and date from the page, allows overriding them, and explains that 'all' returns three labeled citations in one reply. It omits failure behavior (unreachable page, missing metadata), which is the main remaining gap.

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 first sentence is front-loaded and strong, but the 'Inputs:' enumeration largely duplicates the input schema field-by-field, and the example prompt repeats the same information a third time. Roughly a third of the text does not earn its place.

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

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

With no output schema, the description usefully sketches the return shape for the 'all' mode (labeled citations, one per style) and for bibtex. For a single-fetch formatting tool with fully documented parameters, only network-failure behavior 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 restates the parameters rather than extending them, and its style list ('apa7, mla9, chicago-ad, harvard, ieee, bibtex or all') actually drops 'ris', which the schema does include – a small inconsistency that adds no meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Fetch a web page and format it as a website citation' in seven named styles. The web-page framing implicitly separates it from cite_from_doi, cite_from_isbn and cite_from_arxiv, though no sibling is named explicitly, which keeps it just 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?

Usage context is implied ('Cite this page in APA: https://...') and the description explains the bibtex path for reference managers, but it never states when to prefer cite_from_doi or find_doi over this tool, nor any exclusions such as paywalled or non-HTML pages. The agent must infer routing from the input type.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds real value: the data source (Crossref), the default result count of 5, and the returned fields (title, authors, year, container, DOI). It doesn't mention fuzzy-match behavior for partial titles beyond implying it, which keeps it just below a 5.

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

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

Front-loaded with purpose then return shape then inputs, with zero filler. The example-prompt sentence is a nice addition but slightly redundant given the rest of the text.

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

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

With no output schema, the description correctly compensates by enumerating the returned fields and default result count. Combined with the source and next-step tool, an agent has everything needed to call it and use the result.

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

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

Schema coverage is 100%, so all three parameters are already documented with matching wording ("family name", "as much of it as you know", limit 1-10). The description largely restates the schema rather than adding new syntax or edge-case guidance, so the baseline 3 applies.

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

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

States a specific verb and resource ("Search Crossref for the DOI") and names the input precondition (title but no DOI). It also distinguishes itself from sibling cite_from_doi by positioning this tool as the lookup step that feeds that one.

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 trigger condition ("when you have its title but no DOI") and routes downstream to cite_from_doi. It does not explicitly contrast with cite_from_url or cite_from_isbn, so the agent must infer that those handle non-title identifiers.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description still adds real behavior: alphabetisation by first author's family name with a title fallback for anonymous works, IEEE numbered in citation order, BibTeX and RIS emitted in the order given, a 50-lookup ceiling, and all-or-nothing error handling that names the failing lookup. Those are exactly the details an agent cannot get from the 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?

The purpose and ordering rules are front-loaded well, and the example prompt is a useful anchor. However, the long mid-sentence inventory of source fields (type, title, authors, year, container, publisher, city, edition, ...) duplicates the schema verbatim at 100% coverage and bloats an already dense single sentence.

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

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

For a tool this complex the description covers what matters: how the list is ordered per style, how inputs combine, the 50-lookup limit, and error behaviour. There is no output schema, and it only implicitly signals the return shape (a list, or one BibTeX/RIS block) rather than stating it, which is the one gap worth closing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the style enum values and the Crossref/Open Library lookups. The description largely re-enumerates the source object fields rather than adding meaning, though it does clarify that all four input arrays can be combined and that sources is optional when lookups are supplied. 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 — formatting several sources into one works cited list — and immediately pins down the scope that separates it from format_citation: many sources, one list, with per-style collation rules. It also distinguishes itself from the lookup siblings (cite_from_doi, cite_from_isbn, cite_from_url) by describing those as inputs it can absorb in bulk.

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 clear: give sources, dois, isbns, urls or any mix, up to 50 lookups, and a failing lookup aborts with an error naming it. The example prompt shows a realistic invocation pattern. What is missing is explicit routing guidance — it never says to use format_citation for a single source or cite_from_doi when only one DOI is involved, leaving the agent to infer that from the 'same fields as format_citation' reference.

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 readOnlyHint=true and openWorldHint=true, so the description's job is to add output behavior — and it does: multi-style replies are labelled with the style name on the line above, BibTeX yields a single .bib entry, RIS yields an importable record. It does not discuss error behavior for missing fields (e.g. a journal with no container), which limits it to a 4.

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 content is front-loaded and ends with a useful example, but the source types and styles are enumerated twice (first sentence, then again in the 'Inputs:' list), and the style list appears a third time in the 'Pass all/bibtex/ris' sentences. That repetition inflates a description that could be materially shorter without losing anything.

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 22-parameter, no-output-schema tool, the description covers the input contract, the meaning of the style selector, and the shape of the response for each output mode, which is what an agent most needs. The residual gaps are conditional-requirement details (which fields each source type demands) that are spread partially in the schema rather than summarized here.

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

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

With 59% schema description coverage and 22 parameters, the description carries real weight: it explains editor/translator placement rules (editors substitute for authors; co-existing names follow the title per style) and clarifies the container concept beyond the schema. It still only lists several parameters (doi, url, year, volume, issue, pages) by name without explaining their per-style behavior.

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 names a specific verb (Format) and resource (citation) and enumerates supported source types and styles, so the agent knows exactly what comes out. It is clearly distinguishable from sibling tools like cite_from_doi or cite_from_url, which take an identifier rather than supplied details.

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 invocation guidance: pass "all" for the three main styles, "bibtex" for a .bib entry, "ris" for a Zotero/EndNote/Mendeley record, and it supplies a worked example prompt. It never explicitly says when to prefer this over cite_from_doi/cite_from_isbn, so the alternative-routing guidance is implicit 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?

The annotations already establish readOnlyHint and openWorldHint, and the description adds meaningful behavioral detail: DOI or ISBN lookup fills in authors and year, and DOI and ISBN cannot be combined. It does not cover lookup failure behavior, but the added disclosure is substantive and consistent with the annotations.

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

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

The description is front-loaded with the tool's purpose and then packs the key input rules, form/style options, and an example prompt into a short space. The example earns its place, though some input listing slightly repeats schema 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?

For a 7-parameter citation tool with no output schema, the description is complete enough: it explains the output type, input modes, supported styles/forms, and the DOI/ISBN constraint. It could say more about invalid identifiers or missing author/year cases, but the core call behavior 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?

With only 57% schema description coverage, the description meaningfully compensates by explaining authors, year, DOI, ISBN, page, form, and style inputs. It adds the important mutual-exclusion rule for DOI and ISBN and clarifies narrative vs parenthetical form, though page and year formatting details remain sparse.

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

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

The description clearly identifies the resource and output: an in-text citation generated from authors/year or DOI/ISBN, with optional page and narrative form. It is specific enough to distinguish this from bibliography generation, but it does not explicitly differentiate itself from sibling tools such as format_citation or cite_from_doi.

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 input guidance and an example prompt, which implies when the tool is useful. However, it does not state when to use this tool instead of siblings like format_citation, cite_from_doi, cite_from_isbn, or format_bibliography, and it provides no explicit exclusions.

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