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 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: each result includes probability and paper, and available roles differ between abstract-tier and full-text records.

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 short, front-loaded, and every sentence contributes meaning. Minor awkwardness in the phrase 'sentences Jev labeled' slightly hurts readability, but there is no wasted text.

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

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

For a read-only tool with full schema coverage and an output schema, the description covers the key invocation needs: scope, returned data, and role availability by tier. The ambiguous 'Jev' reference and lack of guidance on combining query and arxiv_id are minor gaps.

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

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

Schema description coverage is 100%, so all parameters are already documented at the schema level. The description adds role-tier context but no per-parameter semantics that the schema does not already provide, 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?

The description states a specific verb and resource: find author sentences labeled with a role across every stored record. It clearly conveys the tool's scope and output fields, making it distinguishable from sibling claim/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?

The role-based scope and record-tier coverage give clear implied usage context. However, the description does not explicitly name alternatives or state when to prefer this tool over siblings like search_claims or get_claims.

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 declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond this: results are pre-extracted, require no PDF reading, and are returned in one call, which tells the agent about the tool's effort and completeness characteristics.

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 names the output, the second explains the benefit and usage context, and the third covers input flexibility. The most important scoping information is front-loaded with no filler 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?

With a single parameter, rich annotations, and an output schema present, the description is complete for correct invocation. It tells the agent what the tool returns, when to use it, and which input forms are accepted, leaving no critical gap.

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 baseline applies. The description restates the accepted input forms ('Accepts an arXiv id or URL, DOI, or Pith Number') but adds little meaning beyond what the schema already documents for arxiv_id.

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 uses a specific verb and resource: 'Pith's review of one specific paper, in one call.' It enumerates the exact content returned (verdict, scores, summary, weakest assumption, structured argument), which clearly separates it from sibling tools 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?

The description explicitly states when to use it: 'Use this for any question about a specific paper' and lists concrete question types. It does not explicitly name sibling alternatives or say when not to use it, so it is clear context without 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 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 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explains that full-text records include conditions/measurements/results/limitations and that totals are included so a capped list is not mistaken for the whole paper. 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?

One dense, well-structured sentence front-loads the core purpose ('one paper's compiled record') before itemizing contents. Every clause contributes information about what the agent will receive, with no filler or repetition of schema details.

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 and strong annotations, the description provides sufficient detail about packet composition and the full-text vs. non-full-text distinction. It lacks explicit sibling differentiation, but that gap is more about usage guidance than completeness for invoking 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?

Schema coverage is 100% and the schema already describes arxiv_id formats and the limit range, giving a baseline of 3. The description adds value by tying the limit behavior to the packet's capped lists and explaining that totals prevent misinterpretation, which clarifies what the limit parameter actually controls.

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

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

The description clearly identifies the tool as returning one paper's compiled record and enumerates the packet contents: the authors' claim/contribution, abstract sentence roles and probabilities, paper-level labels, and full-text evidence. It goes well beyond the title, though it does not explicitly contrast itself against siblings like get_record or paper_bridge.

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 'small enough to hold beside others' and the detailed contents imply this is for reading and comparing compact per-paper records, but there is no explicit when-to-use/when-not-to-use guidance or named alternatives. Usage context is present only by implication.

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.