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

Annotations already establish readOnly/non-destructive, so the bar is lower; the description still adds real behavioral context: it verifies source hashes and literal anchors, performs field accounting rather than entailment reasoning, and must surface missing evidence and unverified attribution. It does not describe the return payload or what happens on hash mismatch, but the audit semantics are well disclosed.

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 trigger followed by a compact item spec and a scope limitation; every sentence carries information. The item-shape sentence is dense and jargon-heavy, but it is the most efficient place for that detail.

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 audit tool with no output schema, this is close to complete: the item contract, the check semantics, and the disclosure requirement are all present. The unexplained `checklist_id` and the absence of any description of the audit result 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 0%, so the description carries the full documentation burden. It does a good job on the `items` structure — field, status enum values, statement, reason, and citation objects with id/quote/offset — but never explains `checklist_id`, leaving one of two required parameters undocumented.

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

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

States a specific verb and resource: audit each checklist field before the final answer. It also delimits the check type (hash, literal anchors, field accounting vs. semantic entailment), which separates it from a generic evidence tool. It never names a sibling, so differentiation is by content rather than routing.

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 ('Before final answer') and an explicit exclusion ('NOT semantic entailment'), which tells the agent what this tool will not catch. It does not name alternatives such as evidence_checklist, so the agent must infer which tool creates the checklist versus audits it.

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

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

Adds context annotations cannot convey: the snapshot is frozen and sampled, so results are incomplete and may be stale, and there is no live expansion. Pagination is signalled via 'Follow next_offset'. It stops short of stating what happens on an unknown identifier or an exhausted offset.

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

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

Four short sentences, front-loaded with the core action, then modes, then pagination, then coverage caveats. No filler; every clause adds usable 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?

Given no output schema and zero schema descriptions, the description covers the essentials: what is read, which modes exist, how to page, and the sampling limitation. It could go further on return shape beyond next_offset and on error behavior for invalid identifiers.

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

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

Schema coverage is 0%, so the description must carry all parameter meaning, and it largely does: identifier accepts a library paper_id or an OpenAlex W ID, and mode accepts references/citing/relations. Offset is only obliquely covered by 'Follow next_offset', with no stated default or range.

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?

Opens with a specific verb+resource: reading a frozen citation snapshot, and names the three access modes (references, citing, relations). It is clearly distinguishable from siblings like search or fetch, though it never explicitly contrasts with them by name.

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

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

Usage is implied by the mode list and the notes on sampling and no live expansion, but there is no explicit guidance on when to choose this tool rather than search, fetch, or source_page. The agent must infer the boundary from the resource name alone.

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

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

Annotations already cover read-only/non-destructive/openWorld=false and oddly declare idempotentHint=false with no explanation here. The description adds one genuine behavioral note ('No scientific completeness guarantee'), which is useful scope framing, but says nothing about what the tool returns, whether state is stored between calls, or how the checklist relates to the later audit.

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 customization, then the hand-off. Nothing wasted, though the first sentence's phrasing is slightly awkward and could be a flat imperative.

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?

There is no output schema, so the description should explain what a 'checklist' is structurally — default fields, return shape, whether it is text or structured. It also leaves the idempotency flag unexplained. For a tool whose whole value is the artifact it produces, this is a significant omission.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only vaguely gestures at extra_fields via 'add question-specific requirements' while never explaining the required 'question' input or the format of the extra field names. An agent must guess whether extra_fields are field labels, criteria strings, or evidence categories.

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 verb phrase 'Start scientific questions with an explicit evidence checklist' gestures at a checklist-creation tool, but never states plainly what it produces (a template? a stored scaffold? a returned field list). Naming audit_answer does differentiate it from siblings like search/fetch, so it is not a tautology, but the core purpose stays abstract.

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 a clear trigger ('start scientific questions'), an in-lifecycle action ('add question-specific requirements'), and an explicit follow-up ('later submit every field to audit_answer'). That is solid workflow routing; only the exclusion side (when NOT to build a checklist) is missing.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: hash validation, page provenance, pagination, access restrictions, and a caution about inferring ownership.

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 compact sentences, front-loaded with the core purpose. Each sentence adds operational guidance or a constraint, and none is redundant.

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 tool with no output schema, it covers the essential preconditions, pagination, access constraints, and provenance checks. Some ambiguity remains around what 'parent section' means and how hash validation and page provenance manifest in the returned content.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It constrains id to search results and hints at offset behavior through next_offset, but it does not directly define the offset parameter's meaning or reconcile 'next_offset' with the schema's 'offset' field.

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: 'Read the original parent section for a search result ID,' and adds hash validation/page provenance. It does not explicitly distinguish itself from sibling tools such as source_page, so it falls short of a 5.

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

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

Explicitly requires IDs to come from search, forbids arbitrary file access, and explains pagination via next_offset. It lacks explicit when-not guidance or direct comparison with sibling alternatives, but the usage context is clear.

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

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

Annotations already cover read-only and non-destructive safety, and the description adds meaningful context beyond them: it is a cheap lexical lookup with no model call, only *active* papers are returned, and an empty query is capped at 50 results. Pagination beyond that cap is unstated.

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

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

Three terse clauses with zero filler; the match modes are front-loaded and the default/cap behavior follows immediately.

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

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

For a single-optional-parameter list tool with no output schema, the description covers match modes, default behavior, and result cap. What an agent cannot learn is how to page past 50 results or what fields come 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 coverage is 0%, so the description must carry the parameter, and it does: `query` accepts a title substring, an exact DOI, or a paper ID, and the empty-string default is explicitly defined as 'list up to 50'. Only the ID/DOI format syntax is left unspecified.

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/list active papers) plus the three match modes: title substring, exact DOI, paper ID. It is distinguishable from `search` only implicitly, via the 'No model call' note, so it stops short of a clean sibling differentiation.

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

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

"Empty query lists up to 50" and "Use IDs to scope search" give concrete invocation guidance, but the description never says when to prefer this over `search` or `citation_network` — the boundary 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 cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description still adds substantive behavior: 'No answer generation', the exact return shape (source spans, PDF pages, section headings, result IDs), and the 10-item cap on paper_ids. The unexplained idempotentHint=false is the main omission.

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

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

Four short sentences, front-loaded with the core action and free of filler; the 'no answer generation' disclaimer sits last where it functions as a caveat. Slightly telegraphic phrasing ('source-first') costs a bit of immediate clarity.

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 parameters, no output schema, and annotations already declaring the safety profile, the description closes the important gaps: it describes the return payload, forbids answer generation, and constrains both inputs. 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 0%, so the description must compensate, and it does for both parameters: query must use faithful English scientific terminology without presupposing answers, and paper_ids is optional, scopes the search, and is capped at 10. It does not say where paper_ids values come from (presumably list_papers), which keeps it from a 5.

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

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

The description gives a specific verb+resource ('Retrieve source-first scientific evidence') and immediately clarifies that it returns spans, pages, headings, and IDs rather than answers, which separates it from fetch and audit_answer. The name 'search' alone is generic, so the description is doing real work, though it never explicitly names the sibling it differs from.

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 rather than stated: 'Result IDs for fetch' hints at a search-then-fetch chain, and the guidance on phrasing Chinese questions in English terms is operational advice. But there is no explicit when-to-use versus list_papers or citation_network, and no stated preconditions or exclusions.

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

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

Annotations already declare readOnly/non-destructive/openWorld=false, so the description adds value with what's beyond them: page read is gated on source hash validation, image return is optional, and the tool explicitly does not certify interpretation. It omits what happens on a hash mismatch or whether text is returned alongside the image.

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 dense sentences, front-loaded with the action and its precondition, followed by use cases and exclusions. No filler and nothing restated from the schema or annotations.

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 and zero schema descriptions, the description covers the core contract: page numbering, hash validation, optional image. Remaining gaps are paper_id semantics and failure behavior on validation error, which matter for a lookup that can fail.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It does this well for `page` (1-based, original PDF numbering, which is a real correctness detail), and implies `render` via "optionally return its image," but leaves `paper_id` completely unexplained and never states the render default of true.

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 (read an ORIGINAL PDF page) with meaningful scope qualifiers: 1-based indexing and source-hash validation. It is unmistakably distinct from list_papers/search/fetch, though it never names a sibling to contrast against 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?

Gives concrete positive triggers (table column alignment, footnotes, figures, formulas, missing experimental conditions) and an explicit exclusion (does not fetch external supplements, does not certify interpretation). It stops short of naming which sibling to use instead when the need is, e.g., a supplement or a search.

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