CiteStamp

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuine behavioral value beyond them: it enumerates the possible outcomes (found, confirm with reason, not found in the named sources on a date, couldn't check) and warns that a not-found is not proof a work was never published.

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 purpose before usage, input format, and outcome taxonomy. Every sentence earns its place with no padding.

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?

No output schema exists, so the description carries the return-value burden and does so by listing the four result states and their epistemic limit. It is essentially complete for a one-parameter read tool, though it could note what the 'confirm' reason contains or any source-coverage caveats.

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 there is a single parameter, so the schema already documents accepted identifier formats. The description's 'Give a DOI, an arXiv id or the reference as written' largely restates the schema, adding no new syntax or 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?

States a specific verb and resource ('whether a reference resolves to a real work') that is clearly distinct from siblings like references_of (lists a work's references), what_cites, and retraction_listing. An agent can identify the tool's function 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?

'Use when an answer is about to cite a paper' gives a concrete triggering context, which is stronger than implied usage. It does not explicitly name when to prefer a sibling or state exclusions, so it falls 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 readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds real behavioral context beyond that: results are tiered as asserted vs inferred, each carries attribution and provenance, and the operation is paged — all of which shape how an agent interprets output. It stops short of describing ordering or dedup mechanics, which live in the 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 sentences plus a terse 'Paged.' fragment; the core scope statement is front-loaded and nothing is padded. The trailing one-word fragment is slightly abrupt but efficient rather than 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?

For a paged read tool with no output schema, the description covers the key concepts an agent needs (bidirectional neighbourhood, asserted vs inferred tiers, paging) and the schema handles pagination mechanics. It could say more about result ordering or the shape of an edge record, but nothing critical 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% and the parameter descriptions are unusually rich (limit tiers, offset paging semantics, duplicate removal, has_more). The description only adds the vague word 'Paged', so it contributes little beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb+resource with scope: 'every edge touching the given work in either direction', and adds the tiering ('asserted|inferred with attribution and provenance'). It implicitly contrasts with siblings by offering the 'whole neighbourhood in one call' versus the narrower references_of/what_cites/what_refutes/what_supports, but it never names them, so differentiation rests on inference.

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 concrete trigger ('Use when a user asks "what is known about this paper's citations" or wants the whole neighbourhood in one call'), which is clear context for selection. It does not explicitly state when to prefer a narrower sibling instead (e.g. when the user only wants cited-by edges), so no exclusion 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 already cover the safety profile (readOnly, idempotent, non-destructive). The description adds that results are paged, which is real context. It does not mention return shape, but the schema descriptions carry has_more/inferred_total, so the 3 reflects useful but modest added behavioral context.

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 tight sentences: definition, then use cases, then the paging note. Front-loaded with the core operation and free of 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, paged list tool with a fully documented schema and annotations covering safety, the description supplies direction, use cases, and the paging caveat. It is largely complete, though it could have noted what an 'edge' or tier represents.

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 limit, offset, identifier formats, and asserted_only in detail. The description adds nothing parameter-specific, so the baseline 3 is correct.

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 ('What the given work CITES (its reference list)') and names the direction of the edge. This clearly distinguishes it from the sibling 'what_cites', which reads the opposite direction. An agent can pick between them 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?

Gives three concrete triggering scenarios: asking what a paper relies on, checking whether a specific citation exists, and vetting a reference before reuse. No exclusions are stated, but the sibling set makes the boundary obvious and the positive conditions are unusually specific.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-obvious context: the data comes from a dated export joined weekly (staleness), and 'Not listed means not in that export' clarifies negative-result semantics. It stops short of stating what the response actually contains, which matters since there is no output 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 compact sentences, front-loaded with what the tool determines, followed by the usage trigger and the coverage caveat. No filler or repetition.

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 lookup with strong annotations, the description covers purpose, trigger, data source freshness and negative-result caveats. The one remaining gap is the shape of the returned value (a status/boolean vs. a record), which the description only implies since no output schema exists.

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 single parameter's description already specifies accepted DOI formats (bare, doi: prefixed, doi.org URL). The description adds nothing beyond 'given DOI'. Baseline 3 is appropriate when the schema carries the full parameter burden.

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 (checks/lists) and resource (Retraction Watch database entry for a DOI), and the scope is precise: a retraction-status lookup, not a citation-graph traversal. This is clearly distinguishable from the sibling tools (what_cites, what_supports, references_of, etc.), which all deal with citation relationships rather than retraction status.

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 trigger: 'Use when a user asks whether a paper has been retracted or carries a retraction notice.' It also draws a scope boundary ('the publisher record is not checked'), which functions as a when-not. It does not name an alternative tool, but the siblings are not substitutes for this lookup, so little 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds return-shape context ("edges with tier + attribution; paged"), which the annotations do not convey, though pagination mechanics are left to the 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 sentences, purpose first, then usage triggers, then return/paging note. No filler; every clause earns its place.

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

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

With no output schema, the description supplies the essential return shape (edges, tier, attribution, paged), and the schema fills in paging details. It stops short of relating this tool to the what_supports/what_refutes siblings, a minor gap for a graph-query family.

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 parameter docs are unusually rich (paging quirks, has_more semantics, asserted_only meaning), so the description is not needed to carry parameter meaning. Baseline 3 applies; the description adds nothing param-specific.

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?

"Works that CITE the given DOI (incoming citations)" gives a specific verb, resource, and direction, immediately distinguishing it from the sibling references_of (outgoing). The parenthetical "incoming citations" removes any ambiguity about edge direction.

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 names three concrete user intents (who cites a paper, how cited, verifying a 'cited by' claim), which is strong context. It stops short of explicitly routing to or away from siblings like what_supports / what_refutes, so an agent must infer those boundaries.

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, idempotent, non-destructive). The description adds meaningful provenance context beyond that — the edges are human-signed and/or coded from the FORRT Replication Database, and there are inferred vs asserted tiers — which helps an agent interpret 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?

Two tight sentences: the first defines the relation and its sources, the second states when to invoke it. 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?

No output schema exists, but the description identifies what the returned edges represent and their provenance, and the parameter docs explain paging/coverage signals. Adequate for an agent to call and interpret it, though return shape itself is not described.

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 parameter descriptions are unusually rich (paging caveats, has_more/inferred_total semantics, asserted_only meaning). The description adds no parameter detail, so baseline 3 is correct — the schema does all 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?

States a specific verb (refutes) and resource (edges recorded against the given work/claim), and names the concrete provenance sources (human-signed refutations, FORRT replication failures). This clearly distinguishes it from siblings like what_supports and what_cites.

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 triggering context: 'Use when a user asks whether a finding failed to replicate or has been contradicted.' That is a clear when-to-use statement, though it does not name the contrastive sibling (what_supports) explicitly.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds substantive behavioral context the annotations cannot: what an edge represents, that support comes from two distinct sources (asserted vs. FORRT-coded replication), which pairs with the asserted_only parameter. It stops short of describing pagination behavior, which the schema covers instead.

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 definition and followed by the use case. Zero filler and no repetition of schema content.

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?

No output schema exists, but the description identifies what is returned (support edges from two sources) and the schema documents paging and result-count signaling (has_more, inferred_total). An agent has enough to call this correctly; only the exact result shape is left implicit.

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 (including the limit/offset paging caveats and asserted_only semantics) are already documented. The description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb+resource: edges recorded as SUPPORTING a given work or claim, and enumerates the two content streams (human-signed assertions, FORRT replication outcomes). This directly contrasts with the sibling what_refutes, so an agent can route between them 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?

Gives a clear trigger condition: 'Use when a user asks whether a finding held up or was replicated.' It does not, however, name what_refutes or what_cites as the alternatives to use when the intent is refutation or citation lookup, so the guidance is clear but not fully exhaustive.

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