Pith

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the burden on the description. The description adds useful behavioral context by specifying the argument ordering, the labeled statement roles, and that it covers one specific paper rather than search across papers.

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 core object and scope, then provides a compact list of supported request types and output entry fields. The sentence is somewhat dense, but every clause contributes useful selection and expectation-setting 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?

With a single parameter, full schema coverage, strong annotations, and an output schema, the description covers the key invocation context: what the tool analyzes, what request phrasings trigger it, and what each returned entry contains. It does not address edge cases like missing papers, but that is not critical given the other structured metadata.

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 arxiv_id parameter is already well documented, including accepted forms like bare arXiv ID, URLs, DOI, and Pith Number. The description does not need to add parameter details, so 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?

The description clearly states the tool produces the structured argument of one specific paper: claims, premises, machinery, and falsifier, in argument order. It is more specific than the title and gives the output shape, but it does not explicitly differentiate itself from overlapping siblings like get_claims or get_falsifier.

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 explicitly says 'Use this for requests about...' and enumerates relevant topics: claims, premises, reasoning, logical structure, conclusion. This gives clear when-to-use context, though it does not state when not to use it or name alternatives for excluded cases.

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 a safe read-only, idempotent, open-world operation, so the bar is lower — yet the description still adds real value: it requires a personal key, warns results count against a daily allowance, and discloses that candidates are retrieved by meaning so differently-worded answers can be missed. These are exactly the operational and reliability facts an agent cannot infer from 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?

Four sentences, each carrying distinct load: capability+output, invocation trigger, retrieval caveat, and resource requirements. Capability is front-loaded and there is 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?

With an output schema present, the return shape needn't be restated, and annotations cover the safety profile. The description fills the remaining gaps — auth, rate allowance, and retrieval reliability — so an agent has everything needed to call it 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 description coverage is 100%, so both the 'question' (yes-or-no, 15-600 chars) and 'field' (arxiv category, empty = all fields) parameters are already fully documented. The description adds only marginal framing about the question's scope, 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 ('read the papers closest to a question'), defines the field-wide scope, and specifies the per-paper output (yes/no/not-addressed with the deciding sentence quoted). It is clearly distinguishable from single-claim siblings like check_claim by the 'across a field' framing, though it never names an alternative tool explicitly, which keeps it out of 5 territory.

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?

'Call when a user asks whether something holds across the literature' gives a clear usage trigger, and the semantic-matching caveat tells the agent when results may be incomplete. It stops short of the explicit when-not/named-alternative guidance that would earn 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?

The description adds substantial behavioral context beyond the annotations: candidate selection is based on title/abstract matching plus connected records, paraphrased claims can be missed, and an empty result is not evidence of absence. It also reports a validation statistic, giving the agent useful calibration information without contradicting the readOnly/openWorld 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?

Every sentence earns its place: the first defines the core behavior, the second gives usage triggers, the third explains candidate selection and a key limitation, and the fourth provides validation evidence. The most important information is front-loaded and there is no fluff.

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 tool's complexity, the rich output schema, and the annotations, the description is complete. It covers when to use it, what it returns, how candidates are selected, the open-world limitation, and evidence of reliability. Nothing needed for correct invocation 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 the parameters are already documented. The description adds context about what a 'statement' is used for, but it does not add new semantic detail about the limit parameter beyond the schema's range and default. This meets the baseline without exceeding it.

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 names a specific verb, resource, and output: checking a scientific statement against arXiv papers and returning support, contradiction, or undecided verdicts with quoted claims and confidence. It clearly distinguishes the tool's question-answering role from sibling tools like search_claims or 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?

The description gives explicit trigger conditions: call before asserting a scientific result, when the user asks whether something is established/disputed, or when sources disagree. It does not explicitly name alternative sibling tools or state when not to use them, so it falls just 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?

Beyond the annotations, the description discloses authentication needs ('Needs a personal key') and a rate constraint ('counts against a daily allowance'). It also describes the key output behavior: flagging retracted works and quoting contesting sentences for arXiv citations.

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 are tightly front-loaded: capabilities first, usage second, operational constraints third. Every sentence earns its place without repetition or 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?

With an output schema present, the description need not explain return values. It covers the operation, when to call it, authentication, rate limits, and key behavioral outcomes, making it complete for this single-parameter tool.

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 input schema has one parameter with 100% description coverage, so the schema already defines that 'text' is the draft's reference list. The description does not add syntax or format details beyond what the schema provides.

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 specific verbs and resources: resolving each reference in a draft, flagging retracted works, and checking arXiv citation support/contestation. The scope 'each reference in a draft' distinguishes it from sibling tools like verify_citation or resolve_paper that act on individual papers or citations.

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: 'Call before a submission or when a user wants their reference list checked.' However, it does not explicitly state when not to use it or name alternative sibling tools for comparison.

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, and non-destructive behavior. The description adds valuable interpretive context beyond annotations: an edge means the paper names the other work, not that the work supports the citing claim. It also notes that citing sentences appear only 'where a record exists', setting expectations for incomplete data.

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 two sentences with no filler. It front-loads the core operation ('One hop from a paper'), lists the returned components, and ends with an important caveat. 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 output schema and rich annotations, the description is complete for a citation-neighborhood exploration tool. It covers what is returned, the edge semantics, and the conditional presence of citing sentences. No essential calling information 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 the schema already documents arxiv_id, limit, and direction. The description does not need to add parameter details, and it does not attempt to. It gives no extra meaning beyond what the schema provides, matching the baseline for 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?

The description states exactly what the tool returns: one hop from a paper, including reference entries, resolved work identities, citing papers, and citing sentences with labeled intent. This clearly distinguishes it from sibling tools like get_record or resolve_paper.

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 phrase 'One hop from a paper' implies this tool is for exploring immediate citation graph neighbors, and the description clarifies what an edge does and does not mean. However, it does not explicitly state when to prefer this tool over alternatives like find_passages or paper_bridge, nor does it mention 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, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: it explains that results include probability and paper, that records are tiered (abstract vs full-text), and which roles are available at each tier. No contradictions with annotations exist.

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 tightly written sentences deliver the core purpose, output contents, and role coverage distinctions with no filler. The main behavior is front-loaded, and 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?

For a read-only, idempotent lookup tool with a complete input schema and an output schema, the description covers what an agent needs: what is searched, what is returned, and which roles exist per record tier. Nothing critical is missing for correct invocation.

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 fully documents all four parameters. The description adds some semantic color by tying roles to record tiers and indicating that output includes probability/paper, but it does not need to compensate for missing parameter documentation.

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 names a specific verb ('Find'), a specific resource (author sentences labeled with one role across stored records), and clarifies output contents (probability and paper). It is clearly distinguishable from sibling tools like search_claims or get_claims, which target different search or retrieval semantics.

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 implies the tool is for retrieving passages by role, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. An agent must infer usage solely from the role-based search framing.

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 declare read-only, idempotent, and non-destructive behavior, so the description's extra context about ledger contents and argument ordering adds genuine value. It does not contradict any annotation and discloses the ordering behavior, which is not present in the 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 description is a single, tightly packed sentence with no filler. The key alias relationship is front-loaded, followed immediately by the return contents and ordering constraint.

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, read-only alias with an output schema and comprehensive annotations, the description fully covers what an agent needs to select and invoke the tool. It names the sibling it duplicates and summarizes the returned structure without needing to restate schema details.

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 input schema provides 100% coverage for the single arxiv_id parameter, including accepted forms such as bare IDs, URLs, DOIs, and Pith Numbers. The description adds no parameter-specific meaning, so the baseline of 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?

The description specifies exactly what the tool returns: the claim ledger for a paper, including premises, machinery, and falsifier, in argument order. It also clarifies its relationship to analyze_paper_claims by naming it as an alias, which prevents confusion with the many sibling tools.

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?

By explicitly labeling itself an alias of analyze_paper_claims, the description tells the agent that this tool is interchangeable with that sibling. It does not provide explicit when-not-to-use conditions, but the alias relationship gives clear contextual guidance for selecting 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the fact that it returns the same falsifier and watcher count as get_paper_falsifier, which is mild useful context, but it does not disclose any additional behavior beyond what annotations and the output schema already imply.

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 a single short sentence that states alias status and return equivalence without unnecessary filler. It is concise and front-loaded, though slightly cryptic because it assumes familiarity with get_paper_falsifier and the term 'watcher count'.

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 only one parameter, a complete schema, an output schema, and rich annotations, so the description does not need to explain much. However, the description is not fully standalone: it points to get_paper_falsifier without defining what a falsifier or watcher count is, and there is no guidance for when fetching a falsifier is relevant among the many siblings.

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 input schema has 100% coverage for the single parameter arxiv_id, including acceptable forms such as bare arXiv ID, URLs, DOI, and Pith Number. The description adds no parameter-level meaning, so the baseline of 3 applies because the schema already carries the full semantic 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?

The title states the operation: 'Get a paper's falsifier', and the description clarifies that it is an alias of get_paper_falsifier and returns the same falsifier and watcher count. This makes the resource and action reasonably clear, though it still relies on the term 'falsifier' being understood from context.

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 context by identifying the tool as an alias of get_paper_falsifier, implying it should be used whenever that sibling would be used. However, it does not explain when getting a falsifier is appropriate relative to the other sibling tools, and provides no exclusions or alternative selection 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the tool's safety profile. The description adds no contradictions. It provides a bit of extra behavior: the tool not only gives the falsifier but also 'how many people are watching for that result.' This is useful contextual information beyond the annotations, though it doesn't go deep into side effects (which are minimal given the hints).

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 a single, well-structured paragraph that front-loads the core output (falsifier and watcher count) and then gives clear usage guidance. Every sentence adds value: the first defines the purpose, the second specifies when to use it. No fluff or redundancy.

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-parameter read-only tool with a rich output schema and annotations covering safety, the description is complete. It clarifies the tool's focus (core claim), the type of result (observation/experiment/computation), and includes the watcher count. There's no missing information an agent would need to select and invoke this tool 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 description coverage is 100%: the parameter 'arxiv_id' is fully documented in the schema, covering all accepted input forms. The description does not introduce new parameter details, which is fine given the schema's completeness. It mentions 'one specific paper's core claim' but that's about the tool's behavior, not the parameter. 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?

The description clearly states the tool's purpose: to retrieve the falsifier (test, observation, or computation) for a specific paper's core claim, along with the count of watchers. It uses specific verbs and resources, and it is distinct from sibling tools like 'get_falsifier' (likely broader) and 'get_claims' (lists claims). The description explains the exact scope and what it returns.

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 explicit when-to-use guidance: when the user asks what would falsify the paper, prove it wrong, test its central claim, settle the claim, or show that the conclusion fails. This clearly routes an agent away from siblings like 'get_claims' or 'analyze_paper_claims'. It does not state when not to use it, but the list of user intents is specific and sufficiently differentiating.

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 mark the operation as read-only, idempotent, and non-destructive. The description adds behavioral context beyond that: no sentence was written by a model, every label carries its probability, and the record includes what was not stated or examined. It does not discuss auth, errors, or rate limits, but those are not critical for a read-only retrieval tool.

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 longer than average but front-loads the core purpose before giving a detailed inventory of what the record contains. The final sentence about accepted identifiers is somewhat redundant with the schema, and the long middle list could be tightened, but overall the structure is readable and informative.

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 single fully described parameter, the presence of an output schema, and read-only annotations, the description is complete for an agent: it says what the tool returns, what it is for, when to prefer it over get_review, and what inputs it accepts. Nothing essential 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 arxiv_id parameter description already enumerates accepted forms in detail. The description only restates this at a higher level ('Accepts an arXiv id or URL, DOI, or Pith Number'), adding no new meaning beyond the schema, so 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?

The title and first sentence define the tool as retrieving a single paper's compiled record, with the description clarifying that it contains the authors' own sentences arranged with typed labels. It clearly differentiates from siblings like get_review by emphasizing that this is the paper's stated content, not a review.

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 explicitly says 'Use this for what a paper states and under what conditions' and names the alternative fallback case: when get_review reports no review. This gives an agent a clear selection rule and distinguishes it from the most relevant sibling.

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, idempotent, and non-destructive behavior. The description adds useful context beyond that by stating what data is returned and that the calibration record is conditional ('when present'). It does not discuss edge cases like missing reviewers, but the output schema and simple read-only nature reduce that burden.

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 carry the full message: the first defines the return content and its conditional part, the second gives the invocation trigger. There is no filler, repetition of schema fields, or unnecessary context.

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 read-only tool with an output schema, the description covers what is returned in terms of content that matters for selection and invocation. It does not mention not-found behavior or alternative sibling tools, but those are not essential for correctly choosing and calling this tool.

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 has a single required handle with 0% description coverage. The description compensates by implying the handle is a named Pith reviewer's identifier and tying it to the user's question about trustworthiness. It could explicitly state that handle is the reviewer's handle, but with only one parameter the inference is strong.

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 identifies the resource (a reviewer's record) and specifies its contents: published signed reviews plus an optional calibration record with Brier score, open predictions, and positivity skew. It is clear and concrete, but it does not explicitly distinguish itself from sibling tools such as get_signed_reviews or get_record.

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 provides an explicit trigger: call this when the user asks about a named Pith reviewer or about how trustworthy a reviewer's track record is. It lacks when-not-to-use guidance or named alternatives, 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that the reviews are published, human-signed, and include specific components, but it does not disclose additional behavioral traits such as error cases, pagination, or permission requirements. This is acceptable given 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 two focused sentences: the first enumerates the returned content, the second states when to use the tool. Every phrase earns its place, and the most important identifier ('published human signed reviews of one paper') is front-loaded. No redundant or vague wording.

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 simple one-parameter read-only lookup with a rich output schema and full annotations, the description is complete. It specifies the input form, the scope ('one paper'), the nature of the data, and the invocation condition. Nothing essential for selecting or calling this tool 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 arxiv_id parameter description thoroughly explains accepted forms (bare arXiv id, abs/pdf URL, DOI, Pith Number). The tool description does not add parameter-level detail, but with full schema coverage the baseline of 3 is appropriate; no compensation is needed.

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 names a specific verb and resource: getting published human signed reviews for one paper, then enumerates the contents (reviewer identity, axis deltas, claim verdicts, defects, predictions, payment). It also distinguishes this from machine-review tooling by emphasizing 'human' and 'on top of the machine review.' This clearly separates it from sibling tools like get_review and get_claims.

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 an explicit trigger condition: 'Call this when the user asks what human experts said about a paper, on top of the machine review.' This tells an agent when to select the tool, though it does not explicitly name alternatives or state when not to use it. Clear context is present, but exclusion guidance 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 indicate a safe, idempotent read operation. The description adds useful behavioral details beyond annotations: results are newest first, and days caps the lookback window with a maximum of 90. This is meaningful additional 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?

Two tightly written sentences place the core behavior first, then the trigger context, then the critical days constraint. No filler or redundant restatement 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 simple read-only list tool with an output schema, the description covers the key trigger, ordering, and time-window constraint. It could mention what limit does or how category interacts with the results, but those are partly documented in the schema itself.

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 only 33%, with the category parameter already explained in the schema. The description adds semantics for days (caps lookback, max 90), but says nothing about limit or category behavior. Partial compensation for the low coverage, but not complete.

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: lists the papers Pith reviewed most recently, newest first. It also clearly separates this from general search tools by emphasizing recency and recency-based ordering.

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 explicitly says when to call this tool: when the user asks what is new, notable, or recently reviewed in a field or overall. It does not name alternative sibling tools or exclusion conditions, but the trigger context 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 already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: it operates only on papers claimed by the account behind the key and it 'Needs a personal key,' which is an auth prerequisite an agent must satisfy before calling.

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: purpose and payload first, then the call trigger, then the key requirement. No filler and the most decision-relevant information is front-loaded.

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 documentation is not required, and the description still summarizes the shape of the response. Combined with the auth note and scope definition, an agent has everything needed to decide and 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?

The tool takes zero parameters, so the schema carries nothing to explain and the baseline is 4. The description correctly introduces no parameter discussion and instead clarifies the implicit scope (papers claimed on the account) that substitutes for an input filter.

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 ('how many papers cite each' of the user's claimed papers) plus the exact payload (counts, citation stance as support/extension/disagreement, quoted citing sentence). This is clearly distinguishable from siblings like citation_neighbors or verify_citation, which operate on arbitrary papers rather than the account's claimed set.

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?

Explicit trigger is given: 'Call when the user asks who is building on or disputing their work.' The account-scoped framing also implicitly excludes general citation lookups, though no sibling alternative is named for the case where the user asks about citations to a paper they have not claimed.

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 behavior, so the description's real contribution is the authentication requirement (personal key) and the fact that results are grouped per claimed paper with a verdict plus a count. That is genuine context beyond the annotations, though nothing is said about rate limits or empty-result behavior.

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 with the resource stated first and the key requirement last; no waste. The line breaks are cosmetic and the second sentence is a bare prerequisite clause rather than a polished guideline, but nothing 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?

With an output schema present, return shape need not be described, yet the description still sketches what comes back (verdict and count per paper). For a no-parameter, read-only tool this is essentially complete; only the distinction from sibling review tools is thin.

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 is 4. The description correctly frames the implicit input (the account behind the key) rather than inventing parameters, which matches the empty 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?

Names a concrete resource (machine review verdict plus count of published signed human reviews) scoped to papers claimed on the caller's account. It distinguishes itself from the general reader siblings by the account-scoping phrase, though it does not explicitly contrast with get_review, get_signed_reviews, or latest_reviews.

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 only guidance is the prerequisite 'Needs a personal key,' which is useful but not a when-to-use rule. Nothing tells the agent when to prefer this over get_signed_reviews or latest_reviews, so usage is only implied.

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 mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail by specifying the three relationship categories returned and that common references include both arXiv and non-arXiv works.

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?

A single sentence efficiently captures the full purpose and all output categories without wasted words. The most important information is front-loaded.

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 structure does not need explaining. The description covers the core semantics and edge-worthy inclusion of non-arXiv references, but does not mention practical nuances like limit handling or empty-result cases, though these are likely covered by 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?

Schema coverage is 100%, so the parameters are already well documented. The description adds conceptual context about a and b being the two papers being compared, but does not need to add more since the schema is complete.

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 enumerates three specific, distinct outputs: direct citation between the two papers, resolved works both cite, and citing papers that cite both. This makes the tool's purpose concrete and distinguishes it from single-paper tools like citation_neighbors.

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 pairwise framing ('two papers', 'both') implies this is for comparing exactly two papers, but there is no explicit statement of when to choose this over citation_neighbors or paper_packet, nor any 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 (read-only, idempotent, non-destructive), so the bar is lower. The description goes beyond them by disclosing label provenance (Pith's classifier on LaTeX source), display thresholds (0.8/0.95/0.7), how sub-threshold labels become 'unlabelled', and a measured-agreement URL — genuinely useful 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?

The purpose and category list are front-loaded well, but the long parenthetical threshold sentence and the external agreement URL make it denser than needed. Much of the classifier-provenance detail could be trimmed without losing selection value.

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 documentation is unnecessary. For a read-only analysis tool the description covers the classification semantics, thresholds and usage condition adequately; only the relationship to sibling tools remains 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 the schema already documents both parameters fully. The description only alludes to quoted sentences per group and accepted id forms without adding format or syntax detail, 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?

The description states a specific resource and relation type: what other arXiv papers do with this paper and vice versa, broken into named intent categories (builds on, uses method, compares with, contests). It is clear enough to distinguish from a plain citation listing, though it does not explicitly contrast itself with the sibling citation_neighbors.

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 closing sentence gives one usage condition: 'Use this for how a result has been taken up, challenged or built on across arXiv.' There are no explicit exclusions or named alternatives, so the routing guidance is implied rather than directive.

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 read-only, idempotent, non-destructive behavior. The description adds value by disclosing that lists may be capped and that totals are included so a capped list is not mistaken for the whole paper, and by noting that full-text records include conditions, measurements, results, and limitations.

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?

A single dense, front-loaded sentence that opens with the core object ('One paper's compiled record') before enumerating contents. There is no filler, tautology, or redundant restatement 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?

With read-only annotations and a full output schema, the description covers the packet's composition, the abstract-only vs full-text distinction, and the capping/totals behavior. This is sufficient for an agent to select and invoke the tool 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 description coverage is 100%; both arxiv_id and limit have explicit descriptions, so the description adds little parameter-level detail. The mention of capped lists and totals loosely relates to the limit parameter but does not expand on schema semantics.

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 title provides a specific verb ('Read') and resource ('one paper's record packet'), and the description enumerates a distinctive set of contents: main claim, abstract sentence roles, paper-level labels, and full-text metrics. This clearly distinguishes it from sibling search, citation, and review tools.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternatives are named. The phrase 'small enough to hold beside others' implies a comparison/compaction use case, but the agent must infer when to choose this over get_record, resolve_paper, or search_papers.

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, and non-destructive behavior, so the description adds value beyond those hints by clarifying what an empty result actually means: nothing in the examined scope matched, consistent with openWorldHint=false. No contradiction with 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?

Two sentences, each earning its place: the first defines what the tool reports, the second warns about empty-result interpretation. No wasted words and the key usage warning is placed where it will be noticed.

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, read-only tool with an output schema present, the description is complete. It covers scope selection, empty-result interpretation, and relies on the schema for parameter details.

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% — the schema already explains arxiv_id as 'One paper, or empty for the whole record store.' The description reinforces this semantic but does not add much beyond what the schema already provides.

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 identifies the resource ('sources read', 'levels run', 'stored records by tier') and the scope distinction between one paper and the whole store, making the purpose clear. It lacks an explicit command verb and never contrasts with sibling tools, 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?

'Call before treating an empty result as a finding' is explicit, actionable guidance for when to use this tool. It gives clear context but does not enumerate alternatives or exclusions relative to sibling tools.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the key behavioral detail that 'resolved' is false when the input did not become an arXiv id, which is important for agents to know how to interpret the 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 with no wasted words. The core purpose is front-loaded, and the failure-mode note ('resolved' is false) is a valuable addition that 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?

For a single-parameter, read-only, idempotent tool with a full schema and output schema, the description is nearly complete. It could explicitly state that the output is the arXiv id string, but the phrase 'into the arXiv id' plus the output schema covers this. The failure-mode disclosure is the most valuable contextual addition.

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 the 'reference' parameter thoroughly. The description adds a small amount of context by listing the accepted formats, but this largely mirrors the schema's parameter description. 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?

The description states a specific verb ('Turn') and resource ('a pasted arXiv id, arXiv URL, DOI, or Pith Number') and clearly defines the output ('the arXiv id the other tools key on'). It distinguishes itself from siblings by explaining that this is the normalization step for other tools.

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 implies when to use this tool: when you have a reference in one of the listed formats and need the canonical arXiv id. It doesn't explicitly name alternatives or exclusions, but the sibling list shows other paper-related tools, and the description's 'the other tools key on' makes the routing 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 declare readOnly, idempotent, and non-destructive behavior, so the description adds value by disclosing the search scope ('every scientific claim Pith has extracted, across all reviewed papers') and the result composition ('paper, verdict, and review link'). No contradiction with 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?

Three tightly structured sentences with no filler: scope first, usage triggers second, output summary third. 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?

For a two-parameter search tool with safety annotations and an output schema, the description covers the essential call-time decisions: scope, when to invoke, and what results contain. It does not discuss pagination or ordering, but those are minor given the output schema presence.

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 already documents the query parameter as a plain-word statement, and the description's trigger examples add context for what to put in query. However, limit is left undocumented in both the schema and description beyond its type and default, so parameter enrichment is incomplete.

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: full-text search over extracted scientific claims across all reviewed papers. It clearly distinguishes itself from sibling tools like search_papers and find_passages by focusing on claims, and states what the tool returns.

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 explicitly tells the agent when to call it: when the user asks who claims something, whether a claim appears in recent literature, or what evidence bears on a statement. It does not enumerate alternatives or state when not to use it, which prevents 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 establish that this is read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral detail by saying results carry the paper's verdict, summary, and review link. No contradictions or hidden behaviors are apparent.

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 focused sentences, with the core action front-loaded and no filler. Each sentence adds distinct value: what is searched, when to use it, and what results contain.

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 lightweight read-only search tool with only two parameters and an output schema, the description covers the invocation trigger, search scope, and result contents. Nothing essential is missing for an agent to call this tool 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 only 50%: the query parameter is described well in both schema and description, but the limit parameter has no description in the schema and is not mentioned in the description. The description reinforces query intent but does not add meaning for limit or explain its effect on results.

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 names a specific action ('Search Pith-reviewed papers') and a clear resource ('papers by title and abstract'). It also gives concrete user intents (topic, phenomenon, method, paper title) that map to this tool, distinguishing it from sibling claim/passage/citation tools.

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 explicitly states when to call the tool: when a user names a research topic or asks whether Pith has reviewed a subject. It also provides an exclusion ('without an identifier'), but it does not name alternatives like search_claims or resolve_paper, so the routing guidance is good but not 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds value by detailing that it reads the paper's abstract and full text where available, and that the 'examined field' indicates which source was used. The inclusion of the validation statistic (139/160 agreement) further sets expectations about reliability, which goes beyond the structured metadata.

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 logically organized: it starts with the core function and verdict types, then usage guidance, then source details, and ends with a performance note and link. While it contains some extra detail (the evaluation statistic), it remains concise and front-loaded. Every sentence adds information, though the length could be trimmed slightly without losing substance.

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 description covers the essential aspects: what the tool does, when to use it, and what sources it consults. Since an output schema exists (as indicated by the context signal), it correctly avoids explaining return values. The one minor gap is that it doesn't explicitly state what happens if the paper isn't found or if the sentence isn't a citation, but overall it is sufficiently complete for reliable invocation.

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% for both required parameters (sentence and cited), and each has a descriptive explanation (e.g., cited accepts multiple forms). The tool description adds little beyond this—it implies the sentence is a citation context, but that's already in the schema. Thus, the baseline of 3 is appropriate because the description does not meaningfully enhance parameter understanding.

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 ('verify') and resource (citation support) and enumerates the exact output categories (supports, partly supports, contradicts, not addressed). It also includes a concrete usage context ('before citing a paper'), which helps distinguish it from sibling tools like check_claim or analyze_paper_claims, even without naming them.

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 explicit when-to-use scenarios: 'before citing a paper for a specific claim, or to check a citation in a draft or an answer.' It does not mention alternatives or exclusions, but the stated use cases are clear and actionable, making it easy for an agent to decide when to invoke this tool.

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