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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral boundary — the output is phrase-level screening, not a validated risk-of-bias or statistical assessment — which helps an agent avoid misusing the result. It says nothing about input requirements, safety profile, or what the screening returns, leaving substantial behavioral gaps.

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 single-sentence fragment is brief but under-specified rather than concise — it spends its only content on exclusions and never describes the action. Front-loading the scope limitation is good, but the definition is too thin to earn 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?

In a dense sibling set with multiple audit and statistical-checking tools, no annotations, no output schema, and 0% parameter documentation, the description should do far more. It usefully carves out a niche versus audits but omits return format, expected input content, and any usage conditions.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. It offers no indication of what source_text should contain (abstract? full paper? methods section?) or what source_id refers to, despite source_text format being critical for a screening tool.

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 operation as 'transparent phrase screening,' which gives some sense of scope and distinguishes it from heavier siblings like audit_methodology and check_statistical_reporting. However, it never states a concrete verb-plus-resource ('screens methodology phrases in a source text') or what the screening produces, so the purpose is only implied.

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 'NOT a RoB-2, GRADE, or statistical audit' clause effectively signals when this tool is the wrong choice and implicitly routes the agent toward audit_methodology/check_statistical_reporting. It never states when this tool IS the right choice or names those alternatives explicitly, so guidance is only half-present.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful limits: it verifies quote-to-text traceability and explicitly does not scientifically validate labels. However, it omits other behavioral facts an agent needs, such as whether the operation is read-only, what it returns, and how mismatched quotes are reported.

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

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

Three short, front-loaded statements with no filler; the core purpose leads and the caveats follow. The fragmented line breaks are mildly awkward but do not impede comprehension.

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 tool with five required parameters, an untyped nested annotations array, no output schema, and no annotations, the description is under-specified. While the scope-limiting caveats are useful, an agent still lacks parameter semantics and any sense of the return shape 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 0% across five required parameters, so the description must compensate but largely does not. It loosely maps to a few fields ('outcome-specific', 'user-annotated', 'supplied raw text') but gives no meaning for study_id or study_design and no format for the annotations array, leaving most parameters undocumented.

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

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

States a specific verb (audit) and resource (traceability of methods evidence, with quotes checked against raw text), so the agent knows this is a traceability-verification tool rather than a validity assessor. It does not, however, distinguish itself explicitly from close siblings like audit_pmc_methodology or assess_methodology, leaving that separation to inference.

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

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

The description carves out a clear boundary ('Quotes are checked against supplied raw text', 'Labels are never scientifically validated'), which implicitly tells the agent this is a limited scope-check rather than a full appraisal. But it never states when to choose this over audit_pmc_methodology or assess_methodology, nor any prerequisites, 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that it pulls external Europe PMC XML and that no scientific conclusion, risk-of-bias judgement, or absence claim is inferred, which meaningfully bounds interpretation of results. It still omits auth requirements, failure behavior when a PMC ID is invalid, and what the validation result contains.

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, front-loaded with the action before the limitation. The second sentence is a slightly awkward fragment, but nothing is padded or wasted.

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?

A tool taking four required, undocumented arguments with no output schema and no annotations needs more than two sentences. The description never explains the annotation format, what 'outcome' and 'study_design' should contain, or how validation findings are returned.

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?

All four parameters are required with 0% schema description coverage, and the description mentions none of them. The non-obvious 'annotations' array of free-form objects and the 'outcome'/'study_design' strings are left entirely unexplained in both the schema and the prose.

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 two specific actions (fetch Europe PMC XML, validate user annotations) against a concrete resource (direct JATS paragraphs), which is far more informative than a bare 'audit' label. It does not, however, distinguish this from the sibling 'audit_methodology', so an agent cannot tell the two apart from the text alone.

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 statement of when to use this tool versus the similarly named audit_methodology, no prerequisites, and no conditions that select it over alternatives. The only scoping present is a negative claim about what is not inferred, which bounds output rather than guiding selection.

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

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

With no annotations, the description carries the full burden and does add one important caveat: it 'never certifies scientific support.' That is useful guardrail context. It still omits whether the operation is read-only, deterministic, local-only, or how top_k affects behavior and return size.

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 compact sentence with no filler, and the key caveat is placed at the end. It is appropriately sized, though its terseness contributes to the ambiguity elsewhere.

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

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

For a 3-parameter tool with no annotations, no output schema, and 0% schema description coverage, one sentence is not enough. The description leaves the return shape, ranking behavior, and parameter semantics largely unexplained.

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

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

Schema description coverage is 0%, so the description must compensate but does not. It implies that documents are caller-supplied abstracts, but it does not explain the query parameter or the top_k parameter at all.

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 algorithm (BM25) and the input class (caller-supplied abstracts), which helps distinguish it from retrieval-oriented siblings. However, it never states the actual action explicitly (e.g., 'ranks documents by query relevance'), so the purpose is only implied rather than clearly stated.

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 word 'Opt-in' is the only usage hint and does not explain when to choose this tool over alternatives like search_literature or compare_studies. There is no guidance on preconditions, exclusions, or expected workflow.

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

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

No annotations are provided, so the description carries the full burden. It does not say whether validation persists anything, what a failure looks like, what makes a graph valid, or what 'traceable evidence identifiers' must conform to. The name/description tension between 'build' and 'validate' further obscures whether this is a read-only check or a mutation.

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 front-loaded sentence with no padding, so it is structurally efficient. The problem is under-specification rather than verbosity, which caps the score at adequate.

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?

A graph-building/validation tool with no annotations, no output schema, and zero parameter documentation needs a far richer description. Nothing tells the agent the expected graph shape, the validation criteria, or what is returned.

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

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

Schema description coverage is 0% and both parameters are unconstrained arrays of arbitrary objects (additionalProperties: true). The phrase 'traceable evidence identifiers' is the only hint at expected node/edge content, and it is far too vague to compensate for the missing schema documentation of two required parameters.

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: validate an evidence graph with traceable evidence identifiers. However, the tool NAME says 'build' while the description says 'validate' — an agent cannot tell whether this constructs or only checks a graph. It also does nothing to distinguish itself from close siblings like verify_evidence_ledger or export_evidence.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. With siblings such as verify_evidence_ledger and verify_claim in the same family, the agent is given no basis for choosing this tool over them.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one important trait: the two upstream data sources consulted and the fact that a null result cannot be treated as confirmation of validity. It says nothing about authentication, rate limits, latency, or how a hit is reported.

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 tight sentence with no filler, and the caveat is placed where it will be read. It is dense and jargon-heavy ('update-to'), but 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?

There is no output schema, so the description should ideally describe what a positive hit looks like; it only frames the negative case. The absence-inconclusive note is valuable, but return-shape and source-precedence details are missing for a tool whose whole value is its answer.

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

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

Schema description coverage is 0% and the single 'doi' parameter is never mentioned in the description, so it adds no syntax or format guidance (e.g., bare DOI vs. URL form). The parameter name is self-explanatory enough that this is a moderate rather than severe gap.

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 (Inspect) and a well-defined resource (Crossref update-to and Retraction Watch-linked updates), which is enough to separate it from siblings like verify_citation or get_paper. It stops short of naming the input (a DOI) or the output, so it is clear but not maximally so.

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 clause 'absence is inconclusive' is a genuine interpretive caveat that tells the agent how to read a negative result, which implies when this tool is worth calling. However, it never states when to prefer this over verify_citation or get_paper, nor any prerequisite or sequencing 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only detection pass but never states whether anything is mutated, what permissions are needed, what the output looks like (no output schema exists), or how many records it can handle — none of the behavioral traits beyond the one-sentence scope are disclosed.

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

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

A single front-loaded sentence with the core scope stated first and the exclusion tacked on efficiently. Every clause earns its place; nothing is padded.

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 tool this is a thin but workable definition. The hint about which statistical quantities matter partially compensates for the completely opaque record schema, but with no annotations and no output schema, the agent still lacks enough to construct correct input records with confidence.

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

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

Schema coverage is 0% with a single untyped array-of-objects parameter (additionalProperties: true, no defined keys), so the description must explain what a "record" must contain. It hints at the relevant fields (p values, CIs, sample sizes) but never states the expected key names, required vs optional entries, or the record structure an agent must build.

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 ("Find") and a precisely bounded resource ("mechanically inconsistent p values/CIs/sample-size entries"), then distinguishes itself from broader siblings like assess_methodology by excluding semantic judgment ("not test results"). An agent can tell this apart from the other audit tools without opening any schema.

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

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

The phrase "not test results" gives an explicit when-not boundary, steering the agent away from using this for interpreting or assessing findings. However, it names no concrete alternative sibling to route to when the task actually is about test results, so guidance is clear but not fully actionable.

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

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

With no annotations, the description carries the full behavioral burden and largely fails: it does not say how comparison is performed, whether the operation is read-only, what permissions or input validity are required, or what the result looks like. The only disclosure is a negative scope constraint (no inferred theoretical disagreements), which is useful but thin.

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 short, front-loaded sentence with no filler, so there is nothing to trim. However, the brevity is closer to under-specification than to disciplined conciseness for a tool with an opaque nested input.

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 one structurally undefined parameter, no output schema, and no annotations, the description should explain expected input shape and return behavior. It explains neither, leaving the agent unable to construct 'papers' confidently or predict results.

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 single parameter 'papers' is an array of free-form objects with additionalProperties=true and 0% schema description coverage. 'Supplied bibliographic metadata' hints at expected content but gives no field names, shapes, or required keys, so the agent must guess the object structure entirely.

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 ('Compare supplied bibliographic metadata'), which is clearly distinguishable from siblings like audit_methodology or check_statistical_reporting. The scope caveat ('no inferred theoretical disagreements') further narrows intent, though no sibling is named explicitly.

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

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

The 'no inferred theoretical disagreements' clause implicitly bounds what the tool is for, but there is no when-to-use condition, no prerequisite, and no named alternative among the 16 siblings. An agent gets a limitation without a selection rule.

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

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

No annotations exist, so the description carries the full burden. It does usefully warn that heterogeneity and bias are NOT assessed, which prevents over-interpretation of results, but it says nothing about preconditions, error behavior, or what the pooling returns for sparse/one-study input.

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 compact clause with zero padding, and the caveat is front-loaded. Its brevity is achieved by omitting essentials rather than by editing, so it is concise but under-specified.

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 statistical pooling tool with an unconstrained nested input, no output schema, and no annotations, an agent cannot construct a valid call or interpret the result from this description alone. The scope caveat is the only substantive content.

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

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

Schema description coverage is 0% and the single parameter 'studies' is an untyped array of free-form objects with no item schema. The description does not say what fields each study object must contain (effect size, variance/SE?), which is the one thing an agent most needs here.

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 verb-resource pair ('fixed-effect numerical pooling') and the implementation flavor ('C++'), which hints at what it computes. However, 'Opt-in' is unexplained and the description never explicitly contrasts with the sibling cpp_random_effects, so the agent must infer the fixed-vs-random distinction itself.

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?

No guidance on when to choose this over cpp_random_effects or any other pooling path. 'Opt-in' is the only conditional signal and it is never defined (opt-in with respect to what setting or caller?).

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

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

No annotations, no output schema, and the description says nothing about required input shape (effect sizes, standard errors, study IDs), failure modes, or what the 'approximate interval' is at (e.g., 95%). It does imply leave_one_out triggers per-study exclusion, but that is the only behavioral disclosure.

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?

Extremely short and front-loaded, with zero filler, but it is a noun-phrase list rather than structured prose, so the terseness tips into under-specification rather than clarity.

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

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

For a statistical estimator with no annotations, no output schema, and zero parameter documentation, the description is far too thin; an agent cannot reliably construct the studies payload or interpret the returned interval.

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

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

Schema coverage is 0% with 2 parameters. The description only gestures at leave_one_out ('leave-one-out'); the required studies array — the critical parameter — is left entirely undefined as to expected fields, units, or structure.

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 the statistical method (DerSimonian-Laird) and the quantities produced (Q, I², tau², interval), which lets an agent infer this computes a random-effects meta-analysis. But there is no verb or resource statement, and the sibling cpp_fixed_effect_meta is never contrasted, so the agent must infer which model to pick.

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?

No when-to-use guidance and no mention of when to prefer this over cpp_fixed_effect_meta or the other statistical siblings. The agent gets no criteria (e.g., heterogeneity) for choosing the random-effects model.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints that the tool may mutate state by flagging descendants for review, but it does not state permissions, persistence of flags, rate limits, side effects, or what happens to inputs.

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 front-loaded sentence with no wasted words. It is efficient, though its compression leaves important operational meaning underspecified.

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

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

With no annotations, no output schema, and 0% schema description coverage, the definition needs to explain parameters and side effects in detail. It instead provides only a high-level phrase, leaving an agent unable to invoke the tool confidently.

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

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

Schema description coverage is 0%, so the description must explain the two required parameters, but it never defines 'dois' or 'edges'. The phrase 'citation descendants' loosely hints at the edges parameter, but neither format nor semantics are given.

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 concrete verbs and resources: fetching Crossref publication notices and flagging citation descendants for review. It is clearer than a tautology, but it does not distinguish this tool from related siblings such as propagation_alerts or check_retraction.

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 guidance on when to use this tool, when not to use it, or which sibling to prefer for adjacent tasks like citation expansion or retraction checking. Usage must be inferred from the name and the vague phrase 'publication notices'.

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

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

With no annotations, the description carries the full burden. It usefully discloses that traversal is bounded and that edges are unverified metadata, but it omits read-only status, permissions or rate limits, and what the response contains.

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 extremely concise and front-loaded, with no wasted words. The single fragment structure is efficient but leaves important operational details implicit.

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 four parameters, no annotations, 0% schema coverage, and no output schema, the description is far too sparse. It does not explain the seed DOI, traversal depth, per-direction limits, or return shape, so an agent cannot call it confidently without opening 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 description coverage is 0%, and the description names none of the four parameters explicitly. 'Forward/backward' loosely maps to directions and 'bounded' to the max limits, but seed_doi and the exact semantics of max_depth versus max_per_direction are undocumented.

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

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

The description identifies OpenAlex citation links and forward/backward scope, but it is a noun phrase without an explicit operation or mention of the seed DOI. It partially differentiates from verify_citation by noting that edges are unverified, but the agent must infer that the tool expands a citation chain.

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 guidance, prerequisites, or named alternatives. 'Bounded' and 'unverified metadata' hint that this is exploratory rather than verification, but that routing signal is not stated directly.

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

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

No annotations exist, so the description carries the full burden. It does disclose the important behavioral fact that this is pure formatting of supplied metadata with no verification or lookup performed, which prevents misuse. It says nothing about failure modes (malformed entries), whether unknown fields are preserved or dropped, or what the tool returns.

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 compact sentence with the capability first and the exclusion second — well front-loaded and zero waste. It is telegraphic to the point that some useful detail was likely cut, but nothing present is padding.

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

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

For a two-parameter, low-complexity tool with no output schema, the definition covers the essentials of what it does and what it does not do. It is still thin on the expected shape of the input records and on the return value, which an agent must handle blind since no output schema exists.

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

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

Schema description coverage is 0%, so the description must compensate. It does spell out the three legal format values, which the schema does not (no enum is declared), giving real meaning to output_format. But 'supplied metadata' only gestures at the structure of the required papers array, and the default of bibtex is left to the schema.

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

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

Names a specific verb (export) plus the resource (supplied metadata) and enumerates the three serialization targets, BibTeX/RIS/CSL-JSON. The 'NOT scientific verification' clause clearly separates it from the verify_*/check_* siblings, though it does not distinguish it from export_evidence.

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 negative clause signals when not to reach for it (anything requiring validation or verification), which is genuinely useful routing. But there is no positive statement of when to use it, no prerequisite that metadata must already be gathered, and no pointer to export_evidence as the alternative for evidence artifacts.

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

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

With no annotations, the description must carry behavioral weight. It discloses that the operation appends to a local hash-chained JSONL ledger, which implies durable, tamper-evident, local writes. However, it omits error behavior, idempotency, permission requirements, and whether an existing chain is required.

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?

It is a single front-loaded sentence with no filler. While very short for the tool's complexity, the sentence itself earns its place and is not padded.

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 two undocumented required parameters, a nested payload object, no annotations, no output schema, and 0% schema description coverage. A single-sentence description is not enough 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 description coverage is 0% for both required parameters. The description never explains what 'kind' should contain or what shape the 'payload' object takes, leaving the agent with no semantic guidance for either argument.

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 ('Append') and resource ('JSON evidence record to local hash-chained JSONL ledger'), which is more specific than a generic 'export'. It does not explicitly differentiate from siblings like verify_evidence_ledger or build_evidence_graph, so it stops 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. The agent is left to infer that this is the write-side counterpart to verify_evidence_ledger.

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

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

With no annotations, the description carries the full burden. It usefully discloses that results are conditional on registration and that it is a lookup-only operation that does not retrieve the underlying artifacts, but it omits auth requirements, failure behavior, and return shape.

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 tight sentence with the core action front-loaded and the negative constraint appended. Nothing is wasted.

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 lookup with no output schema or annotations, the description covers the essentials: what it finds and that it will not fetch. It leaves the return format and the not-registered case underexplained, which matters since there is no output schema to fall back on.

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

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

Schema coverage is 0% and the single required parameter (doi) is never mentioned in the description. The name is fairly self-evident, but the description adds no meaning such as accepted DOI formats or whether prefix-only DOIs work, so it fails to compensate for the coverage gap.

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 Crossref links to supplements, data, or software. It clearly distinguishes itself from content-retrieval siblings like read_fulltext and get_paper by scoping to link discovery, though it never names a sibling explicitly.

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

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

"If registered" and "do not fetch them" imply when the tool is useful (locating links only, not retrieving content) and set an expectation of possible empty results. However, no alternative tool is named for the actual fetching step, so routing is left to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses the data source (Crossref) and the key limitation (no conclusion validation), which is real value, but says nothing about authentication, rate limits, or behavior on an unresolvable DOI. Adequate but incomplete for a no-annotation 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?

A single sentence with the scope claim front-loaded and the limitation attached via a semicolon. Every clause earns its place; 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?

For a one-parameter lookup with no output schema, the description supplies the data source, the retrieval target (metadata and source links), and the explicit non-goal. What is missing, return shape and failure behavior for bad DOIs, is modest given the tool's simplicity.

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

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

Schema description coverage is 0% and there is one parameter ('doi'), so the description must compensate. Calling out 'Crossref DOI' implies the identifier namespace, which is useful, but it adds no format example, prefix guidance, or resolution behavior. Partial compensation only.

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: 'Get Crossref DOI metadata and source links.' The negative clause 'does NOT validate scientific conclusions' further separates it from validation-oriented siblings such as verify_citation and verify_claim. However, it doesn't explicitly declare which sibling to use for validation, so it stops 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?

The negation ('does NOT validate scientific conclusions') implicitly signals when-not-to-use, which is useful routing against verify_claim/verify_citation. But there is no positive guidance on when to reach for this tool (e.g., 'use this to fetch bibliographic metadata before citing') and no named alternative for the validation case.

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

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

No annotations exist, so the description carries the full burden. It does disclose two real behavioral traits — a local cache and a five-second request gate (rate limiting) — which is more than nothing. But it omits what happens on a cache hit vs. a gated/throttled call, error behavior, and whether the call is a pure read.

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?

It is a single short sentence with no padding, so nothing is wasted — but it is a noun-phrase fragment rather than a structured statement, and it leads with the least informative word ("Opt-in"). Brevity here is under-specification, not efficiency.

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

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

For a 3-parameter retrieval tool with no annotations and no output schema, the description should at minimum say what is returned and from which source. It covers only caching and throttling, leaving the agent unable to predict results or distinguish this from the other retrieval 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?

Schema description coverage is 0%, so the description must compensate and it largely does not. "Local cache" loosely maps to ttl_seconds, but `query` (the only required parameter) and `limit` get no syntax, format, or matching-semantics guidance at all.

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?

"Go metadata retrieval" gestures at pulling literature metadata through a Go-implemented path, but it never says what a "record" is (paper, citation, provider metadata) or how it differs from search_literature, search_literature_extended, or get_paper. The caching/gate phrases describe mechanics, not the resource being fetched.

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?

"Opt-in" hints that this path is optional rather than default, but there is no statement of when to choose it over the several literature-search siblings listed. No exclusions, no preconditions, no fallback 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?

No annotations exist, so the description carries the full disclosure burden. It states the call is concurrent against three fixed APIs, but never says whether it is read-only, what it returns, how failures from individual providers are handled, or any rate-limit/latency implications of fan-out. That is a large gap for a fan-out network 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?

A single front-loaded sentence with no filler, but it is under-specified rather than concise — the brevity comes at the cost of the behavioral and parameter detail this tool needs.

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

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

With no annotations, no output schema, and 0% schema coverage, the description must supply everything, and it supplies one sentence. An agent cannot tell what comes back from the probe or how to interpret the query/limit pair.

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

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

Schema description coverage is 0% and the description never explains either parameter. It leaves "query" undefined despite it being required and semantically odd for something framed as a status probe, and never mentions "limit" (default 5) or what it bounds across the three APIs.

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?

It names a resource (status probe) and scope (three fixed literature APIs, concurrent, opt-in), which hints at what happens. But "status probe" is ambiguous — it could mean health-check or literature search — and the presence of a required "query" parameter muddies what the probe actually does. It does not clearly separate itself from siblings such as go_literature_records or search_literature.

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?

"Opt-in" implies optionality but never says when an agent should choose this over go_literature_records or search_literature, nor when to avoid it. No preconditions, no cost/concurrency caveats, no named alternative.

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

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

No annotations are provided, so the description carries the full disclosure burden. Beyond the phrase 'reproducible search records', it says nothing about what gets logged, where records are stored, whether the operation mutates state, required permissions, or what the response contains. For a search-plus-persist tool this is a significant gap.

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 tight sentence with the core action front-loaded and the clarifying exclusion appended. It wastes no words, though the extreme brevity borders on under-specification rather than genuine conciseness.

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

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

With no annotations, no output schema, and 0% parameter documentation, the description is the only source of behavioral detail and provides almost none. An agent cannot determine what the tool logs, what it returns, or how it differs operationally from the many search/verification 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?

Schema description coverage is 0% for both parameters. The description does not explain what 'query' accepts or how 'limit_per_source' behaves (its unit, default, or per-source meaning). With two undocumented parameters, the description needed to compensate and does not.

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 specific verbs and a resource: 'search + log reproducible search records'. The 'NOT an exhaustive systematic review' clause hints at scope, differentiating it conceptually from a full-review tool. However, it never names or distinguishes itself from the closest sibling, search_literature, so an agent still has to guess which search tool fits.

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 'NOT an exhaustive systematic review' boundary gives a when-not signal, implying this is a lightweight, reproducible-search-logging step. But there is no explicit when-to-use guidance and no named alternative (e.g., search_literature) to route between, so the agent must infer selection.

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

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

With no annotations, the description carries the full burden; it does disclose two salient traits — that inference runs against a locally pinned model and that results are experimental, not evidentiary proof. It says nothing about determinism, latency, failure modes, or how the four inputs are consumed, so the disclosure is partial.

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?

It is a single short clause with no filler, which is good, but the terseness comes at the cost of specification rather than reflecting an efficient summary of a complete one. Front-loading is not a problem; omission is.

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?

A four-required-parameter tool with no annotations, no output schema, and no parameter documentation is left almost entirely unexplained. An agent cannot infer input semantics, expected output, or how this differs from its near-namesake sibling from this description.

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?

All four required parameters (claim, evidence, source_id, candidate) have 0% schema description coverage and the description adds no meaning for any of them — for example, what 'candidate' selects or how source_id is validated. The description does nothing to compensate for the coverage gap.

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 sentence characterizes the model ('experimental', 'locally pinned') rather than stating the operation performed on claim/evidence/source_id/candidate. It never explains how this tool differs from the sibling nli_assess_evidence, which appears to do a closely related NLI assessment.

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

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

'Explicitly selected' weakly implies opt-in usage, and 'never scientific proof' cautions against over-reliance, but no condition tells the agent when to pick this over nli_assess_evidence or bm25_rank_evidence. No prerequisites, exclusions, or alternatives are named.

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

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

No annotations are provided, so the description carries the full burden. It does disclose genuinely useful traits: the model is pinned (reproducible across runs), works offline (no network dependency or rate limits), and yields an estimate rather than a verification. It omits what the label output actually contains (confidence, margin) and whether results are cached or ledgered.

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?

Extremely short with zero filler, and the qualifier 'never verified truth' is front-loaded. However, it is a telegraphic fragment rather than a complete sentence, and the density is achieved by dropping information rather than by efficient phrasing.

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 5-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. An agent cannot learn how threshold/margin shape the output, what the response looks like, or why source_id is required, all of which are undocumented elsewhere.

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

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

Schema description coverage is 0% across 5 parameters, and the description names none of them. The two numeric knobs, 'threshold' (0.7) and 'margin' (0.15), have defaults but no stated meaning or effect on the support/refute/insufficient decision, which is the single most consequential thing an agent needs to know before calling.

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 the operation (NLI assessment of evidence) and specifies the output taxonomy (support/refute/insufficient), plus the key qualifiers 'offline' and 'pinned MODEL'. This distinguishes it from verification-oriented siblings like verify_claim, though it never names a specific sibling to route against (e.g. nli_assess_challenger_evidence).

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 guidance. An agent must infer that this is the cheap, reproducible, non-authoritative screen to run before verify_claim or the challenger NLI variant, but the description never states that ordering or any exclusion. 'Never verified truth' is the only usage-adjacent signal.

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

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

With zero annotations, the description carries the full burden and falls far short: it never states whether this is a pure read (implied by 'provenance' but not declared), what encoding or size limits apply to the binary payload, or what guarantees the returned offsets have. The enumeration of outputs is the only behavioral information offered.

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?

Eleven words with no waste, but this is under-specification rather than conciseness — the fragment is missing the verb that would make it a usable sentence. Length is not the problem; the absence of any actionable statement is.

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?

Required inputs include a base64 PDF blob, there are no annotations, no output schema, and 0% schema coverage, yet the description supplies nothing about the call contract. For a three-required-parameter tool handling an uploaded document, this is inadequate to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate for three required parameters and it does not: pdf_base64 is never explained (encoding, full-document vs page, size limits), page_number's indexing base is unstated, and 'quote' is only obliquely gestured at via 'quote offsets' without saying it must be verbatim locating text.

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 text is a noun-phrase fragment ('User-supplied PDF: page hash, quote offsets, table and image bounding boxes') that restates the tool name and lists apparent outputs rather than stating a verb+resource. An agent can infer it computes provenance for a PDF page, but the operation (extract? locate? return?) is never stated, and no sibling such as verify_source_quote or rust_locate_quote is distinguished.

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 when-to-use, when-not-to-use, or alternative guidance at all, despite several siblings (verify_source_quote, rust_locate_quote, verify_evidence_ledger) that plausibly overlap. The only contextual hint is 'User-supplied PDF', which weakly signals it applies to user-uploaded files rather than retrieved ones.

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

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

With no annotations, the description carries the full burden. It vaguely implies a write/record operation (screening decisions and flow counts) but does not state whether it mutates state, what permissions are needed, how duplicate/reviewer-conflict handling works, or what is returned. The mention of 'two independent reviewer' decisions is the only substantive hint.

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?

It is short but this is under-specification, not conciseness. There is no front-loaded action statement, and the fragment does not earn its place as a usable instruction.

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 tool with an unconstrained nested-object array parameter, no annotations, and no output schema, the description supplies none of the missing context. An agent cannot reliably invoke it.

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 sole parameter 'records' is an array of untyped objects with additionalProperties=true and 0% schema description coverage. The description never documents the expected record shape (reviewer id, decision value, exclusion reason, etc.), leaving the agent unable to construct valid input.

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 text is a noun phrase listing two outputs ('screening decisions', 'PRISMA flow counts') rather than a verb+resource statement of what the tool does. It also gives no basis to distinguish it from the sibling prisma_review_flow, which shares the same PRISMA domain.

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 indication of when to call this versus prisma_review_flow or prisma_review_flow's related siblings, nor any stated precondition (e.g., duplicate reviewers required for 'dual' screening). The agent must guess the usage context entirely.

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

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

No annotations are provided, so the description carries the full burden, yet 'auditable' and 'missing full-text stages' are the only behavioral hints — there is no disclosure of whether records are persisted, whether the output is a computed PRISMA count table, what validation the checklist enforces, or what the response contains. The 'missing full-text stages' phrase is a genuinely useful scope disclosure, which is why this is not a 1.

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 eleven-word fragment is not conciseness but under-specification; nothing is front-loaded because nothing is explained. There is no wasted word, but the text is far below the minimum needed for a three-nested-parameter tool.

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

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

With no annotations, no output schema, three fully undocumented required nested parameters, and several closely related PRISMA/evidence siblings, the description omits everything an agent needs to call this correctly. It is not adequate for the tool's complexity.

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?

Three required parameters (identified, records, checklist) with 0% schema description coverage and nested object types, and the description says nothing about any of them — not the expected shape of 'identified' versus 'records', nor what keys 'checklist' must contain. The agent has essentially no way to construct valid arguments from the definition alone.

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 is a noun phrase ('Auditable PRISMA identification/screening and explicit missing full-text stages') rather than a verb+resource statement, so it never says what the tool actually does — build a flow diagram, record counts, or log screening decisions. It adds a few keywords beyond the name (identification/screening stages, absent full-text stage) but remains a restatement of the tool's title concept rather than an action.

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 when-to-use, when-not-to-use, or prerequisite guidance at all, despite a directly overlapping sibling (prisma_dual_screen) that an agent could easily confuse this with. The phrase 'missing full-text stages' hints at a scope boundary but never says to use another tool instead.

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

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

With no annotations, the description carries the full burden, and it discloses only one behavioral trait: citations are not treated as retractions. It says nothing about whether the tool reads or writes, what the alert output looks like, or how propagation is computed.

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 clause with no filler is front-loaded, so it is concise, but it is under-specified for a three-object graph-shaped input. Brevity here costs more than it saves.

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 tool requiring three structured collections, with no annotations, no output schema, and zero parameter documentation, the description leaves essentially every question an agent would need answered before invoking it.

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?

All three required parameters (nodes, edges, notices) are untyped generic objects at 0% schema coverage, and the description gives no hint of their expected shape, required fields, or how they relate — e.g. whether edges reference node ids or whether notices attach to sources.

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 phrase 'source-linked correction/retraction alerts' does gesture at a specific domain concept and adds the 'not citations' distinction, but there is no verb — an agent cannot tell whether this computes, lists, or emits alerts, nor how it differs from check_retraction or crossref_update_alerts.

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 stated condition for when to call this versus check_retraction, crossref_update_alerts, or verify_citation. The only implied guidance is the negative caveat about citations, which is not a usage rule.

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

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

With no annotations, the description carries the full burden, and it does disclose that the response includes a source hash and a truncation flag, plus the OA-only limitation. It omits failure behavior for non-OA items, rate limits, and what happens when truncation occurs, so disclosure is partial.

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 tight sentence with the operation and source front-loaded and no filler; every clause conveys 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?

For a tool with no annotations, no output schema, and 0% schema coverage, the description gives only a partial picture: it names the return elements but leaves error handling, non-OA behavior, and max_chars semantics unexplained.

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

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

Schema description coverage is 0%, so the description should compensate. Mentioning 'truncation flag' loosely connects to max_chars (default 30000), but neither parameter's format, default, or effect is explained beyond that hint.

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

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

The description gives a specific verb ('Read'), resource ('OA full-text XML'), identifier ('by PMCID'), and source ('Europe PMC'), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from siblings like get_paper or verify_source_quote, which is the only gap.

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 'OA' qualifier implies this only works for open-access articles, which is a useful implicit constraint, but there is no explicit when-to-use guidance or comparison against get_paper (metadata) or search_literature. Usage context is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a write operation through 'Record' and adds the constraint not to infer a validated certainty score, but it does not disclose overwrite behavior, required permissions, reviewer validation, or success/failure 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?

One front-loaded sentence with no filler. It is appropriately terse, though that terseness contributes to the completeness gap scored elsewhere.

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 six-parameter, all-required mutation with nested objects, no annotations, and no output schema, the one-sentence description leaves the agent without input expectations or validation rules. It states the purpose but not nearly enough to 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 0%, and the description never mentions outcome, design, down, up, reviewer_id, or rationale. With six required parameters—including two free-form nested objects—the agent must infer every field's meaning from names alone.

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

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

The verb 'Record' and resource 'human GRADE reasoning' give a clear action, and the caveat about not inferring a validated certainty score sharpens scope. It does not explicitly distinguish itself from sibling tools such as record_risk_of_bias or assess_methodology, keeping it at 4.

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 clause 'without inferring a validated certainty score' implies this is for human-supplied GRADE reasoning rather than automated scoring. However, it names no alternatives and gives no explicit when-not-to-use guidance, 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?

No annotations are provided, so the description carries the full behavioral burden. It reveals that two human appraisals are recorded and disagreements are flagged, but omits mutation behavior such as overwrite rules, validation, permissions, error handling, and what the response contains.

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 front-loaded sentence with no wasted words. It efficiently states the core action, the dual-appraisal requirement, and the disagreement behavior.

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 five parameters including a nested reviewers array, no annotations, no output schema, and zero schema description coverage. A one-sentence description is far too thin to tell an agent how to construct valid reviewer objects or understand the operation's full behavior.

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

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

Schema description coverage is 0%, so the description must compensate and mostly does not. It implies framework values (RoB2/ROBINS-I V2) and that reviewers must be two humans, but does not explain study_id, outcome, effect_of_interest, or the nested reviewer object shape.

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: recording RoB2/ROBINS-I V2 risk-of-bias appraisals. It also specifies the dual-reviewer context and disagreement flagging, which distinguishes it from siblings like assess_methodology or audit_methodology, though it does not explicitly name alternatives.

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 this is used to record two human appraisals, but gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not explain when to choose this over assess_methodology or record_grade.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the key matching semantics (literal, no scientific interpretation), which tells an agent results will not be fuzzy or semantically inferred, but it says nothing about return content, behavior on no-match, or engine availability/failure modes.

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 single sentence contains no filler, but it spends its limited words on 'Opt-in Rust PyO3' rather than front-loading the user-facing behavior, so brevity comes at the cost of clarity.

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

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

For a two-required-parameter tool with no output schema and no annotations, the description should say what a match returns (offset, span, boolean) and how source_text relates to quote. Neither is covered, leaving the agent guessing at the result shape.

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

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

Schema description coverage is 0%, so the description must compensate and does not. 'quote' is only obliquely referenced and 'source_text' (the corpus to search) is never explained, nor is any format or case/whitespace sensitivity of the match.

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?

It names the operation (literal quote match) and a differentiating trait (no interpretation of scientific meaning), but 'Opt-in Rust PyO3' is implementation jargon that does not tell an agent what the tool actually produces and it never mentions searching within source_text. It is distinguishable in spirit from verify_claim/nli_assess_evidence but not from verify_source_quote, which is an obvious near-sibling.

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?

'Opt-in' hints that this is a non-default path, but there is no statement of when to choose it over verify_source_quote or verify_citation, no prerequisites, and no conditions under which it should not be used.

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

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

With no annotations, the description carries the full disclosure burden. It earns credit for two non-obvious behaviors — cross-provider DOI deduplication and reporting each provider error — but omits whether the call is read-only, rate/limit behavior, authentication needs, and result shape or pagination.

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 front-loaded sentence with no filler: verb first, then providers, then dedup/error behaviors. It is slightly telegraphic ('report each provider error' leaves format unspecified), but structure and size are appropriate.

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 multi-provider search tool with no annotations, no output schema, and 0% schema coverage, the description is materially incomplete. It omits query syntax, return format, pagination/limit semantics, and error/dedup output shape, all of which an agent needs before invoking it.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. It says nothing about query syntax (boolean? DOI? identifiers?) or what limit_per_source controls, leaving the agent to guess both parameter meanings.

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?

Specific verb ('Search') plus three named resource providers (OpenAlex, Europe PMC, Crossref), with two extra behaviors (DOI dedup, per-provider error reporting). It is clearly distinguishable from verification/audit siblings by subject matter, but it never contrasts itself with the closest neighbor, find_data_and_code, which also performs scholarly discovery.

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?

No statement of when to use this versus alternatives such as get_paper, read_fulltext, or find_data_and_code, and no prerequisites or exclusions. Usage is only inferable from the verb 'Search', which is not enough guidance when the sibling set overlaps on discovery.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully warns "never claim exhaustive recall," which is a real epistemic constraint, but omits return shape, deduplication across the four sources, whether Semantic Scholar is opt-in via a parameter or silently included, and any latency/rate-limit 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 compact clauses with the scope statement leading and the caveat trailing — no filler. It is efficient, though efficiency here partly reflects under-specification rather than disciplined editing.

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

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

With no annotations and no output schema, the description is the only source of behavioral context, and it is far too thin for a two-parameter networked search tool. Missing are the source identities, whether Semantic Scholar is toggled or always on, result ordering, and how cross-source duplicates are handled.

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

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

Schema coverage is 0%, so the description must explain both parameters and does not: "query" is never characterized (syntax, boolean support, field targeting) and "limit_per_source" is only obliquely implied by "four sources." The distinction between per-source limits and total results is left for the agent to guess.

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?

"Search four sources" gives a verb and a scope, but the four sources are never named, and the sibling search_literature is not distinguished from this "extended" variant. An agent cannot tell from this text what the extended corpus actually adds beyond count.

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 when-to-use guidance and no explicit routing against search_literature, which is the obvious alternative in the sibling list. The phrase "including optional Semantic Scholar" hints at a broader scope but never states the condition that should select this tool over the plain one.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the check is against Crossref and that it is a bibliographic match rather than a publication-validity judgment, but it does not describe return behavior, match strictness, failure modes, or external API constraints.

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, front-loaded sentence with no wasted words. The scope and key exclusion are communicated immediately.

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

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

There is no output schema and no annotations, so the description should do more to explain what a successful or failed verification returns. It gives the core scope but leaves important agent-facing details absent.

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

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

Schema description coverage is 0%, so the description must compensate for both required parameters. It mentions 'DOI/title match,' which ties the parameters together, but it does not explain DOI formatting, title-matching behavior, exactness requirements, or how the claimed title is compared.

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 ('bibliographic DOI/title match in Crossref'), and the parenthetical distinguishes it from publication-validity checks. It does not explicitly name sibling tools, but its scope is clear enough to separate it from claim or source verification.

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 implies usage by saying it verifies a DOI/title match and explicitly excludes checking the validity of the publication. However, it does not say when to use this instead of alternatives like verify_claim, verify_source_quote, or check_retraction.

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

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

With no annotations, the description carries the full burden and does disclose one important limitation: it is a literal-string check, not scientific verification. It still omits what a pass/fail result means, whether it is read-only, and failure behavior, so it is only partially transparent.

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

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

Two short sentences, both earning their place, with the core function front-loaded and the caveat immediately after. No padding 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 no annotations, no output schema, and three entirely undocumented parameters, the description does not supply enough for an agent to call the tool correctly or interpret its result. The limitation caveat helps but leaves substantial 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 0% across three required parameters, and the description says nothing about quote, source_text, or source_id. It therefore fails to compensate for the missing schema documentation, leaving an agent to infer the relationship between quote and source_text.

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

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

The description states a specific action and object ('Check literal quote presence'), which is clearer than the tool name 'verify_claim' suggests. However, it does nothing to distinguish itself from the near-identical sibling 'verify_source_quote', so an agent cannot tell which to select without opening both schemas.

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 second sentence functions as a when-not guideline ('This cannot scientifically verify a claim'), steering the agent away from treating it as scientific validation. But there is no positive when-to-use statement and no explicit routing to an alternative such as verify_source_quote or assess_methodology.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a key limitation (it cannot detect whole-ledger replacement), which is genuinely valuable scope information, but it omits what checks are performed, whether the operation is read-only, and what a pass/fail result looks like.

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 clause states the action first, then the critical scope limitation, with zero filler. Every word earns its place and the most decision-relevant caveat is front-loaded after the core purpose.

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 zero-parameter tool with no annotations and no output schema, the description covers purpose and one limitation but does not describe the return value or what 'integrity' encompasses. Adequate but leaves an agent guessing at the outcome semantics of a verification call.

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 per the baseline this scores 4. There are no input semantics for the description to clarify, and the empty schema is consistent with the description's self-contained verification scope.

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 ('Check local JSONL ledger integrity'), and the 'ledger' resource clearly differentiates it from sibling verify_* tools like verify_citation and verify_claim. However it never names or contrasts with any sibling explicitly, so the differentiation is inferred from the unique resource rather than stated.

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 its usage context (verifying a local ledger's integrity) but gives no explicit when-to-use trigger and names no alternative tools. The 'cannot detect replacement of the entire ledger' clause is a scope caveat rather than routing guidance, so an agent has only an implicit sense of when to prefer this over other verification 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?

No annotations are provided, so the description carries the full burden. It discloses retrieval of external full text but says nothing about failure behavior (quote not found), whether the pmcid must be an exact PMC identifier, rate limits, or what the result looks like. 'NOT a scientific verdict' is a useful output-scoping caveat but far from complete behavioral disclosure.

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 compact sentence with the action front-loaded and the important limitation trailing. No filler, though the semicolon-heavy phrasing is slightly terse.

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-required-parameter tool with no annotations and no output schema, the description should explain return shape (found/not-found, position, matched text) and any pmcid format expectations. It omits both, leaving the agent unable to interpret results.

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

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

Schema coverage is 0% and neither parameter has a description, so the description is the only source of meaning. It implies 'pmcid' identifies the Europe PMC source and 'quote' is the string being located, which covers both params conceptually, but adds no format, matching, or normalization guidance.

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 chain (Retrieve + locate) on a specific resource (Europe PMC full text / source paragraphs) and the boundary condition 'NOT a scientific verdict', which distinguishes it from siblings like verify_claim and verify_evidence_ledger. Clear without needing to inspect the schema.

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

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

The 'NOT a scientific verdict' clause implies when NOT to rely on this tool's output, but no alternative sibling is named and no positive trigger condition (e.g., 'use when you have a pmcid and an exact quote string') is given. 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.