agent-offset-clearinghouse

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

The description discloses the payload content (per-credit plus book-wide conservation totals), which is helpful. However, annotations declare readOnlyHint=false for what reads like a retrieval tool, and the description neither explains the non-read-only nature nor mentions side effects, auth, or cost. With no output schema caveat needed (one exists), the remaining behavioral gap is real.

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 no filler; the resource is front-loaded. It is arguably too terse to carry usage guidance, but 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?

With an output schema present and zero parameters, the description only needed to establish purpose and routing. It establishes purpose adequately but leaves the agent without any signal on how this differs from the several other position/credit-listing siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to document; baseline 4 applies. The description correctly implies a no-argument full dump.

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

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

The description names a concrete resource (the credit book) and its contents (per-credit and book-wide mass conservation totals), which is more specific than the bare name 'book'. But it uses no verb and does not distinguish itself from siblings like list_credit, net_position, or verra_supply that also expose credit/position data.

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 call this versus list_credit, net_position, or verra_supply, and no prerequisites or exclusions. The agent must infer usage purely from the phrase 'full credit book'.

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

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

The description says the operation is 'exactly-once (idempotent on purchase_id)', but the annotations declare idempotentHint=false. That is a direct contradiction on a key behavioral property, which is especially important for a mutating purchase/retirement tool. Payment escrow and dry_run context are useful, but the contradiction mandates a low score.

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 compact and front-loaded, starting with the core action and then explaining matching, idempotency, output, settlement, and dry_run. Every sentence adds useful information without repetition.

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 mutating tool with an output schema, the description covers the operation, matching behavior, idempotency intent, certificate return, escrow settlement, and dry_run semantics. The main incompleteness is that the idempotency statement conflicts with annotations rather than clarifying them.

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 mass_g as the amount retired, purchase_id as the idempotency key, and dry_run as a non-mutating preview. Buyer is only minimally described as 'for a buyer', but the other three parameters are clarified well.

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: 'Retire mass_g of verified credits for a buyer.' It also explains matching, certificate output, and escrow settlement, so the agent can understand the operation without opening the schema. It does not explicitly distinguish itself from the sibling buy_offset_budget tool, keeping it just below 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 description gives clear context for using dry_run=true to preview without mutating the book. However, it never states when to choose buy_offset over buy_offset_budget or when not to use this tool, so usage guidance is mostly implied rather than explicit.

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 genuinely useful behavior beyond the annotations: cheapest-first ordering, a hard no-overspend guarantee, and dry_run=true previewing without mutating. However, 'Idempotent on purchase_id' directly contradicts the annotation idempotentHint=false, and idempotency is exactly the property an agent relies on when deciding whether a retry with the same purchase_id is safe — this conflict is safety-relevant and undermines the rest of the 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?

Three tight sentences with the allocation rule and budget constraint front-loaded, followed by the caller profile and then the idempotency/dry-run notes. No filler; every clause conveys a distinct constraint.

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

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

An output schema exists, so return values need no explanation, and the description covers allocation strategy, budget semantics, preview mode, and use case. The residual gaps are the undefined 'buyer' parameter and the unresolvable idempotency conflict with the annotations.

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 carries the burden and mostly does: it defines budget_minor's semantics (exact cost must fit inside, never overspends), purchase_id's role (idempotency key), and dry_run's effect (preview without mutating). Only 'buyer' is left undefined — the agent cannot tell whether it is an account ID, address, or display name.

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 (money-denominated offset purchase) and the exact allocation rule: retire the maximum cheapest-first verified mass whose exact cost fits inside budget_minor. The 'money-denominated' framing and 'exact cost fits inside budget_minor (never overspends)' cleanly separates it from the sibling buy_offset, which is presumably mass-denominated.

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 selection condition — 'Built for callers whose restoration obligation is a currency amount — e.g. a revenue share accrued in a ledger' — which tells the agent when this tool applies versus a quantity-based purchase. It stops short of naming buy_offset explicitly as the alternative to use when the obligation is expressed in mass/tonnes.

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

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

The description says 'Idempotent on batch_id', but the annotations declare idempotentHint=false, which is a direct conflict on the one behavioral trait an agent uses to decide whether retrying is safe. Beyond that conflict, the description does disclose genuinely useful behavior (hash-chained, never disbursed twice, only newly-accrued proceeds for verified projects), but the idempotency contradiction undermines the reliability of the whole behavioral statement.

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 dense sentences, each doing work: creation semantics first, then the idempotency and scoping rules, then the downstream use. The parenthetical '(content-addressed, hash-chained)' is compact and informative; 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 mutation tool with an output schema, the description supplies the needed effects and constraints: what gets frozen, which proceeds qualify, and no double disbursement. The main gap is that it gives no permission or prerequisite information and contradicts the idempotency annotation, which an agent must resolve before calling.

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?

There is a single parameter and schema description coverage is 0%, so the description carries the burden. 'Idempotent on batch_id' is the only added meaning: it tells the agent that batch_id is the deduplication key. It never says where batch_id comes from, what format it takes, or whether it must be pre-registered by disbursement_schedule.

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: 'Freeze the current disbursement schedule into a certified, tamper-evident batch (content-addressed, hash-chained)'. That is clearly distinct from siblings like verify_disbursement, verify_certificate and settlement_batch, which verify or settle rather than certify.

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

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

The closing sentence gives a clear decision context: this produces the record that the CEO executes actual Stripe transfers against, so an agent knows to call it before real money moves. It never explicitly excludes alternatives or names verify_disbursement/settlement_batch as the thing to use instead, so routing is implied rather than spelled out.

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

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

The description adds genuinely useful behavior beyond the annotations: what is removed (active fill path), what is preserved (listing and retirement history for audit), and the auth requirement. However, it asserts "Idempotent for an already-delisted credit" while annotations declare idempotentHint=false, a direct conflict that could lead an agent to retry a delist expecting a no-op and instead produce additional side effects.

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

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

Three tight sentences with no filler; the operation and its scope lead, followed by the idempotency note and the auth precondition. Every clause carries information an agent would otherwise have to infer.

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 values need not be explained, and the audit-retention and auth details cover the main behavioral questions for a mutation tool. What remains missing is any account of the two required parameters and the resolution of the idempotency conflict, which for a state-changing admin call is a meaningful 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 0% — both credit_id and reason are bare typed fields with no titles beyond their names. The description never mentions either parameter, so it does not clarify identifier format, whether reason is free text, constrained, or surfaced in the audit record, or that both are required.

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 and resource (remove a credit from the active fill path) and states the precise semantic scope: the listing and retirement history are retained rather than destroyed. That distinguishes it from list_credit or the retirement/verification siblings, which touch the same credit object without changing its fill eligibility.

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?

"Admin operation" plus "Gateway state-change authentication is required" gives a clear precondition and audience, so an agent knows this is a privileged state change rather than a query. It stops short of naming an alternative path (e.g., a permanent retirement/cancellation tool) or stating when not to delist, so it is context-rich but not fully 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so 'Read-only' in the description is largely redundant. The one genuinely new behavioral fact is 'free' (no cost/quota impact), plus the 'call it first' sequencing advice.

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 verb and the enumerated output, followed by the cost and ordering hint. Nothing 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?

An output schema exists, so return shape need not be spelled out, and the description already names the key fields it yields. For a no-arg, read-only meta tool, an agent has everything needed to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it needs no arguments. Baseline for a 0-param 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?

States a specific verb ('Describe') and resource ('this agent') and enumerates exactly what is returned: name, version, purpose, supported actions, and their inputs. No sibling tool does self-description, so an agent can distinguish it immediately from the artifact/certificate tools.

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

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

Explicitly says 'call it first to learn how to use this server', which is a concrete usage trigger and ordering instruction. It lacks a when-not condition or named alternative, but no sibling is a plausible substitute for self-description.

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

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

The description explicitly says 'Read-only,' but the annotations declare readOnlyHint=false. That is a direct contradiction of the tool's safety and mutation profile. Although the description adds useful business behavior about the 15%/85% split and pending_registration, the contradiction is a serious behavioral transparency failure.

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 compact and front-loaded, leading with the preview purpose and then describing the split and pending_registration handling. It is efficient overall, though the closing parenthetical 'can't pay an unverified project' restates the pending_registration reason.

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 an output schema, so return values need not be explained, and the description covers the core financial split and pending_registration behavior. However, for a financial preview tool it omits parameter behavior and contradicts the annotations on read-only status, leaving an agent with an incomplete and unsafe invocation picture.

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 one parameter, project_id, with 0% description coverage, so the description must explain its meaning. It never mentions project_id or clarifies whether it scopes the preview to a single project or whether omission produces a global schedule. The parameter remains effectively 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 clearly states a specific operation: an automated disbursement preview that splits newly-accrued proceeds into a Viridis Conservation withhold and project payout. It does not name or differentiate itself from relevant siblings such as certify_disbursement, verify_disbursement, or settlement_batch, which keeps it from 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 description implies usage through 'Automated disbursement preview' and states that it applies to verified restoration projects, with unregistered projects surfaced separately. However, it gives no explicit when-to-use versus alternatives, no prerequisites, and no guidance on whether project_id should be supplied for a single project or omitted for a global preview.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that the record is a past purchase or offset certificate retrieved by id; it does not describe not-found behavior or access requirements, but the annotation coverage lowers the burden.

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

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

A single short sentence with the action and scope front-loaded. There is no redundant or filler text.

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

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

For a simple one-parameter read tool with rich annotations and an output schema, the description is minimally sufficient to invoke it correctly. However, it leaves gaps around when to choose this lookup versus sibling verification/list tools and gives no detail on the identifier format.

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, but 'by id' only loosely restates that purchase_id identifies the record. It gives no format, expected value, or distinction from other id parameters in the sibling tools.

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 ('Fetch') and resource ('past purchase / offset certificate') scoped by id. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as verify_certificate or list_credit.

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 guidance on when to use this tool versus alternatives. It does not say whether it is intended for retrieving a purchase after buy_offset, whether it should be used instead of verify_certificate, or any preconditions for the lookup.

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

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

The description clearly describes a state-changing operation: a credit 'enters the book' and must pass verification before it can, and it is paired with a sibling called delist_credit that reverses it. Annotations declare readOnlyHint=true and destructiveHint=false, which directly conflicts with that. An agent relying on the annotation would treat a write as a safe 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?

Three sentences with no filler, and the hard prerequisite is front-loaded ahead of the optional registry path. The only small cost is that the first sentence carries the ambiguous 'list' framing that the rest of the text has to repair.

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 values needn't be described, and the verification prerequisite plus the Verra path are well covered. For a state-changing tool with contradictory annotations, though, it omits what an agent most needs: whether listing is reversible and how, duplicate-listing behavior, and any permission or identity requirement tied to issuer.

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 10 parameters, so the description carries the load and partially does: verification_ref is explained as a D-Score/land-verification attestation, and registry/vcs_project_id/serial_number/vintage/methodology are tied to the Verra cross-reference flow. However, issuer, project_id, mass_g and especially price_minor_per_kg (minor units per kg is not obvious) are left undocumented, so several required parameters remain cryptic.

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 says 'List a conservation credit on the book,' which names a resource but uses 'list' — a verb that reads as enumeration in most MCP catalogs while here it means creating a sell-side listing. Phrases like 'unverified credits cannot enter the book' and the sibling delist_credit disambiguate it, but the agent must do that inference. It never explicitly contrasts itself with delist_credit or the buy_offset family.

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 real conditional guidance: verification_ref is stated as REQUIRED with the consequence ('unverified credits cannot enter the book'), and it names the exact condition and parameter for the Verra path ('To trade on the Verra network, pass registry="verra"' plus the VCS provenance fields). What's missing is any when-not-to-use guidance or routing to delist_credit/buy_offset.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description only adds that results are 'registered' projects carrying metadata, which is modest added context with no detail on ordering, result count, or whether the list is exhaustive or truncated.

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 or repetition. It is appropriately sized for a parameterless list operation, though it is so terse that it leaves behavioral questions unanswered rather than wasting words.

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 the description needn't explain return values, and with zero parameters and full annotation coverage the burden is low. The only missing piece is whether the list is ever paginated or capped, which matters for a 'list all' tool in a domain with sixteen 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?

This tool takes zero parameters, so the baseline of 4 applies. The description correctly makes no parameter claims and introduces no ambiguity.

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

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

The description uses a specific verb ('List') and a well-scoped resource ('all registered restoration projects with their metadata'), which is unambiguous. However, it doesn't explicitly distinguish itself from other read-side siblings like list_credit or verra_supply, leaving the agent to infer the boundary from the resource name 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?

The word 'all' implicitly signals a full-collection retrieval with no filtering, which is the primary usage cue. There is no explicit guidance on when to use this over register_project or project_funding, and no mention of whether it should be used before a detail lookup or as a discovery step.

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 and idempotentHint=false, meaning the call may write state, yet the description reads like a pure calculation and says nothing about side effects, ledger writes, or idempotency. With annotations covering safety but the description implying a read-only computation, the agent gets no added behavioral context and may be misled about 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?

Two short sentences, front-loaded with the core calculation, with no filler. The carbon_accountable clause is somewhat cryptic and partially redundant given the output schema, but the overall structure is efficient.

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?

Although an output schema exists (so return values needn't be explained), this is a two-parameter tool with 0% schema description coverage and a non-read-only annotation. The description does not explain buyer semantics, emitted_g units, or what state (if any) the call changes, so an agent lacks enough context to invoke it 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 compensate for both parameters. It partially explains emitted_g by noting it comes from the agent-compute-ledger, but never clarifies the buyer parameter or the unit/format of emitted_g, leaving the schema gap largely unfilled.

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 calculation (emitted minus retired) tied to a buyer and a ledger, which identifies the resource. However, it lacks an action verb (compute? record? fetch?) and does not distinguish the tool from siblings such as get_purchase or verify_retirement, leaving the agent to infer that this computes a net position rather than records one.

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 guidance on when to use this tool versus alternatives like buy_offset or verify_retirement, nor any prerequisites or exclusions. The sentence about carbon_accountable implies a post-offset check, but usage context is only weakly 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?

The description carries real behavioral content: it discloses that figures are earned/owed rather than paid and that settlement happens outside this tool. However, it asserts "Read-only" while the annotations declare readOnlyHint=false — a direct mismatch that forces the flag, even if the annotation is merely the MCP default being corrected.

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 definition is front-loaded with the ledger meaning, then units, then the parameter rule, then the safety note — no wasted clauses. The closing line ("what makes the clearinghouse fund restoration") is motivational rather than operational, but it is short.

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 fields, and it covers purpose, parameter behavior, and the paid-vs-owed distinction. The only real gap is the read-only claim disagreeing with readOnlyHint=false.

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 schema never explains that an empty project_id means "all projects," so the description's "Pass a project_id for one project, else all" adds genuinely missing semantics. It stops short of describing the expected ID format.

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 defines the resource precisely as a supply-side disbursement ledger showing what each project has earned from retirements and is owed, naming the units (gross_proceeds_minor + retired_g). That is specific enough to separate it from settlement_batch or disbursement_schedule, 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?

"Pass a project_id for one project, else all" gives concrete invocation guidance, and "Read-only — the CEO settles the actual payout" effectively excludes the settlement use case and points the agent elsewhere. It does not name which sibling tool to use for payouts, so alternatives are only implied.

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

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

Annotations already declare the write/idempotency/destructiveness profile, and the description adds genuinely new behavior: verification is a hard gate and project_id is immutable once registered. Missing auth/permission expectations and what happens on duplicate registration keeps it from 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?

Three short sentences, each load-bearing: what it does, the hard requirement and its rationale, and a mutability constraint. The verification requirement is front-loaded rather than buried.

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 values needn't be described, and the critical immutable/verification constraints are covered. However, for a mutation tool with 7 mostly-undocumented optional fields, the agent lacks guidance on what to supply and has no statement about duplicate-registration failure or permissions.

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 7 parameters, so the description must carry the burden — but it only explains verification_ref (with examples like D-Score/land-verification/registry id) and project_id's immutability. Five parameters (name, location, beneficiary, methodology, registry_ref) get no semantic explanation anywhere.

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 ("Register a ... restoration project") plus the downstream purpose (retirements against its credits can be funded), which goes beyond a bare restatement of the name. It does not name a sibling like list_projects or delist_credit to explicitly distinguish itself, so 4 rather than 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?

Gives a clear precondition — only verified conservation is funded and verification_ref is mandatory — which tells the agent when this tool is applicable. It stops short of stating when NOT to use it or naming an alternative path for unverified projects, 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.

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

The description calls this 'Read-only cash-settlement summary' while annotations declare readOnlyHint=false, a direct conflict about the tool's safety profile. Beyond that, it adds nothing about sums being computed server-side or what the statement contains beyond the listed 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?

A single front-loaded sentence with the key claim first and the parenthetical field list kept tight. Slightly dense in the middle clause, but 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?

An output schema exists, so return values need not be explained, and both parameters are covered. However, the contradiction with the readOnly annotation leaves an agent uncertain whether calling this is a safe read, which is critical missing context for a no-annotation-compatible mutation flag.

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 and largely does: it defines the scope of 'buyer' (whose retirements) and gives 'since' both its semantics (incremental window) and its format (ISO-8601), which the bare schema 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?

States a specific verb and resource — a read-only settlement summary of a buyer's retirements, with the exact sums included. It clearly separates this aggregate statement from per-record siblings like get_purchase or verify_retirement, though it never names an 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?

The phrase 'the statement a human settles in one transfer' implies the settlement reconciliation use case, and 'optionally since an ISO-8601 timestamp' implies incremental statements. There is no explicit when-not guidance and no sibling tool is named as an 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?

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description earns credit by explaining what verification actually entails (hash recomputation plus ledger lookup), which tells the agent this is a deterministic recomputation rather than a mere lookup. It stops short of describing outcome behavior (what a mismatch looks like, whether ledger state can change the answer).

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 sentence, front-loaded with the verb and resource, with the mechanism in a trailing clause. 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. But for a tool whose only input is an opaque nested object, the description leaves the agent without enough to construct a valid call, which is the one gap that matters here.

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 parameter is a nested object with additionalProperties:true, so the schema gives the agent no idea what fields a certificate must contain. The description does nothing to compensate — it never sketches the certificate shape, required fields, or an example. This is the definition's biggest weakness.

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 ('Verify an offset certificate') and goes further by naming the mechanism: recompute the hash and check the ledger. That clearly separates it from verify_disbursement and verify_retirement, though it never explicitly contrasts itself with those 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?

No guidance on when to call this versus the sibling verify_* tools, no prerequisites, and no statement of what a caller should do with a failed verification. The use case is only implied by the word 'verify'.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuine value beyond them by stating it recomputes the hash chain and checks whole-book conservation, which tells the agent what the check actually validates.

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

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

Two sentences, front-loaded with the operation and scope, with no redundant or filler text. Every clause adds 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description is fairly complete, though it could state what a failed verification implies or how the audit result should be interpreted.

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?

Zero parameters, so there is nothing for the description to disambiguate. The baseline for a param-free tool 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?

Uses specific verbs (recompute, confirm) against a concrete resource (disbursement certificate hash chain, whole-book conservation of disbursed proceeds). It is clearly a verification tool, but it never names or contrasts the closely related sibling verify_certificate, so an agent must infer the distinction.

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 'Any party can audit disbursements' implies an auditing context but gives no explicit when-to-use, when-not, or alternative (e.g., verify_certificate vs verify_disbursement). Usage is left to inference despite obviously similar 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' repeats structured data. What the description does add beyond annotations is the matching rule (offset_ref = purchase_id) and the shape of the verdict; it does not state what happens when no matching retirement exists or how partial coverage is judged.

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

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

A single dense paragraph, front-loaded with the identity and the assertion being tested, followed by the return shape. The leading 'x402-C C4 check' code is opaque filler, but the rest earns its 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?

Given an output schema exists, listing return fields is redundancy, but the description otherwise supplies the missing parameter semantics and the decision rule the agent needs. Only the default-required_g behavior and the no-match case are left unaddressed.

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 the load: it does explain that purchase_id is matched against offset_ref and that required_g is the gram threshold to clear. It omits the meaningful default of required_g=0 and whether units/rounding are enforced, leaving a real gap for a 2-param tool with no schema docs.

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 (confirm/verify) and resource (a retirement of conservation credit) plus the exact quantitative condition (retires at least required_g grams). The 'offset_ref = purchase_id' mapping makes the check concrete. It does not explicitly differentiate itself from the nearby sibling verra_retirement_record, which an agent could plausibly confuse it with.

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 'the check that lets a carbon receipt's neutrality claim be honored' implies the context in which to call it, but no alternatives or exclusions are named — nothing says when to prefer this over verra_retirement_record or verify_certificate.

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

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

The description says 'Read-only,' but the annotations declare readOnlyHint=false. This is a direct contradiction of the tool's behavioral safety profile, so the description cannot be trusted on this dimension.

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 then adds submission context. It is reasonably concise for the amount of domain context, though the parenthetical about future auto-posting is marginally extra.

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 values need not be fully explained, but the description contradicts annotations and leaves both input parameters undocumented. For a two-parameter tool with 0% schema description coverage, this is not complete enough to guide reliable invocation.

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

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

The input schema has zero description coverage for two parameters, including the required purchase_id. The description lists output record fields instead of explaining what purchase_id or retirement_reason mean or how they affect generation.

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: generate a Verra-portal-ready retirement record for a retirement made against Verra supply. It also names the key record fields and the registry cross-reference, which distinguishes it from sibling tools such as verify_retirement and verra_supply.

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

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

The description gives clear usage context: it applies to a retirement made against Verra supply and the generated record is submitted under the Viridis Verra account to finalize on-registry retirement. It does not explicitly name alternatives or exclusions, but the triggering condition is clear.

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

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

The description asserts 'Read-only,' while annotations declare readOnlyHint=false — a direct contradiction on the most important behavioral trait. The fee-split sentence adds economic context but does nothing to resolve whether the call mutates state or is safe to retry (idempotentHint=false).

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 lead clause front-loads the resource, which is good, but the closing sentence about retirement revenue splits is irrelevant to deciding whether and how to invoke the tool. The two-word 'Read-only.' claim is both wasteful and actively misleading given the annotations.

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 values need not be explained, and with zero parameters the call surface is trivial. What remains missing is the essential bit — what the tool actually does — plus a contradiction with annotations that could cause an agent to treat a non-read-only call as safe.

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 explain; the baseline for a no-arg tool is 4. The provenance fields mentioned (project id, serial, vintage) describe returned data, not inputs.

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 resource ('the tradeable Verra VCS book' of credits with project id, serial, vintage), so an agent can tell roughly what domain it covers. But it is a noun phrase with no verb: it never says whether the tool lists inventory, returns a summary, or prices the book. With siblings like 'book' and 'list_credit' in the same family, the boundary is not established.

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 call this versus alternatives — not even versus the obviously adjacent 'book' or 'list_credit' tools. The only conditional sentence ('Every retirement nets the project 85%...') describes a business rule, not invocation guidance.

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