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

With annotations already declaring readOnly/idempotent/non-destructive, the description still adds real value: it discloses that no charge is incurred, that preparation reserves no allowance, that the finalized order entitlement is authoritative, and that no payment or credential is returned. The entitlement wording is slightly abstract but materially informs 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?

Front-loaded with the core purpose in the first sentence, and each following sentence adds a distinct fact (cost, sequencing, authority of entitlement). The phrasing 'Preparation reserves no allowance' is a little opaque, costing some crispness.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description covers cost, sequencing, and credential behavior for a zero-param read. What an agent needs to call it correctly is 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the default baseline applies. No misleading parameter claims are made.

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

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

States a specific verb and resource — read how many free checks remain — and situates it relative to the sibling prepare-a-public-JSON-check flow, so an agent can tell it is a quota/eligibility read rather than an execution step.

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

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

'Use this to understand eligibility before preparing a public JSON check' plus the 'After enrollment' precondition gives clear when-to-use guidance and ordering against noticer_prepare_receipt. It stops short of explicit when-not-to-use cases or naming other siblings such as receipt_status.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real context beyond them: no account/order/payment is created, missing config is non-blocking, and it disclaims that this is guidance rather than a verified outcome or free-eligibility guarantee. That negative-space disclosure is exactly what annotations can't express.

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 trigger condition is correctly front-loaded, but the text is padded: 'Creates nothing' is stated once as a standalone sentence and then restated as 'without creating an account, order or payment,' and the final disclaimer sentence repeats the 'this is setup guidance' idea already conveyed by the title-adjacent framing. Two of the five sentences could be merged without information loss.

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

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

With an output schema present, the description need not enumerate return values, and it still names them at a high level (setup state, terms location, price). For a zero-parameter read-only setup tool, an agent has enough to decide and call correctly; the only gap is not indicating what a caller should do after reading the state.

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 there is no parameter semantics to document and the baseline of 4 applies. Nothing in the description conflicts with the empty schema.

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

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

The description names the concrete deliverable (local setup state, canonical terms location, published USD 1 receipt price) and explicitly states 'Creates nothing,' which separates it from write-oriented siblings like noticer_prepare_receipt and noticer_pay_with_existing_link. However, the opening framing about 'an action you sent or delegated needs its result confirmed' describes a broader workflow rather than this tool's own function, which delays the actual verb+resource.

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?

'Start here when...' gives an explicit entry-point condition with three conjunctive triggers (needs confirmation, your tools can't, result is one field of public HTTPS JSON), which is genuinely actionable. It also preempts a likely failure mode ('A missing local configuration does not prevent tool discovery'). It stops short of naming which sibling to move to next, so alternatives are only implied by the name set.

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?

Goes well past the annotations: discloses that enrollment itself never charges, that five free checks are granted to new self-service buyers, that later receipts cost USD 1 with separate wallet approval, and that the credential/recovery secret stay in encrypted local custody. 'Enroll once' is consistent with idempotentHint=true. Minor gap: it doesn't say what happens on a repeat call or how failure modes surface.

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 enrollment condition is front-loaded and nearly every sentence carries operational weight (URL, approval order, pricing, custody). The prose is dense and slightly rambling in the middle, but there is no filler to cut.

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 high-stakes enrollment that touches payment and consent, the description covers cost, consent gating, secret custody and the approval workflow; an output schema exists so return shape needs no elaboration. What remains thin is per-parameter guidance for the three required booleans.

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% — the three booleans have no descriptions at all — so the description must carry the load. It does explain the consent semantics collectively ('Booleans assert consent, not proof') and ties approval and terms acceptance to setting them true, but it never maps meaning onto the individual parameter names owner_authorized and commerce_scope_accepted.

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 — 'Enroll once' for 'commerce-only access' to public-JSON checks — which is enough to separate it from the account/setup siblings. It stops short of naming which sibling to use when commerce-only access is not the goal (e.g. noticer_commercial_setup vs noticer_commercial_account).

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

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

Gives a clear triggering condition ('when the owner chooses commercial public-JSON checks and needs commerce-only access') plus a prerequisite sequence: show the /start URL, obtain host action-time approval, then set the booleans true. It does not state exclusions or explicitly redirect to a sibling when the condition is unmet.

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?

It discloses substantial behavior beyond the annotations: two byte-identical retrievals are verified against a pinned key, invalid/stale/mismatched/untrusted evidence is rejected rather than converted to continue, INCONCLUSIVE yields a blocking server gate, raw evidence remains encrypted locally, and the local decision is unsigned and does not execute downstream actions.

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 front-loads the verification purpose and decision outcomes, but it is long and repetitive, especially the repeated statement that a signature authenticates the issuer rather than source honesty. Some sentences could be tightened without losing substance.

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

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

For a complex cryptographic verification tool with an output schema, the description covers the decision states, rejection behavior, trust boundaries, and non-execution limits well. The main gap is the unexplained check_label parameter and the absence of explicit sibling routing guidance.

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 carry parameter meaning. It explains decision_ref as a stable caller-local reference for the intended next action, but it never explains what check_label means or how it affects verification.

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

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

The description clearly states the action: locally verify a signed receipt and return a verified receipt verdict plus local decision. It is specific about the resource and outcome states, but it does not explicitly differentiate itself from siblings such as noticer_receipt_status or noticer_run_receipt.

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 usage through the PROVED/DISPROVED/INCONCLUSIVE decision flow and says to use a stable caller-local decision_ref for the intended next action. However, it does not explicitly say when to call this tool versus preparing, running, or checking receipt status, and it gives no exclusions.

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

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

Adds substantial context beyond the annotations: no trust-on-first-use, returns status and never secrets, optionally discovers an already installed Link CLI only after consent, and an explicit threat-model caveat that the key and encrypted records share one OS-user boundary. The 'no server contact' claim is consistent with openWorldHint=false, and the consent gate explains the destructiveHint=false / idempotentHint=true profile.

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 opening sentence front-loads purpose and precondition, and each subsequent sentence carries distinct information (what is created, what is returned, what is excluded, what the limits are). It is dense but occasionally packs multiple distinct facts into one long clause chain, which slightly slows scanning.

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?

Output schema exists and the description still usefully notes that setup status is returned and secrets never are, plus the threat-model boundary -- enough for an agent to call this correctly. The only remaining gap is that the required owner_authorized parameter's semantics are inferred rather than stated.

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 carry the load; it does explain enable_existing_link as an opt-in discovery of an already installed trusted Link CLI gated on consent. owner_authorized is only implied by the 'explicitly consents' precondition rather than described as a required authorization flag, leaving a small 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 and resource -- set up local private custody -- and immediately enumerates what that concretely creates (owner-only POSIX state/config and a random custody key pinned to a canonical origin). The explicit negative list ('does not enroll, contact a server, pay, install software or sign in') sharply separates it from the commercial/enrollment/payment siblings.

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

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

Gives a clear precondition (owner has chosen Noticer and explicitly consented to local setup) and a clear set of when-not-to-use cases via the negation list. It stops short of naming the alternative sibling tools (noticer_enroll_commerce, noticer_pay_with_existing_link) that a reader must infer from the negated verbs.

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

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

Beyond the annotations, the description discloses that this prepares a challenge rather than a charge, requires no wallet, depends on owner approval, and returns bound challenge/endpoint metadata. It also adds important security handling instructions about never exposing SPTs, payment credentials, or keys. These details materially help an agent understand the tool's behavioral boundaries.

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, and most sentences add useful safety, precondition, or return-value context. The wording is somewhat dense and includes an undefined acronym (SPTs), but there is little outright waste.

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

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

The description covers important behavioral and safety context for a complex payment-adjacent tool, and the output schema means return values need not be detailed. However, with six required parameters at 0% schema description coverage, the description is still incomplete about how most parameters should be supplied.

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 carry parameter meaning. It partially clarifies merchant_account and network_id by saying they must come from independently verified provider configuration, but it leaves check_label, confirmed, amount, and currency largely 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 states a specific action: obtaining one-order payment terms by preparing a public challenge after owner approval. It distinguishes itself from the existing-Link payment tool and clarifies that it is not a charge. However, it does not clearly differentiate from related siblings such as prepare_receipt or run_receipt.

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

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

It gives clear preconditions: owner must approve USD 1, the receipt must be eligible and saved, and merchant/network must come from independently verified provider configuration. It also contrasts with the separate existing-Link tool that requires wallet approval. It stops short of explicit when-not guidance relative to other receipt-related siblings.

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?

Goes well past the annotations: it discloses that a real payment can be submitted, that approval alone is not settlement and settlement is not verified evidence, that credentials stay in private subprocess memory, that only sanitized status and an approval URL are returned, and that no downstream action runs. That is exactly the behavioral context annotations cannot express.

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?

Purpose is front-loaded in the first sentence and each subsequent line adds a distinct constraint (requirements, prohibitions, credential handling). Dense but not padded; slightly long, though most of the length is load-bearing safety guidance.

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

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

An output schema exists, and the description still characterizes the return (sanitized status plus approval URL) and rules out settlement inference. For a single-shot payment tool, nothing an agent needs to invoke it safely 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 0%, so the description must carry parameter meaning. It does indirectly: 'exact USD 1' pins amount and currency, 'SAME check_label/request' names check_label's role, and 'both local consent and the wallet's approval' implies what confirmed gates — but it never explicitly maps these to the four parameter names or describes formats/types for amount, currency, or confirmed.

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 ('pay for one eligible saved receipt') plus the exact payment rail ('existing authorized Link wallet'), which cleanly separates it from siblings like noticer_payment_challenge and noticer_run_receipt. An agent can tell what this does 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?

Explicit preconditions (separate exact USD 1 consent, both local consent and wallet approval required), explicit sequencing (resume only the SAME check_label/request, present any approval_url), explicit next step (noticer_get_verified_receipt after settlement), and explicit exclusions (never install software, log in, switch payment methods, or create a replacement request after denial, expiry, or an uncertain payment).

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

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

Beyond the annotations, the description discloses important behavior: it does not observe, charge, or reserve allowance; it returns frozen scope, obligation hash, price, and a confirmation notice; server validation is final; and no receipt is guaranteed for every failed request. It also explains idempotent recovery behavior by requiring reuse of the same check_label with identical scope after interruption. These details add substantial operational context and do not contradict the annotations.

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

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

The description is appropriately detailed for a security- and billing-sensitive preparation tool and front-loads the core purpose and constraints. It does repeat some points, notably owner authorization and the absence of observation/payment/allowance reservation, which makes it slightly longer than necessary. Overall structure is still functional and readable.

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 nested scope object, authorization requirements, idempotency concerns, and high-stakes separation from actual observation and payment, the description is complete enough for an agent to prepare a valid request. An output schema exists, and the description still usefully previews the return terms and approval workflow. Recovery and validation edge cases are also covered.

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 carry parameter meaning, and it does: it explains check_label stability, scope contents including claim_ref, questioned and control URLs, query constraints, deadline_seconds range, and authorized_public_read=true. It also clarifies dotted-path extraction semantics with concrete examples. This compensates thoroughly for the sparse 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 makes clear that this tool prepares/freezes the terms for a public-read check and returns scope, obligation hash, price, and a confirmation notice. It distinguishes the preparation phase from actual observation or payment, which helps separate it from run_receipt. However, the opening sentence is framed as an instruction for describing the destination state rather than a crisp statement of the tool's purpose.

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 preconditions: owner authorization for public reads, same-host public HTTPS JSON URLs, distinct paths, and a genuinely known-good control. It also states that no observation or payment occurs here and that separate explicit run approval is required before proceeding, which effectively guides when to use this versus a run tool. It does not name sibling tools explicitly, so it falls short of perfect alternative routing.

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

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

Annotations already declare read-only and idempotent behavior, and the description adds critical non-obvious context: a 3-second minimum between polls, verdicts are unverified, the response is entitlement/next-step guidance rather than authorization, and it never submits another payment.

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 warnings are front-loaded, but the first two sentences are nearly repeated: 'Poll...3 s apart' is repeated as 'Wait at least 3 seconds,' and the unverified-verdict warning appears twice. This duplication wastes 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?

For a simple polling tool with an output schema and safety annotations, the description covers polling cadence, trust limits, and side-effect boundaries. It remains incomplete because it does not define check_label or route the agent to alternatives when status alone is insufficient.

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 only parameter, check_label, has 0% schema description coverage and the description never explains its meaning, format, or source. This leaves the agent guessing what label to supply.

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 opening 'Poll' plus 'verdict' and 'saved payment' make it clear this is a receipt/payment-status polling tool, and the 'unverified' warning implicitly separates it from get_verified_receipt. However, it never states the resource explicitly or names a sibling, so differentiation still relies on inference.

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

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

It sets a clear polling interval and warns not to drive a workflow from status alone, and notes it can inspect an uncertain saved payment without submitting another payment. It does not say which sibling to call instead when a verified receipt or an action is needed.

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

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

Annotations declare readOnlyHint=false, yet the description twice asserts 'Reads only' while also saying it 'Starts observation and returns a check identifier' — i.e. it creates server-side state. This is a direct contradiction that could lead an agent to treat a state-creating call as side-effect free. The otherwise useful disclosures (booleans are caller assertions not proof of consent, future USD 1 evidence access, 3-second polling floor) do not offset the contradiction.

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 critical gating condition is front-loaded, which is good, but the text repeats itself ('it never pays or performs or repeats the original action' vs 'It never pays or performs the downstream action') and multiplies jargon where one plain sentence would do.

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

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

An output schema exists, so return detail is covered, and the commercial/consent context is unusually well conveyed. Still, for a 4-parameter open-world tool it omits the meaning of check_label and never tells the agent which sibling (noticer_receipt_status, noticer_get_verified_receipt) continues the flow after the check identifier 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 coverage is 0%, so the description carries the full burden. It does explain that obligation_hash is the saved obligation hash and that both booleans must reflect explicit owner approval and are assertions rather than proof, but it never mentions check_label at all — one of four required parameters is entirely 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 action and resource: observe a saved public JSON condition tied to a frozen scope, starting the observation and returning a check identifier. The verb and effect are clear, though the jargon ('saved public JSON condition', 'frozen scope') is opaque and it never names how it differs from noticer_prepare_receipt or noticer_receipt_status.

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

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

Gives explicit preconditions ('only after approval of the exact frozen scope and confirmation notice', 'Supply its saved obligation_hash') plus operational rules: poll no more often than 3 seconds, evidence access may later need a separate USD 1 approval. It lacks an explicit when-not or a pointer to noticer_receipt_status for the polling it references, so it falls short of 5.

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