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

With no annotations, the description carries the full burden and does so richly: it discloses the append-only hash-chain mechanism, what each entry hash binds, the fixed format tag, that tampering or an incompatible format version will break the chain in a detectable way, and crucially that the function does not persist anything itself. This is exactly the behavioral context an agent needs before invoking it.

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

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

The description is front-loaded with purpose and return value, then mechanism, then usage guidance, then the important non-persistence caveat. It is somewhat long, but nearly every sentence carries useful technical information for an annotation-free tool handling a hash chain.

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

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

Given the complexity of a tamper-evident hash chain, the absence of annotations, and the lack of an output schema, the description is complete enough: it explains the return value, persistence expectations, verification path, and versioning constraints. An agent has what it needs to call the tool correctly.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters and their nested fields thoroughly. The description adds thematic explanation of how the chain and payload are bound by hashes, but does not add parameter-level syntax or format details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a precise verb and resource: appending one entry to an append-only, hash-chained audit log and returning the new longer chain. It also names verify_audit_chain and explains how tampering or version mismatch will be detected there, which clearly distinguishes it from the verification 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?

It gives explicit usage context: 'Use this wherever you need a tamper-evident record of events (agent actions, approvals, state transitions) that a skeptical third party can later verify independently.' It also clarifies the non-persistence behavior and what to do with the return value, though it does not explicitly state when not to use it or name a direct 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?

With no annotations, the description carries the full burden and does well: it explains the positive composite, the two specific penalty patterns, and the tool's limits (it cannot show fabrication and misses varied, multi-source campaigns). It does not explicitly state side-effect purity or deterministic behavior beyond the schema's now parameter.

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

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

The purpose is front-loaded, and the description is dense but largely earns its length by covering scope, interpretation, and limitations. Some sentences are long, but the complexity of the tool justifies most of the space.

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

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

The description gives rich context for a complex scoring tool, including scope, interpretation, and caveats. Because there is no output schema, it would be stronger if it specified the return score's range or shape, but it is still sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and nested config properties thoroughly. The description adds conceptual meaning about consensus/diversity/volume/recency and the two manipulation checks, but no additional parameter-level semantics beyond what the schema provides.

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

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

The description opens with a specific verb and resource: it scores how organic a corpus of unattributed, scraped sentiment signals looks. It clearly distinguishes itself from the sibling score_trust_identified and explicitly states what kind of signals it handles.

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

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

It gives explicit when-to-use guidance (reviews/mentions/buzz with no identity behind them) and names the alternative tool for identified contributors. It also clarifies when not to over-interpret the result, saying a low score is not a fraud finding.

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 supplied, so the description carries the full burden and does so well: it defines the three buckets, the precedence rule ('unverified always wins over staleness'), and the scope limit (existence + freshness only, not grounding). It stops short of stating side effects or that it is a pure read, but the semantic disclosure is strong.

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?

Front-loads the core action, then usage, then the caveat, and every section is relevant. The SOC2-controls analogy costs a few words but meaningfully conveys the pattern, so the size is justified for the tool's complexity.

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 output schema and no annotations, the description supplies the missing return semantics by naming the three classification outcomes and their tie-breaking. Nothing essential for correct invocation or interpretation appears to be 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 coverage is 100% and every parameter is already documented in the schema (including the empty/whitespace evidenceRef rule and the maxAgeDays semantics). The description reinforces the maxAgeDays/verifiedAt relationship in prose but adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (checking) applied to a specific resource (public-facing product claims registry) and immediately defines the three output buckets. It is clearly distinguishable from siblings, naming check_grounding as the adjacent tool.

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 frames when to use it ('periodic Monday-morning review or a CI gate') and states the boundary condition and the alternative tool to pair with ('not that the thing it points to still actually supports the claim's text -- pair with check_grounding'). This is exactly the when/when-not/alternative guidance expected.

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 so well: it discloses that this is a mechanical/structural check, that the default matcher is naive substring/word-overlap rather than semantic entailment, that it can both false-positive (coincidental word match) and false-negative (genuine paraphrase), and that it cannot verify the truth of the evidence itself. It also states the priority rule ('invalid outranks every other status').

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?

Front-loaded with the purpose, then classification definitions, matcher caveat, and escalation path in a logical order where each sentence carries distinct information. It is long, but the length is justified by the four-status taxonomy and the non-obvious matcher limitations.

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

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

No output schema exists, yet the description fully enumerates the return classifications and their meanings, and covers the matcher's failure modes and parameter interplay. For a 2-parameter tool with a nested evidence map and no annotations, nothing an agent needs to invoke and interpret it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by framing `evidence` as a closed world and explaining the parameter interaction (a marker cited in `text` missing from `evidence` is invalid; empty evidence makes all citations invalid). It reinforces the `[[cite:id]]` marker convention and notes what to do with alternate syntax.

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 first sentence states a specific verb and resource ('Detects ungrounded or forged citations in AI-generated text') and the body enumerates the four classification outcomes. It is clearly distinguishable from siblings like corroborate_evidence or check_provenance_claims by naming the exact artifact it inspects (sentence-level citation markers vs. evidence map).

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 says when to use it ('before shipping any AI-written report, summary, or answer that cites sources') and when to escalate ('for higher-stakes content, use grounding-kit directly with a custom supports() function'). It also names the alternative tool and the condition that selects it, leaving nothing 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?

With no annotations the description carries the full burden and does so thoroughly: it re-runs the function once per scenario, confirms byte-identical output, flags vacuous mutations, runs in a worker thread with bounded timeout that is NOT a sandbox, and states the trust constraint on passed code. It also discloses coverage limitations (untried values, one-at-a-time fields, proxy fields).

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

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

Front-loaded with the core purpose and the sibling routing, and almost every sentence earns its place given the tool's complexity. The downside is a single dense paragraph stitched with em dashes that is harder to skim than a structured list would be.

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

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

For a complex tool with no output schema, it explains result semantics (byte-identical = pass, vacuous flag) and the exact scope of what a pass covers. It stops short of describing the concrete result object shape, but the caveats and constraints an agent needs to call it correctly are present.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds meaning beyond the schema, notably the 'vacuous' scenario flagging and the notion that a mutation must actually change the input to count. It reinforces that scenario names appear in failure output and that mutations rewrite one axis on a copy.

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

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

States a specific verb ('checks whether ... output changes') and resource (a decision/score/ranking function's dependence on a named variable), and explicitly differentiates itself from sibling check_payout_invariance. An agent can tell this apart from siblings 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?

Explicit when-to-use ('hiring/lending/insurance/housing-style fairness claims or any other should-not-depend-on-X claim') versus when to prefer the alternative ('use check_payout_invariance specifically for the payout/commission axis'). Also tells the agent to re-run in CI whenever the function changes.

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 delivers: it discloses that runtime code executes in a worker thread with a bounded timeout and is NOT a sandbox (only pass trusted code), that static-imports is a best-effort grep rather than a real parser with named blind spots, and that vacuous mutations are flagged rather than counted as passes. It also scopes what a 'pass' actually means.

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 core purpose is front-loaded, but the body is one very dense multi-clause sentence stuffed with parentheticals and em-dash asides, which makes it hard to scan for the mode-selection rules. The information mostly earns its place, but the structure hurts retrieval rather than helping it.

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 an 8-parameter, two-mode tool with no output schema, the description covers execution model, trust boundaries, mode tradeoffs, and pass semantics well. It does not describe the shape of the returned result beyond 'shown in failure output', which is the remaining gap.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters (baseline 3). The description adds genuine meaning beyond it: an example shape for baseInput, guidance that mutateSource must be pure and adversarial with concrete examples, an example rankFnSource signature, and the security caveat on passing code. It stops short of enumerating defaults/mode-requirements per parameter, which the schema does cover.

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

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

States a specific verb (checks) and a precisely scoped resource (whether a ranking/recommendation/comparison engine's output ordering depends on operator payout), and immediately bounds the claim ('for the specific scenarios you supply, not a formal proof'). It is distinguishable from the sibling check_mutation_invariance by its explicit payout/commission focus.

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 routes mode selection: 'Use `runtime` when you can call the ranking function directly; use `static-imports` as a cheaper, complementary check on the engine's source.' It also states the ongoing workflow expectation ('re-run this in CI whenever the ranking logic changes') and warns to write adversarial/boundary scenarios rather than one easy 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 and does so unusually well: it discloses the incident-derived provenance of the default phrase list, the phrase-list coverage gap ('will miss phrases it doesn't know about'), the negated-window limitation ('fixed character window... not a parser'), and the precise meaning of an empty result. These are exactly the caveats an agent needs to avoid over-trusting the output.

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?

Front-loaded with the core detection behavior, then limitations. Dense and every sentence carries signal, though the incident anecdote is longer than strictly required and could be tightened without losing meaning.

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 does most of the work, covering scope, limits, and empty-result semantics. Its one gap is the shape of the returned offenses (it references 'offense messages' but never describes the result structure), which matters for a tool with no output schema.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value beyond the schema by explaining that certaintyPhrases defaults are a starting point drawn from one incident and should be extended per domain, and by clarifying the tier semantics context for certaintyRequiresTier/requireSourceRefForTiers.

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 ('scans reader-facing claims for certainty-implying language') and enumerates the three detection classes (unbacked certainty phrases, tiers requiring a sourceRef, unrecognized tiers). This is clearly distinct from siblings like check_grounding or check_claims_registry 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?

Gives strong workflow context ('run it on any copy, marketing page, or AI-drafted content that makes factual-sounding claims before it ships, not after') and a domain-extension hint for certaintyPhrases. It stops short of naming a sibling alternative or the condition that would route to one, so it falls just below the top bar.

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 so richly: it discloses that engineRight/humanRight are never blended, that divergence requires BOTH a count and rate floor, that calibration has its own separate floor and status (so divergence can be reportable while calibration is refused), and that groupBySource runs in a worker thread with a bounded timeout and a code-trust caveat.

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 front-loaded with the core computation, but the body is dense with nested parentheticals and run-on sentences that carry multiple ideas each. For a complex statistical tool the length is partly justified, yet several clauses could be trimmed without losing meaning.

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

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

With no output schema and no annotations, the description must carry the load; it explains the computed counts, the floor semantics, the separate calibration status, and the grouping behavior. It stops short of describing the report's full shape (e.g. examples, overall structure), which is the one remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds conceptual meaning beyond the per-field text: why two separate counts exist (system can be right overall yet wrong on every overrule) and why both floors must clear together. Some of this overlaps the schema's own phrasing, keeping it below a 5.

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 ('computes how often two independent judges rated the same object differently') and even names the two output counts (engineRight/humanRight). It explicitly distinguishes itself from the sibling grade_decision by scope (population of engine-vs-human calls vs one recommendation's window).

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

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

It gives an explicit trigger ('use this whenever a system has both an automated judgment and a human override/correction recorded for the same objects') and an explicit alternative with its own condition ('for grading one recommendation's own before/after outcome window ... use grade_decision'). Nothing 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?

With no annotations, the description carries the full burden and does so well: it discloses the verdict logic (2+ distinct sources plus a non-textual signal for 'confirmed', disagreement surfacing as 'mixed', null results gated by coverage, thin coverage capping the verdict). It does not describe error behavior or the shape of the returned verdict object, leaving a modest gap for a scoring tool.

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

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

The key constraint ('NOT a vote count') is front-loaded and the grading rules follow in a tight, information-dense sentence. It is longer than average but nearly every clause carries a distinct rule; minor density without wasted sentences.

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 and no output schema, the description conveys the decision rules an agent needs to invoke it correctly and anticipate verdict semantics. It stops short of stating return-value structure, but the embedded verdict names give sufficient orientation.

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

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

Schema coverage is only 50%, but the description compensates by explaining how the parameters drive outcomes -- distinct `source` counting for independence, non-textual `kind` unlocking 'confirmed', and coverage capping the verdict. This adds real semantic meaning beyond the field-level schema descriptions.

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 ('grades confidence in a claim from a set of independent evidence signals') and immediately differentiates itself from a naive alternative with 'NOT a vote count'. An agent can distinguish this from siblings like check_grounding or score_trust_identified without opening the schema.

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

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

Explicitly says when to use it: 'whenever several pieces of evidence were gathered for a claim (by you, another tool, or a research/verification pass) and you need an honest, non-inflated verdict'. It gives a clear triggering context but does not name or contrast against specific sibling tools, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden and discharges it: it enumerates the three verdicts, the exact cross-multiplication semantics, the exposure (exposed === true) rule, the baseline_negative_signal refusal, the secondary/non-headline handling, and the downgrade of a dismissed-but-correct recommendation. This is far beyond what any structured field provides.

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 core purpose and routing are front-loaded in the first sentence, and every sentence is load-bearing (verdict logic, exposure rule, secondary handling, alternative tool). It is dense and long, however, with the parenthetical worked example pushing it toward the verbose side, so it is efficient but not maximally tight.

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

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

For a complex nested-object tool with no annotations and no output schema, the description supplies the missing return semantics: the three verdict strings, the fields to surface (badRateDelta, baseline/result counts), secondary.wouldBeVerdict, and refusalCodes. An agent has enough to interpret results without an output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it explains how refuteThreshold drives 'holding' vs 'not-holding', that the rate comparison cross-multiplies raw counts rather than badRate fields, and how exposure gates the headline verdict. It stops short of restating per-field defaults, which is fine since the schema already covers them.

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 precise verb (grades) plus resource (a recommendation-and-decision pair against a before/after observation log) and immediately defines the scope: same subjectId + checkKey, baseline vs result window. It is trivially distinguishable from siblings like compute_divergence, which it names as the population-level alternative.

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 says 'Use this to close the loop on any recommender/advisor system that logs recommendations, human accept/reject calls, and later outcomes' and names when NOT to use it: 'For grading a whole population of engine-vs-human calls at once ... use compute_divergence instead.' Both the when and the alternative are stated outright.

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, so the description carries the full burden, and it does substantial work: it clarifies this is documentation/scaffold output rather than a live check, that the worked example runs against the real kit producing one accepted and one rejected claim, and that the snippet is copy-pasteable. It stops short of saying whether the worked example has side effects or resource cost, which is the one remaining behavioral 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?

It is a long single paragraph, but it is front-loaded with the most important framing (runtime library, not a server-side check) before the deliverables. A few phrases restate ('so you can see actual output before wiring it in'), which keeps it just under a 5.

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-required-parameter scaffolding tool with no output schema, the description fully covers what the agent receives (explanation, install step, snippet, optional live example), when to invoke it, and how it differs from the verification siblings. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100% for the single boolean, and the schema already states it runs a live accepted/rejected example. The description's '(optionally) a live worked example ... one accepted claim, one rejected claim' largely restates that, so baseline 3 is appropriate.

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

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

The description states a specific deliverable (pattern explanation, install step, copy-pasteable starter snippet, optional worked example) and explicitly contrasts it with siblings: 'it is not something this MCP server can check on demand the way it checks a document's citations.' An agent can distinguish this scaffolding tool from check_grounding / corroborate_evidence 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?

Gives an explicit when-to-use: 'Use this when you're building or reviewing anything that lets an AI agent report back what it did ... and you don't yet trust that report by construction,' with concrete example domains. It also implicitly excludes the runtime-check interpretation by explaining the packet only exists in the caller's own runtime.

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 so well: it explains that the withReserveConfirm piece needs a live UsageLedger and async callback that cannot be handed to this tool, and that the worked example runs against an in-memory demo ledger (so no external data dependency). It also scopes the tool's limits (advisory only, not a hard concurrency limit, not proof of provider billing). It stops short of stating side effects of running the live example (latency/cost/credentials), keeping it just under a 5.

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 content is substantive and mostly earns its place, but it is delivered as one dense, meandering paragraph with heavy parenthetical nesting for a tool that takes one optional boolean. It is not front-loaded on the single most important fact, and readability suffers; it would be far stronger as a short lead sentence plus structured bullets.

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 must carry the full load, and it does enumerate what is returned (three explained pieces, install step, snippet, optional live examples with specific cases) and names the concurrency_and_recovery section of the output. It is nearly complete, only leaving unclear whether the live examples incur latency or require credentials.

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

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

The schema has 100% description coverage for the single includeWorkedExample parameter, so the baseline is 3. The description restates the same idea ('optionally... a live worked example') and enumerates what the examples contain, which adds content detail but no syntax or format meaning beyond 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?

The description states a specific action (explain the three cost-governor-kit pieces, provide an install step, a starter snippet, and optionally live worked examples) for a specific resource. It also distinguishes itself from the sibling check_* tools by stressing it is a runtime library, not an on-demand checker. The purpose is clear, though it is buried in a long first sentence rather than stated crisply up front.

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

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

It gives an explicit when (building or reviewing anything that calls a paid AI API and wanting a pre-call spend estimate plus usage counting that skips a call that threw). It names exclusions (NOT a strict concurrent limit, not proof a timed-out call was never billed) and routes to an alternative explicitly: use withCapacityReservation instead if you need a real reservation. This is model usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does substantial work: it discloses the weighting model (tier x source x proof-strength x reputation x recency decay), the effective-sample-size computation, and the shrinkage-toward-prior behavior with thin vs. deep evidence. It also notes the empty-signals edge case yields the prior. It stops short of stating what the response actually contains or any determinism caveat (the `now` param hint lives in the schema, not here).

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?

Front-loaded with the verb and scope, then the mechanism, then the routing rule — a sensible order with no filler sentences. It is dense and somewhat long-winded in the mechanism sentence, but each clause carries distinct 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 complex, nested-schema tool with no output schema and no annotations, the description explains the computation well but never says what the tool returns (score, confidence band, effective sample size?). The config's confidence thresholds imply a confidence output, yet the return shape is left entirely to inference.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds conceptual meaning the per-param descriptions do not: it explains that `dial` is the shrinkage strength and that `prior` is the baseline thin evidence shrinks toward, framing how the two required params interact. It does not add anything for `signals` item fields beyond the schema's own vocabulary 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+resource ('scores one entity or one dimension') and scopes it to signals from KNOWN, identified sources. It explicitly distinguishes itself from the sibling assess_anonymous_authenticity by naming the unattributed/scraped case, so an agent can route without opening a schema.

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

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

Gives an explicit use case ('trust/reputation scores backed by attributable evidence') and an explicit exclusion with the alternative tool named ('for unattributed/scraped signals ... use assess_anonymous_authenticity instead'). The condition that selects each tool is stated, not 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 burden and does so thoroughly: it names the two truncation attacks, states that neither is caught by default, distinguishes what `expectedMinLength` versus `anchor` each catch, and explicitly bounds the guarantee ('tamper-evident, not tamper-proof', post-anchor entries only internally consistent). No behavioral trait is left implicit.

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?

Front-loaded with the core operation, then the option/attack analysis. It is long for a tool description and repeats the truncate-and-re-append distinction in several places, but the density is largely justified by the subtle security semantics being conveyed.

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?

Covers what is verified, what attacks are and are not detected, and the limits of the guarantee. The one minor gap is that it never states the exact response shape (verdict field, per-entry error reporting), though there is no output schema to lean on for that.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes beyond the schema by explaining the security semantics of the optional parameters (what each attack each one catches, and the consequence of omitting both). That is real added meaning over the structured fields, though the mechanics of `anchor` are also restated in the schema itself.

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 precise verb and resource ('Independently re-verifies a hash chain from genesis') and immediately defines the exact operations performed (recomputes each entryHash, checks prevHash linkage). It is clearly distinguishable from the writer sibling append_audit_entry, which produces rather than checks chains.

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

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

Gives explicit when-to-use ('Use this to audit a chain you did not produce yourself before trusting it') and, more importantly, tells the agent exactly which optional parameters to supply for which threat model and what silently passes if neither is given. This is unusually complete routing guidance for a verifier.

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