vealth

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

The description discloses important behavioral traits: only the hash is sent ('You send only the hash, never the file'), the anchoring happens in a weekly batch ('It lands in the next weekly Base batch and the Ethereum root'), and it is free with no account or payment required. These details go beyond typical descriptions, though it doesn't cover potential failure modes or the return format.

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

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

The description is front-loaded with the core purpose and includes multiple useful details (privacy, batching, cost) without excessive fluff. It is somewhat long but every sentence contributes value, making it reasonably concise for the information conveyed.

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

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

Given the tool's simplicity (2 params, no output schema) and strong schema descriptions, the description provides sufficient context: security model, timing, and cost. It explains what happens after submission (weekly batch, Ethereum root) and notes verification is possible, though it doesn't explicitly direct users to verify_anchor.

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 already describes both parameters thoroughly: sha256 includes format and how to generate it ('64 lowercase hex characters. Get it with: shasum -a 256 <file>'), and label includes privacy warning. The description adds no new parameter-specific meaning beyond reinforcing that the hash is the only data sent.

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: 'Anchor the SHA-256 of any file onchain, free.' The title reinforces this with 'Timestamp a file onchain so you can prove you had it first.' It distinguishes from sibling tools like verify_anchor by focusing on the submission/timestamping action rather than verification.

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

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

The description explicitly advises when to use the tool: 'Use it the moment you produce something whose PRIORITY matters: a security finding before you disclose it, research before you share it, a draft before you send it out.' While it doesn't explicitly mention alternatives or exclusions, the use-case guidance is clear and contextual.

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

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses that the data is live and never cached, that the tool is free and keyless, and explicitly states it is read-only. It also provides a public mirror URL, giving additional transparency about the data source.

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

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

The description is two sentences, front-loaded with the primary purpose, and every word adds value. It efficiently covers what the tool returns, optional behavior, caching behavior, access requirements, and a public mirror without any redundancy.

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

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

Given the tool's simplicity (3 optional params, no output schema), the description is complete. It specifies what data is returned, how to use the optional location parameters, and the operational characteristics (live, free, keyless, read-only). No significant information gaps remain for an agent to correctly select and invoke this tool.

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

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

The input schema already provides 100% coverage for all three parameters, so the baseline is 3. The description adds extra meaning by explaining that passing a location triggers nearby work counting, which clarifies the purpose of the latitude, longitude, and radiusKm parameters beyond their individual schema descriptions. This elevates the score to 4.

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

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

The description clearly states the tool's function: it returns live counts from the Vealth work board, including total and open work, claims, settlements, proposed value, and sector breakdown. It also distinguishes itself from sibling tools (which focus on individual work items, claims, proofs) by focusing on aggregate board statistics.

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 provides clear context on when to use the tool: for live board statistics, with the option to pass a location to count nearby work. It does not explicitly state when not to use it or name alternatives, but the context makes the primary use case obvious, and the optional location parameter is explained.

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

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

With no annotations provided, the description carries the full burden and does exceptionally well. It discloses that 'this server never takes payment or holds a wallet,' clarifies that 'Vealth does NOT sell paper offsets,' and warns that 'The estimate is orientation only, never a precise carbon claim.' These are key behavioral and safety traits that go beyond simple read/write semantics.

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 verbose and includes a long, multi-clause sentence explaining Vealth's business model. While the core purpose is front-loaded, much of the text could be tightened without losing meaning. It is not tautological, but it does not earn every sentence's place.

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

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

For a simple estimation tool with no output schema and no annotations, the description is quite complete. It explains what the tool returns (CO2e estimate plus ecological work), provides caveats about precision, and guides the user to the next step (find_work). The lack of an output schema is partly compensated by the explicit mention of 'PLUS the real, verifiable ecological work.'

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

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

Schema description coverage is 100%, so both parameters ('calls' and 'tokens') are already described in the schema. The description adds little beyond restating that you should 'Give a rough token or call count,' which mirrors the schema's 'approx number of model calls' and 'approx total tokens.' No meaningful extra semantic detail is provided.

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

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

The description clearly states the tool's function: 'Give a rough token or call count for your AI session and get an order-of-magnitude CO2e estimate PLUS the real, verifiable ecological work you can provision to answer it on Vealth.' It explicitly names the resource (CO2e estimate) and distinguishes itself from sibling tools by mentioning 'Call find_work next to pick the work,' indicating this is the starting point.

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 provides clear context: it is 'the anchor tool,' implying you should start here, and it recommends 'Call find_work next to pick the work.' It also sets expectations by noting the estimate is 'orientation only.' However, it does not explicitly state when not to use this tool or mention any alternatives besides find_work, so it lacks strong 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?

With no annotations, the description carries the full burden. It discloses that the tool is free, requires no account or wallet, and searches a public board. However, it does not mention rate limits, pagination, or behaviors when no results are found, leaving some gaps.

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

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

The description is three sentences long, front-loaded with the core function, and each sentence serves a purpose: function and result details, access requirements, and usage guidance. There is no redundancy or 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?

The description covers the tool's purpose, typical use cases, result fields, and access constraints. Since there is no output schema, it appropriately outlines key return elements (pay, skill level, proof, URL). It doesn't address error handling or workflow integration, but that is not critical for a straightforward search tool.

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

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

All six parameters have substantial schema descriptions (100% coverage), so the baseline is 3. The description adds context about result contents but does not provide additional parameter-level semantics beyond what the schema already states.

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 verb 'search' and the resource 'Vealth's public board of real ecological and community work packets.' It distinguishes itself from siblings like get_work_packet by emphasizing the act of searching rather than retrieving a specific packet.

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

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

It explicitly provides usage context: 'Use this when someone asks for work, a job, a task, or something to do near a place.' This gives clear direction but stops short of listing when not to use it or recommending alternative sibling tools.

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

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

With no annotations provided, the description fully discloses behavioral traits: it is read-only, charges nothing, marks nothing funded, derives price from the board (not user input), handles partial funding and premiums, and describes refusal scenarios. This is exactly the kind of context needed.

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 long but every sentence carries important nuance about pricing, partial funding, refusals, and read-only behavior. It is reasonably front-loaded with the core purpose, but could be slightly tightened without losing value.

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 purpose, read-only nature, pricing inputs, partial funding, refusals, and next steps. However, it does not explicitly state what a successful quote response contains (only that refusals come back in board's words), which is a minor gap given the absence of an output schema.

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

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

The schema already describes workId as 'The packet id, from find_work,' providing 100% coverage. The description does not add additional parameter meaning beyond referring to 'one board packet,' so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: to ask whether a board packet can be funded and what it costs. It uses a specific verb ('ask') and resource ('one board packet'), and distinguishes itself from sibling tools by explicitly saying 'For a BUYER, not a worker' and directing to 'Call prepare_funding next to actually pay.'

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

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

The description explicitly tells when to use this tool (for buyers checking funding feasibility) and when not to (not for workers). It also names the alternative tool (prepare_funding) for actually paying, providing a clear next step and contrasting with this read-only quote tool.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It mentions the return content (full description, proof requirement) but does not explicitly state that the operation is read-only, or mention error conditions, permissions, or side effects. The 'get' nature suggests safety but it is not explicitly disclosed.

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

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

The description is a single sentence that is front-loaded with the key action and scope. Every word adds value, with no redundancy or 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?

The tool is simple with only one parameter, and the description explains the return includes full detail, description, and proof requirement. However, since there is no output schema, the description could more fully enumerate the fields included in 'full detail' to be completely thorough.

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

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

Schema coverage is 100% with a single parameter (workId) already described with an example. The description adds no new parameter semantics beyond 'by its id', so the baseline of 3 applies.

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

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

The description clearly states the tool's function: retrieving full detail for a single work packet by its ID, including description and proof requirement. It distinguishes from siblings like find_work (search) and work_status (status) by focusing on comprehensive detail retrieval.

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 when you have a packet ID and need complete details, but it does not explicitly mention alternatives or when not to use it. There is no comparison to sibling tools like find_work or work_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?

With no annotations provided, the description carries the full burden and does well: it discloses that claiming is free, that the tool only returns instructions, and that the actual claim requires the worker's own wallet signature. This meaningfully sets expectations, though it could elaborate slightly on the 'what happens after' portion.

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

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

The description is two sentences, front-loaded with the primary purpose, and every sentence adds value. There is no filler or repetition of schema or title content.

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

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

For a tool with no parameters and no output schema, the description covers the essential context: purpose, action boundaries, cost, and a key prerequisite (wallet signature). It could be slightly more specific about the format or steps included in the instructions, but it is sufficiently complete for an informational tool.

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

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

The tool has zero parameters, so the schema is inherently complete. The description provides all necessary semantic context by explaining what the tool does and returns, and no parameter explanation is needed.

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

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

The description uses a specific verb ('Explains') and clearly identifies the resource ('how to claim work and what happens after'). It also explicitly distinguishes itself from claim-execution tools by stating it never performs the claim, which differentiates it from siblings like submit_claim and prepare_claim.

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 makes the informational use case clear: it returns instructions rather than executing the claim. It implicitly tells the agent when to use this tool (when guidance is needed) versus when to use a claim-performing sibling, though it does not explicitly name alternatives or state 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?

With no annotations, the description carries the full burden. It discloses that claiming is free, costs no gas, and the signature is proof of ownership, not a payment. It also warns against sharing private keys and specifies the 5-minute window for the next step. This is rich, accurate behavioral disclosure.

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

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

The description is four sentences, each packed with essential information: what it does, what it returns, the free nature, and the required follow-up. No fluff or repetition. It is front-loaded with the core action and remains highly 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?

For a prepare-style tool without an output schema, the description explains both return values (MESSAGE_TO_SIGN, BODY_JSON), the signing requirement, the security caution, and the next step with a time limit. It fully orients the agent within the claim flow, leaving no critical gaps for 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?

Schema coverage is 100%, and both workId and workerWallet have descriptive one-liners. The description adds contextual flow but does not elaborate on parameter syntax or extras beyond the schema. Per the rubric, baseline 3 applies when schema does the heavy lifting, and this description provides marginal added value.

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

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

The description clearly states the tool's action: 'Start claiming a packet for a wallet you control.' It also specifies the exact outputs (MESSAGE_TO_SIGN and BODY_JSON) and positions itself as 'step 1 of 2', distinguishing it from submit_claim. This is a specific verb+resource with clear scope.

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 provides clear context for when to use the tool: as the first step in claiming a packet, followed by 'call submit_claim within 5 minutes.' It implicitly contrasts with submit_claim and other siblings, but does not explicitly state when not to use it or list alternatives. The step-by-step guidance is strong, but exclusions are missing.

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

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

With no annotations, the description fully discloses behavior: it reads live data from the door ('at this moment'), conditionally returns a checkout URL, and explicitly states that 'this server holds no funds and no keys, takes no payment, and marks nothing funded.' It also clarifies that funding is only confirmed after payment settles and is verified — no hidden 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?

The description is a single paragraph but well structured: purpose first, then conditional details, then payment process. Every sentence adds necessary information; no fluff. Slightly long but justified by the complexity of the payment flow.

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 no output schema, the description explains what will be returned (x402 challenge fields, checkout URL when applicable) and how to proceed (include contributeUsd for partial payment). It covers the full context a buyer needs, including the server's role and how funding is marked. Complete for the tool's complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying that funderWallet is only needed for the onchain challenge and not for the card path, and that workId comes from find_work. This goes beyond the schema's plain descriptions.

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

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

The description clearly states the tool does 'returns the live payment requirements for funding a packet' — a specific verb (returns) and resource (payment requirements for a packet). It specifies the onchain x402 challenge and hosted checkout URL, and the 'Step 2 for a buyer' context differentiates it from find_work (step 1) and funding_quote (likely a static quote).

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

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

It explicitly says 'Step 2 for a buyer', indicating when in the workflow to use it. It also gives conditional guidance: when a card rail is mounted, a checkout URL is returned, and how to contribute a slice via contributeUsd vs paying the full wage. It doesn't explicitly compare to alternatives like funding_quote, but the workflow step provides clear context.

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

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

With no annotations, the description carries the disclosure burden. It reveals the return values (MESSAGE_TO_SIGN, BODY_JSON), the 5-minute validity window, and the cost claim (free when signed). It also references the gate refusing geolocated proof without GPS. However, the poetic phrase about 'the right to be asked for nothing' is ambiguous and obscures the actual cost/charging behavior, slightly reducing clarity.

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 moderately compact but contains an unclear, poetic sentence about charging that adds noise without clear value. The core information is front-loaded and structured, but the ambiguous phrase and somewhat rambling tone make it less crisp than it could be.

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

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

For a step 1 of 2 tool with no output schema, the description adequately covers the input relationship, return values, timeout, and next step. It references get_work_packet for the proof line, but does not explain the signing process or how BODY_JSON is used in submit_proof, which is acceptable for a preparation step.

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 descriptions already cover all 5 parameters, but the description adds workflow meaning: claimId comes from submit_claim, workerWallet must match the claiming address, proof items must match the packet's proof line, and field work requires GPS photos. This enriches parameter understanding beyond the bare 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 title and description clearly state the tool's purpose: preparing a signed proof of finished work, step 1 of 2. It specifies the resource (proof) and action (prepare), and distinguishes it from sibling submit_proof (step 2) and prepare_claim (claim vs proof).

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 provides clear workflow context: after completing work, pass the workId, claimId from submit_claim, wallet, and matching proof items, then sign and call submit_proof within 5 minutes. It names the next step explicitly but does not discuss when not to use the tool or compare with alternatives like prepare_claim.

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

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

With no annotations, the description carries the transparency burden. It explicitly states 'it never spends, never holds funds, never signs,' and describes the return as 'the packet and the path.' This discloses the tool's non-financial side effects clearly, though it does not cover persistence or auth requirements.

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 three sentences, each contributing: the first defines the input-output relationship, the second adds safety guarantees, and the third adds lifecycle context. It is efficient, though the first sentence is somewhat long.

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

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

For a 5-param tool with no output schema, the description covers inputs, returns, key fields of the packet, and safety behavior. It lacks error/failure details, but the core context needed to invoke the tool is present. The mention of 'approved proof retires carbon' provides useful lifecycle context.

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

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

All 5 parameters have schema descriptions, so the baseline is 3. The tool description adds meaning by mapping parameters to the two invocation scenarios: place+problem (query, latitude, longitude, radiusKm) versus board packet id (workId), clarifying the 'or' relationship that the schema leaves ambiguous.

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 ('turn into provisioned work') and clearly defines the output as a bounded packet with scope, method, proof requirement, tCO2e estimate, and funding path. It distinguishes itself from siblings via 'provision, not offset' and the reference to find_work in the schema, making the tool's role unique.

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 clearly states two input modes: 'a place + problem' or 'a board packet id', which tells an agent when to use this tool. It does not explicitly name alternatives or exclusions, but the context is sufficient to differentiate from sibling tools like find_work.

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

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

No annotations are provided, and the description compensates well by stating the server never performs the retirement, never holds a wallet, and that the transaction is keyless from the caller's wallet. It also includes a disclaimer about orientation vs precise carbon claim. Missing are specifics about irreversible consequences or required wallet balance, but overall good.

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 that front-load the core action, but include some verbose asides like 'via the Klima rail' and the orientation disclaimer. It is concise enough, though the final sentence is somewhat tangential.

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

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

There is no output schema, but the description explains the return value as a confirmed retire transaction and instructions. It lacks details on error handling or prerequisites, but given the tool's guidance nature, it is reasonably complete.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal parameter context beyond the schema, only referencing the tCO2e amount.

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

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

The description clearly states the tool's purpose: retiring a specified tCO2e amount on-chain via the Klima rail and returning a confirmed retire transaction as the certificate. It distinguishes from siblings by specifying the real on-chain retirement action and the certificate output.

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

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

It implies usage for actual carbon retirement when a user wants to retire tCO2e on-chain, with instructions returned. However, it does not explicitly mention alternatives or when not to use, such as for estimated footprints.

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

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

With no annotations, the description carries the full burden. It discloses the server's role as a relay, states it holds no keys or funds, and notes that without the signature it can do nothing—providing essential trust/security context. It also mentions the success return value (claimId).

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 three sentences long, each earning its place: the first instructs what to pass, the second explains the server's behavior, and the third highlights the return value and its importance. No fluff or redundancy.

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

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

The tool has only two params, no annotations, and no output schema. The description sufficiently covers the required inputs, the flow (step 2 after prepare_claim), the non-custodial nature, and the value of the returned claimId for proof submission. Missing error behavior is a minor gap given the straightforward context.

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

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

Schema description coverage is 100% for both parameters, and the description essentially restates the same information (bodyJson from prepare_claim unchanged, signature over MESSAGE_TO_SIGN). It adds no novel parameter semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's action ('Complete the claim') and identifies the resource (the signed claim from prepare_claim). It distinguishes itself from siblings by explicitly referencing 'prepare_claim' and the signature requirement, positioning it as the second step in a two-step process.

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 provides strong contextual usage guidance: it references prepare_claim as the source of BODY_JSON and MESSAGE_TO_SIGN, calls itself 'step 2 of 2' in the title, and notes that the claimId is needed for proof submission. It does not explicitly list when-not-to-use alternatives, but the sequence 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?

With no annotations, the description carries the behavioral disclosure. It reveals approval mechanics (creator approval or self-verification), differentiates outcomes for funded vs unfunded packets, and directs to work_status for progress. This provides meaningful expectations for the call's 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?

The description is two sentences, with the first sentence front-loading the action and inputs. The second sentence adds consequential details without padding. It is appropriately sized for the tool's complexity.

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

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

The description effectively covers the full workflow: inputs, approval, payment/credit implications, and status tracking. For a tool with no output schema or annotations, this provides sufficient context for an agent to understand the tool's role and expectations.

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 already documents all three parameters with clear descriptions, covering 100% of them. The description reinforces the need to pass bodyJson unchanged and signature over MESSAGE_TO_SIGN, but adds no new parameter-level meaning beyond the schema.

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

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

The description clearly states the tool's function: relaying the signed proof to the public completion gate, specifying the required inputs (workId, BODY_JSON, signature). It distinguishes itself from siblings like submit_claim by referencing prepare_proof and signed proof specifically.

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 a sequential workflow by mentioning inputs from prepare_proof and noting that work_status shows the current state. It implicitly positions this tool as step 2 of 2, but does not explicitly mention when to use an alternative like submit_claim. It gives clear context for when it should be invoked.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns a merkle proof and transaction for independent verification, that it is keyless, and that it is free. This goes beyond a simple 'verify' label by explaining the trust model and output contents.

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

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

The description is two sentences, front-loads the core action and output, then adds use cases and key properties. No wasted words; every sentence contributes value.

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 is simple (one parameter, no output schema). The description covers input, output semantics, use cases, and trust model. It could mention error behavior or the exact response shape, but for a verification lookup it is sufficiently complete.

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 coverage is 100% for the single parameter, and the description does not add any additional semantic meaning beyond what the schema already provides. It simply repeats 'SHA-256 of a file' without adding format, constraints, or examples beyond the schema.

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

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

The description clearly identifies the tool's function: given a SHA-256, it reports anchored status, timestamp, merkle proof, and transaction. It distinguishes itself from siblings by focusing on independent verification and document-holding confirmation, with concrete use cases.

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 states when to use the tool: to confirm someone held a document at a claimed time, or to confirm your own submission landed. It does not mention when not to use it or name alternative tools, but the use cases provide clear context.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the certificate is signed and re-checkable, that there is 'no oracle, no judge' (implying decentralized verification), that physical claims are not faked but routed to human review, and that the caller pays. It does not mention failure modes or side effects, but the provided behavioral traits are substantive and useful.

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 three sentences but wordy, with metaphorical language like 'Vealth's paid verification door' and 'no oracle, no judge'. It could be tightened to two sentences without losing meaning. The first sentence does front-load the core action, but the overall structure is not maximally 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?

Given no output schema and no annotations, the description should explain return values, errors, and payment mechanics clearly. It gives a high-level overview but does not specify what the certificate looks like, how payment is executed, or what happens on failure. It is moderately complete for a tool with one required parameter, but leaves gaps.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal parameter-level meaning beyond the schema, only reiterating the 'proof URI' and adding that it must be live. It does not elaborate on workId, standard, or definitionId, which remain adequately described already.

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 clear action ('Check a proof URI is safely machine-checkable') and a concrete outcome ('a SIGNED, re-checkable certificate'). It distinguishes itself from siblings by focusing on work claims and the digital vs. physical routing. However, the 'exact path to Vealth's paid verification door' phrasing is slightly metaphorical and could be more direct.

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 usage context: digital claims are machine-verified, while physical proof goes to human review. It also notes that the caller pays from their own wallet. However, it does not explicitly contrast with sibling tools like verify_anchor or submit_claim, nor does it state when not to use this tool.

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

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

With no annotations, the description carries full responsibility. It explicitly states 'Free, keyless, read-only,' which covers cost, authentication, and safety. It also discloses the 'honest pay status' dimension, adding context about what the status reports. Missing details about errors or rate limits are acceptable for a simple read-only tool.

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

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

The description is a single, well-structured sentence that front-loads the key purpose and lists states clearly. Every piece of information earns its place without unnecessary verbosity.

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 status tool with no output schema, the description provides sufficient context: it lists all possible status values and the additional pay status. It could mention behavior for missing/nonexistent workIds, but for a read-only status check, the coverage is adequate.

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 fully describes the single parameter workId as 'The packet id.' The description adds no further parameter semantics, so the baseline of 3 applies. No compensation needed.

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

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

The description clearly states the tool's purpose: returning the live lifecycle state of a single packet, with an explicit enumeration of all possible states and the additional pay status. It distinguishes itself from siblings by focusing on current status rather than full packet details or search.

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 title 'Where a packet stands right now' and the phrase 'Live lifecycle state of one packet' provide clear context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it, leaving some differentiation implicit.

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