Academic Evidence Pack

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

With no annotations, the description carries the full disclosure burden, and it does so thoroughly: it reveals payment requirements via x402, the unpaid isError path, signing and reproducibility guarantees, no-LLM processing, per-claim source/time metadata, and the returned settlement/transaction/network fields. This goes well beyond a generic 'verify citations' statement.

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

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

The description is dense but every sentence carries high-value operational information: output format, input modes, authenticity guarantees, payment, failure mode, and alternatives. The core purpose is front-loaded and the sibling routing is placed at the end.

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 complex paid tool with no output schema and no annotations, the description covers output contents, payment/settlement fields, error behavior, reference limits, and use-case fit. An agent has enough context to decide whether to call this tool, how to handle unpaid or successful calls, and when to route to a sibling.

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 67%, so the description is not fully excused from explaining inputs. The description meaningfully adds that the input is structured references or BibTeX and states the 50-reference limit. It does not explain the options object beyond what the schema lists, leaving strict_authors and include_unpaywall somewhat underspecified.

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

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

The description opens with a specific purpose: "Verify a bibliography," then details the exact verification dimensions (existence, resolution, retraction, metadata match, fabrication risk). It also positions the tool against evidence_pack_preview / evidence_pack by stating it is for checking references the agent already has rather than finding 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?

It gives explicit context for when to use the tool — checking existing references — and names the alternatives for related-but-different tasks: use evidence_pack_preview / evidence_pack when looking for papers for a question or claim. It also clarifies the paid-call flow and unpaid error behavior, leaving little ambiguity about invocation.

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses the signed Ed25519/RFC 8785 format, byte-reproducibility, no-LLM guarantee, source/retrieval time, the 75-reference limit, the $3.00 payment, unpaid-call isError behavior, result fields, and the client-side spend-cap failure mode.

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

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

The description is dense but every sentence carries operational information: what is verified, input formats, output properties, payment details, failure modes, and correct sibling routing. The payment/spend-cap warning is essential and not extraneous.

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?

Despite lacking an output schema, the description covers the return content, payment semantics, and usage boundaries well. The main remaining gap is the undocumented meaning of strict_authors and include_unpaywall, which an agent may need to set 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 67%, with options (strict_authors, include_unpaywall) and several reference subfields lacking descriptions. The description adds only 'structured references or BibTeX' and the 75-reference cap, which is helpful but does not explain the option flags or subfield semantics. It also introduces a potential conflict by saying 'Up to 75 references' while the schema allows maxItems: 200.

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

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

The description states a specific action ('Verify a bibliography') and enumerates the exact checks performed, so an agent immediately knows the tool's purpose. It also explicitly routes evidence-finding queries to evidence_pack_preview/evidence_pack, but it does not differentiate itself from the sibling citation_report or citation_report_preview beyond the title's 'large tier' label.

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

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

It gives explicit guidance: use this tool when you 'already have' references to check, and use evidence_pack_preview/evidence_pack instead when finding papers for a question. It also warns about the x402 spend cap and how to handle it, which is actionable usage guidance.

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

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

With no annotations, the description carries the disclosure burden and does so richly: free preview, first-3 limit, no LLM, every claim carries source and retrieval time, byte-reproducible canonical JSON. The only flaw is internal ambiguity—it first calls the report 'signed (Ed25519...)' and then says 'unsigned'—so the preview's signature status is unclear.

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

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

The description is dense but front-loaded: it opens with purpose and preview status, then lists checks, output format, input formats, constraints, and routing in a logical order. Every sentence contributes, though the signed-format parenthetical adds some length.

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 3-parameter tool with nested objects and no output schema, the description covers what the report contains, input formats, limits, payment status, verification/no-LLM behavior, and sibling routing. It is incomplete only on the semantics of the options object, which is left undocumented.

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

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

Schema description coverage is 67%, so the description adds some value by reinforcing that structured references or BibTeX are alternative inputs, which matches the 'exactly one of references / bibtex' constraint. However, it does not explain the two nested options, strict_authors and include_unpaywall, which are otherwise undocumented in 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 clear verb ('Verify a bibliography') and resource, enumerates the checks (exists, resolves, retracted, title/author/year match, fabrication risk), and differentiates from evidence_pack by noting it checks references you already have rather than finding 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 tells the agent when to use this tool ('Use this to check references you already have') and when not to ('to find papers for a question or claim, use evidence_pack_preview / evidence_pack instead'). It also discloses the free-preview scope: first 3 references, unsigned, no payment.

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 are absent, so the description must carry all behavioral disclosure. It fully does so: it states the operation is free ('Free; no payment'), clarifies the output is an unsigned copy of the same report ('the same signed report ... unsigned'), covers transport behavior for hosted vs. local stdio, and lists all negative conditions when lookup fails ('Not found after the TTL, for previews, or for reports served by another process'). This is comprehensive and goes beyond what annotations usually provide.

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

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

The description is three sentences that are dense but front‐loaded: the core purpose and TTL frame come first, followed by transport behavior, then disqualifiers. Each sentence adds a distinct piece of information. The middle parenthetical '(request_id re-attached, unsigned, as on the paid result)' is slightly convoluted but not wasted. It is concise relative to the amount of behavior it conveys.

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

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

The tool has one parameter, no output schema, and no annotations. The description covers the main needs for correct invocation: what to provide, what you get back ('same bytes'), and when it fails. It does not mention response format or error messages, but for a re-fetch of an existing report, the output is already defined by the original report. The only plausible completeness gap is the absence of explicit note about whether the request_id must be within a signed session, but the TTL removal is already mentioned.

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 schema description already documents that request_id is 'the request_id from a paid citation_report / citation_report_large result' (100% coverage). The description adds the behavioral constraint 'within the cache TTL' and the requirement 'bought' that ties into the schema context. It does not re-explain the regex or format, which the schema covers. The extra semantics (recency and paid status) are useful and meet the baseline of 3 and exceed it slightly.

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?

Description opens with 'Re-fetch a paid report you already bought, by its request_id', which is a specific verb ('re-fetch'), resource ('a paid report'), and required scope ('you already bought'). It also distinguishes itself from siblings by the explicit exclusion 'for previews' and the paid/free contrast, so an agent can differentiate it from citation_report, citation_report_preview, and citation_report_large without opening a 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 clearly scoped to already-paid reports: 'Re-fetch a paid report you already bought.' The description also states when the tool is not to be used (beyond TTL, for previews, for reports served by another process). It does not name sibling tools by name (e.g., 'citation_report_preview') but the term 'previews' and the context of local stdio capability cover the alternatives. It could have explicitly said 'instead use ...' to earn a 5, but the guidance is otherwise explicit and accurate.

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

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

With no annotations present, the description carries the full behavioral burden and succeeds: it discloses the paid cost, payment mechanism, unpaid-call error behavior, the provenance fields returned, and the intentional hedge that the tool does not assert proof. This is well beyond what the schema or title could 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?

Each sentence adds information: core function, returned content, JSON/hedging, payment mechanics, unpaid behavior, and sibling routing. The most actionable facts are front-loaded, and there is no filler or repetition of the schema.

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 paid, 7-parameter tool with no output schema, the description covers success output, failure/payment requirements, pricing, provenance, and alternatives. An agent has enough context to call it correctly and interpret the result envelope; the only small gaps are filter-parameter specifics already visible in the schema.

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

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

The description maps conceptually to query and limit ('question or topic', '3-10'), and output details imply filters like open-access and retraction status. However, with 57% schema coverage, the description does not directly add meaning for from_year, to_year, open_access_only, or fields; it relies on self-explanatory names and schema constraints.

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

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

The description opens with a concrete verb and object: 'Find 3-10 scholarly candidates for a question or topic.' It goes beyond a terse label by listing the returned data and explicitly saying the tool does not claim a paper proves a statement. This also distinguishes it from the evidence_pack_preview and citation_report 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?

Usage is explicit: use this when the free evidence_pack_preview (at most 3 candidates) is not enough, and use citation_report to check references you already have. It also tells the agent what to expect on an unpaid call, which directly guides when and how to invoke the tool.

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

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

With no annotations, the description carries the behavioral burden and discloses key traits: at most 3 candidates, JSON-only output, no payment, caveat that it does not claim a paper proves a statement, and inclusion of retraction/correction warnings. It omits minor operational details like auth, rate limits, and error behavior, 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 dense sentences with no filler: the core value is front-loaded, behavioral constraints are stated, and sibling routing is saved for last. Every sentence earns its place.

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

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

Given the absence of an output schema and annotations, the description covers the main return contents and selection context well. It is slightly incomplete around how date filters, open-access-only, and field minimization affect results, but as a clearly bounded free-preview tool it gives enough to invoke 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 50%: query, fields, and exclude_known_retracted have descriptions, but to_year, from_year, and open_access_only do not. The description does not compensate for those undocumented parameters, though their names are largely self-explanatory. The output list indirectly aligns with the fields enum but does not explain how the fields parameter shapes the response.

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: returns a free triage with up to 3 scholarly candidates for a question or topic. The description enumerates the returned metadata and explicitly distinguishes the tool from evidence_pack and citation_report_preview.

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 when-to-use context: free triage for a question/topic. It also names alternatives and the conditions that select them: use evidence_pack for up to 10 candidates and citation_report_preview for checking references you already have.

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