Wever Labs Agent Products

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

Substantially exceeds the annotations: it discloses per-call pricing (0.10 USDC on Base), a free-call quota, that it 'creates no authority and verifies no account balance', and that 'payment access records are durable' — which usefully explains the readOnlyHint=false / idempotentHint=false annotations. It also states existing credentials and signed grants remain required for separate actions. It does not contradict the annotation set, though it omits return-shape detail.

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

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

The core purpose is buried after pricing metadata, and the 'grants no authority / creates no execution authority' disclaimer is repeated across multiple sentences, plus a redundant POST path line. Significant boilerplate that does not earn its place, and the key capability is not front-loaded.

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 13-parameter tool with no output schema and 0% schema coverage, the description adequately covers the conceptual output ('would-allow or would-deny preview') and the authority boundaries, but leaves parameter semantics and unit conventions unexplained. It is viable but has clear gaps for correct 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?

With 13 parameters and 0% schema description coverage, the description carries the full burden, and it only partially compensates by naming the evaluated categories (scope, budget, usage, expiry, per-action fee limits) that map loosely to the parameters. It never explains units (e.g., *_minor as minor currency amounts), the mode const, as_of semantics, or how allowed_product_keys relates to requested_product_key.

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+resource: 'Evaluate explicit caller-reported scope, budget, usage, expiry and per-action fee limits' and 'Returns a would-allow or would-deny preview.' This is far more concrete than the vague name/title 'Agent Allowance Console' and lets an agent tell it apart from siblings like budget-guard or payment-authority-inspector. It stops short of explicitly naming and differentiating sibling alternatives, so not 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?

It implies usage via the operating boundary ('Direct access uses x402 Base USDC settlement or the verified-wallet free tier') and clarifies this is a preview rather than an authorizing action, which implicitly says when NOT to rely on it for real authority. However, it never explicitly names an alternative tool or states the condition that selects this over siblings, leaving routing to inference.

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

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

With annotations present (readOnlyHint=false, openWorldHint=true), the description still adds real context: no live allowance or balance is read, no destination is contacted, no budget or run is reserved, and no authority is conferred. The pricing model and free-call quota are also disclosed. The negative framing is dense but genuinely informative beyond the structured hints.

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 text repeats itself almost verbatim – 'Evaluates caller-supplied policy, usage and request values only. No live allowance or balance is read, no destination is contacted...' appears twice, and the 'grants no authority' point is restated three times. It is bloated rather than front-loaded.

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

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

For a complex, nested-schema tool with no output schema and 0% parameter documentation, the description explains the authority/safety boundary well but says nothing about inputs or what the evaluation returns. An agent could not reliably construct a valid call from this alone.

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

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

Schema description coverage is 0% and five required parameters (including nested policy/usage/request objects with many sub-fields) are undocumented. The description only names 'policy, usage and request' at a high level and gives no field-level meaning, formats, or constraints for any of them.

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

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

The description does state a specific function – 'Evaluates caller-supplied policy, usage and request values only' – but it is buried under repetitive negation clauses. It never clearly frames itself alongside siblings like wever_payment-authority-inspector or wever_agent-allowance-console, so an agent must infer that this is a pre-flight budget/policy check.

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?

Pricing and free-tier mechanics are given, but there is no explicit guidance on when to call this versus the many sibling rails. Statements that 'existing product credentials, signed mandates, and single-use action grants remain required' hint at prerequisites but never translate into a use/do-not-use rule.

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

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

Rich disclosure beyond annotations: pricing (0.25 USDC/call on Base), a 10-call free wallet tier, x402 settlement path, and the fact that existing credentials/mandates remain required while the adapter supplies no credentials. readOnlyHint=false is consistent with the payment settlement implied by the paid URL. Minor gap: no mention of rate limits beyond the free-call cap.

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 text is bloated with repeated legal/pricing boilerplate: the free computation paths are stated twice ('/api/mcp or /api/service-resolver' and again 'the Labs MCP and resolver computation paths remain free'), and the boundary paragraph restates the same non-authority claims. Front-loading pricing over the tool's actual function wastes the opening the agent reads first.

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

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

With no output schema, the description should explain what the 'deterministic priorities' return looks like, but it does not. It does cover auth, pricing and boundaries adequately, so it is workable but incomplete for a tool whose whole value is its computed output.

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 as_of, services and queues are already documented in the schema. The description adds nothing about parameter format or constraints, so the baseline 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 names a specific verb and resource: 'Summarize supplied service health and queue observations into deterministic priorities.' An agent can tell what the tool produces. However, it never explicitly distinguishes itself from the many sibling rails (sla-rail, budget-guard, etc.), leaving differentiation to inference.

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

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

It gives boundary conditions ('uses supplied data only', 'no provider work, callbacks, document retrieval or signed attestations') and pricing tiers, which imply when it applies, but it never states when to prefer this over siblings like wever_agent-sla-rail or wever_agent-budget-guard. Usage is implied rather than directed.

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 only carry the safety flags (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true). The description adds meaningful context beyond them: 0.10 USDC per call on Base with 10 free signed-wallet calls per rolling 30 days, a 402 x402 billing flow, required credentials/mandates/action grants, 'this adapter grants no authority and never supplies server credentials', and durable records. That is substantial behavioral disclosure beyond the structured 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?

The core purpose and operating boundary are stated in tight sentences, but the definition leads with billing/402 detail ahead of what the tool actually does, and the closing credential/adapter boilerplate and '/api/operations-contract' pointer dilute the payload.

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 7 required params, a nested-ish schema, 0% schema description coverage and no output schema, the description does well on the output side (discloses scores, evidence gaps, ties, no optimality claim) but leaves the input contract largely unexplained. Adequate for a complex tool, but missing parameter-level completeness.

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 all 7 required parameters, so the description carries the full burden. It loosely gestures at criteria/constraints/options, but never explains 'mode' (const 'evaluate'), the 'usage' enum (synthetic vs operational), or 'idempotency_key' semantics, so an agent cannot confirm parameter meaning from the prose.

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

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

The second sentence gives a specific verb+resource: 'Evaluate supplied alternatives against explicit weighted numeric criteria and constraints, with transparent scores, evidence gaps and ties.' That tells an agent exactly what the tool computes. It does not explicitly name the sibling it differs from, though the compute-an-evaluation role is distinct from the payment/ledger 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?

The 'Operating boundary' sets a real constraint on use ('Scores use supplied evidence and measurements only') and the pricing line establishes the pay-per-call model. However, there is no explicit statement of when to choose this over a sibling or when not to invoke it; usage is implied rather than stated.

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

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

Annotations already flag destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description goes further with genuinely useful context: funds move only to immutable parties, releases pay only the payee, expiry refunds pay only the payer, API fees are separate with manual sweeps, and the adapter grants no authority and never supplies server credentials. It does not, however, disclose failure/retry behavior or what happens to partially funded escrows.

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 text is long and repetitive: the immutable-payee/immutable-payer release-and-refund rule is restated three separate times, and the front-loaded content is pricing rather than what the tool does. Several boundary sentences ('This adapter grants no authority', 'Work-order grants do not authorize payment') duplicate each other.

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 five-mode, deeply nested tool with no output schema and 0% schema description coverage, the description omits the single most important dispatch information: what each mode does and when to use it. Behavioral boundaries are covered well, but an agent cannot confidently pick prepare_funding vs fund_escrow vs release_escrow from this text alone.

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 seven parameters with deep nested objects, so the description must carry the semantic load. It alludes to signed wallet proofs, mandates, and EIP-712 release policies, which loosely map to payer_terms_signature, mandate, and release_policy, but it never explains the mode enum values, escrow_id format, idempotency_key role, or the funding_payment structure. Most parameter meaning is left undisclosed.

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 recognizable resource and scope: 'Managed Base USDC custody with verified funding, immutable parties, EIP-712 release policies, expiry refunds to the payer and a durable public release log.' An agent can tell this is an escrow custody service, though the phrasing is diffuse and never enumerates the five operational modes (prepare/fund/release/refund/read) that actually define what the tool does.

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?

Prerequisites are implied ('Existing product credentials, signed mandates, and single-use action grants remain required where applicable') and the pricing/402 hint tells the agent where to look for payment terms, but there is no explicit when-to-use guidance and no routing to or from siblings like wever_x402-payment-gateway or wever_unified-agent-checkout.

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 (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=true) only flag that this is a non-read-only, open-world, non-idempotent, destructive-capable call. The description adds substantial context beyond that: per-call pricing (0.10 USDC on Base), a 10-call free tier over 30 days, required credentials/mandates/action grants, a no-authority/no-server-credentials disclaimer, and durable records. It does not explain the practical effect of destructive=true (e.g., spend of funds, durable record writes) outright, so it falls short of a 5 and sits in mild tension with the promised "no file move/delete operations."

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 text is a dense policy paragraph that leads with pricing rather than purpose, and includes boilerplate disclaimers ("This adapter grants no authority and never supplies server credentials") that read as legal cover. The capability sentence is buried mid-block, and several sentences (credentials requirements, durable records) overlap with each other.

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 paid, wallet-authenticated, idempotency-keyed tool with nested file objects, 0% parameter coverage and no output schema, the description covers the commercial/authorization context well but omits parameter meaning and any statement of the response shape (only a passing "report bounded content metadata"). It defers the rest to /api/operations-contract, which is helpful but leaves the agent without the essentials in-line.

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 full burden for four required parameters, and it largely fails. It hints at the file model ("inline bytes only, with strict size and supported-format limits"), which loosely maps to content_base64 limits, but idempotency_key, the usage enum (synthetic vs operational), and the const mode="inspect" are never explained.

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

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

The description names specific verbs and resources: "Inspect supplied file bytes, compute content hashes, identify exact duplicates and report bounded content metadata." That is a clear, concrete capability statement. It does not, however, differentiate itself from any of the many sibling wever rails beyond implicit domain (files/hashing vs invoices, escrow, SLA), so it stops short of a 5.

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

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

It gives the operating boundary ("Inline bytes only, with strict size and supported-format limits. No remote drive access") and points to the 402 body and /api/operations-contract for terms, which implicitly tells the agent what context it needs. But it never states when to choose this tool over the sibling rails, nor what triggers a successful vs rejected call, so usage guidance is only implied.

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

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

Beyond the annotations, the description discloses the paid-access model and price, the free tier, the 402 term lookup, the mandatory ownership proof, and explicit non-capabilities ('No bill delivery, payment collection or spending authority', 'References are not independently verified'). That is meaningful behavioral context an agent cannot get from the destructiveHint/readOnlyHint flags alone.

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 same key phrases ('Private issuer-wallet invoice ledger, immutable face amount and parties, run-reference binding and recorded issuer review', 'No bill delivery, payment collection or spending authority') are repeated verbatim in the opening and the 'Operating boundary' block, wasting the most valuable positional real estate on duplication rather than new information.

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

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

For a 4-mode, 15-parameter, nested-object tool with no output schema and only coarse annotations, the description is insufficient: the payable flow, mode dispatch, idempotency behavior, and expected versioning are all undisclosed. Payment and authority boundaries are covered, but the operational core is not.

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?

With 15 parameters, nested run_binding, and 0% schema description coverage, the description carries the full burden but explains almost nothing about parameters. 'Immutable face amount and parties' and 'run-reference binding' loosely gesture at amount_atomic/buyer_wallet/run_binding, but no parameter names, formats, enum meanings (synthetic vs operational, approve vs reject), idempotency, or version semantics are clarified.

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

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

The description identifies a specific resource ('Private issuer-wallet invoice ledger') and differentiates from sibling rails (escrow-lite, work-order-rail) by being invoice-focused, but the four operations (create/read/bind/review) are never surfaced even though they are the core of the schema. The purpose is recognizable but the tool's multi-mode nature is left entirely opaque.

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 states access mechanics (x402 Base USDC settlement, 10 free signed-wallet calls, signed issuer-wallet ownership proof required) but gives no when-to-use guidance, no mode-selection guidance, and no comparison against sibling tools such as escrow-lite or work-order-rail. Nothing tells the agent which of the four modes to invoke for a given intent.

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

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

Beyond the annotations, the description discloses concrete behavioral traits: per-call cost, a free tier, where to read x402 terms ('the backend 402 body'), that no execution/quote/payment occurs, and that payment access records are durable. This is meaningful disclosure. It stops short of a 5 because much of the text restates the same 'no authority' point repeatedly rather than adding new traits.

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 opens with pricing rather than purpose, then repeats the 'grants no authority / bounded computation' claim across three separate sentences. Significant redundancy and back-loaded legal boilerplate reduce signal density.

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 four required parameters including a nested object and no output schema, the description omits both parameter semantics and the shape of the prepared workflow it returns. Payment and boundary context is covered, but the operational essentials an agent needs to call and interpret the tool are missing.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it explains none of the four required parameters (mode, agent_id, product_key, constraints) or the nested booleans (include_checkout_estimate, include_allowance_preview, include_proof_preparation). Only faint echoes ('no quote obtained', 'proof verification') hint at the constraint flags.

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: 'Prepare an ordered sequence of supported planning and computation steps with explicit required fields,' and explicitly disclaims execution ('No step is executed, no quote obtained'). However, the purpose is buried behind payment and boundary boilerplate in the opening sentence, and it names no sibling tool to distinguish itself from the many *_rail and workflow peers.

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 context through the pricing model ('0.10 USDC per call on Base; 10 signed-wallet free calls') and prerequisites ('Existing product credentials, signed mandates, and single-use action grants remain required'), which helps an agent understand the conditions. But it never states when to choose this over siblings like wever_agent-work-order-rail or wever_unified-agent-checkout, leaving routing to inference.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds genuinely useful context beyond them: it grants no spending authority, performs no external permission verification, never supplies server credentials, and defers enforcement to target systems. Pricing and free-call quota are also disclosed. It does not, however, explain what a revoke destroys or whether expired grants are retained.

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

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

The opening sentence front-loads pricing and free-call details before the tool's actual function, and the body is a dense run-on string of clauses. Much of it is load-bearing (boundaries, auth requirements), but the ordering buries the purpose and the structure is hard to parse.

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 13-parameter, four-mode tool with no output schema, the description omits mode-specific behavior, the list/evaluate return semantics, and nearly all parameter meaning. It compensates partially with solid operating-boundary statements, but an agent cannot invoke the modes correctly from this alone.

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 13 parameters, so the description must carry the semantic load, and it largely does not. It never explains idempotency_key, expires_at, the synthetic/operational usage enum, grant_id formatting, or offset/limit, and the 'list' mode is not even mentioned as a capability. Only the high-level grant/revoke/evaluate concepts are conveyed.

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+resource pair: persisting wallet-scoped permission grants/revocations and evaluating a subject/action/resource against those records. That distinguishes it reasonably well from siblings like wever_agent-budget-guard or wever_payment-authority-inspector. The payment/pricing preamble pushes the core purpose into the second sentence, but the purpose itself is clear.

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 states prerequisites ('Existing product credentials, signed mandates, and single-use action grants remain required') and a boundary ('Target systems must enforce resource access'), which implies context. However, it never says when to use this versus the many overlapping siblings (delegated-authority, payment-authority-inspector, trust-scorecard), nor which mode is appropriate for which situation.

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 destructive=true, idempotent=false, openWorld=true, but the description adds material context they do not carry: the exact price (0.10 USDC per call on Base), the rolling-30-day free-call allowance shared across signed wallets, the no-authority/no-credential stance, and that records are durable. This is genuinely additive. It stops short of explaining what gets mutated per mode or what the retry_limit actually triggers, keeping it out of 5 territory.

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 dense and front-loads the pricing/402 mechanics before the actual purpose, which is arguably the wrong lead for an agent deciding whether to call it. Several sentences are boilerplate ('See /api/operations-contract,' 'This adapter grants no authority'), and none of the freed space is used to explain the modes.

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 10 parameters, a three-way oneOf discriminator, no output schema, and annotations that only give coarse hints, the description does not explain which mode to select, what each mode returns, or how expected_work binds to the free-call/payment allowance. The heavy lifting is delegated to an external /api/operations-contract document the agent may not be able to read.

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 full burden and largely fails: mode, idempotency_key, sla_id, callback_probe_id, expected_work kinds, usage enum, retry_limit, and deadline_at are never explained. Only loose echoes appear ('wallet-scoped SLA terms,' 'deadlines,' 'callback observations'), which do not tell the agent how to populate a three-variant oneOf.

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 concrete dual purpose: 'Record wallet-scoped SLA terms and evaluate deadlines against retained completed-work or callback observations,' which is a specific verb+resource and separates it from siblings like escrow-lite or invoice-rail. It does not, however, surface the three operating modes (record/evaluate/retrieve) that the schema actually exposes, so the agent must open the schema to learn the tool does more than one thing.

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?

Usage context is implied (post to /api/agent-sla-rail, read the 402 body for x402 terms, credentials required where applicable) but there is no explicit when-to-use vs when-not-to-use guidance and no sibling alternative is named. The 'Operating boundary' paragraph usefully excludes non-goals (no enforcement, scheduling, or consent), which is stronger than nothing, but it is about scope rather than invocation choice.

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=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, consistent with a signed-pack mutation tool. The description adds real value beyond them ('Fresh signed wallet proof is required even for paid calls', 'Handoff permissions require recipient enforcement', 'Stored evidence is not automatically verified'), but it also carries off-topic boilerplate ('Scores are bounded evidence summaries, not global reputation') that appears copy-pasted from a scorecard sibling and dilutes 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?

The core sentence 'Build and verify durable signed task handoff packs with authenticated sender, recipient, context, declared permissions and checkpoint state' is repeated nearly verbatim as the 'Operating boundary', wasting a full sentence. Pricing is correctly front-loaded, but the paragraph mixes payment terms, boundaries, endpoint routing and unrelated reputation language without clear ordering.

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, 8-parameter, dual-mode tool with no output schema, the description does cover the build/verify split, permission enforcement and evidence-limits semantics. It still omits expected return shape (a signed pack in build, a verdict in verify) and the meaning of several inputs, so it is only partially sufficient.

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 8 parameters with nested objects and enums, so the description must carry the load. It names sender, recipient, context, permissions and checkpoint state, mapping loosely to recipient_wallet, task.context, permissions and state.checkpoint, but never explains mode, idempotency_key, usage, or the evidence_sha256 array semantics, leaving most parameters undocumented in both places.

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 pair and resource: 'Build and verify durable signed task handoff packs with authenticated sender, recipient, context, declared permissions and checkpoint state.' An agent can tell this constructs/validates a signed handoff artifact rather than a work order or ledger entry. It does not name or contrast any of the 27 sibling rail/ledger tools, so the differentiation work is left to the agent.

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 two modes (build vs verify) are implied by the schema consts and the mention of 'Build and verify', and prerequisites are hinted ('Existing product credentials, signed mandates, and single-use action grants remain required where applicable'). However there is no explicit when-to-use-this-vs-alternative guidance, which matters sharply given the crowded sibling set of similar-sounding rails.

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=false, destructiveHint=true, openWorldHint=true, so the safety bar is partly met structurally. The description adds real context (402 payment terms, required signed-wallet proof, recipient enforcement for handoff permissions, 'scores are bounded evidence summaries, not global reputation'), but never explains what the destructiveHint=true behavior actually destroys or mutates. The boilerplate 'grants no authority' language even reads as harmless-compute, leaving the destructive annotation unelaborated.

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

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

The core sentence is duplicated verbatim as both the opening and the 'Operating boundary' paragraph, and legal boilerplate ('This adapter grants no authority...', 'Signed records attest only to the stated evidence...') crowds out actionable content. Poor front-loading ratio of signal to 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?

With no output schema, three required parameters at 0% schema coverage, and a destructiveHint=true annotation, the description should explain return values, mutation semantics, and parameter contract. It instead repeats itself and defers to /api/trust-contract, leaving an agent unable to predict inputs or output.

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

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

Schema description coverage is 0% and there are 3 required params including two nested arrays, so the description carries the full documentation burden. It only loosely names the evidence categories ('completed work', 'Base payment receipts', 'escrow refunds') and says nothing about the payment/evidence item fields, nonce formats, or the maxItems limits (5 and 10).

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

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

The first operative sentence states a specific verb and resource: 'Compute a bounded trust score from verified completed work, Base payment receipts and Wever escrow refunds.' An agent can tell this is a scoring/attestation tool rather than a payment or escrow rail. It does not name any sibling tool, so no differentiation credit above 4.

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

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

It gives meaningful prerequisites (paid URL at 0.10 USDC, 10 signed-wallet free calls per rolling 30 days, 'Fresh signed wallet proof is required even for paid calls') and points to the 402 body for x402 terms. However it never says when to choose this over siblings like wever_receipt-passport or wever_payment-authority-inspector, so use is only implied.

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

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

With annotations present, the description goes well beyond them: it discloses that no POST is submitted, no worker assigned, no result delivered, no execution authority or proof verification created, and that server credentials are never supplied. This is meaningful behavioral context. It is not a contradiction that readOnlyHint=false coexists with 'no execution authority', since durable payment-access records are explicitly disclosed as a write side effect.

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 entry is bloated and repetitive: 'grants no authority', 'creates no execution authority', and 'bounded computation on caller-supplied data' are restated three times. Payment terms are front-loaded before the tool's actual purpose, so the definition is not well front-loaded for selection.

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-required-parameter, nested-object tool with no output schema and no parameter descriptions, the description covers behavioral boundaries well but leaves parameter semantics entirely unexplained. An agent cannot reliably populate mode, product_key, or requested_outcome from this definition alone, so it is incomplete for correct 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 description coverage is 0% across 5 required parameters, so the description must compensate and largely does not. It does not explain mode (the const), product_key (the enum of supported products), requesting_agent_id, or requested_outcome; only 'task' is obliquely referenced via 'validate a task'. An agent must open the schema and guess at semantics.

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

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

The sentence 'Validate a task against a supported computation and prepare its fixed POST request' gives a specific verb+resource and scope, and 'No request is submitted, worker assigned or result delivered' sharply bounds what the tool does versus post-commit siblings. It is clear enough to distinguish from execution-oriented siblings, though the core purpose is buried mid-paragraph under payment boilerplate.

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 sketches an operating boundary (x402 Base USDC settlement or verified-wallet free tier, with existing credentials/signed grants required for consequential actions), which implies when to use it. However, it never names or contrasts an alternative sibling (e.g. work-order-rail, paid-workflow, x402-payment-gateway), so the routing decision is left to inference.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false. The description adds substantial context beyond that: pricing (0.10 USDC/call, 10 free calls), the x402 402-body terms, credential requirements, and explicit negatives ('performs no provider work, callbacks, document retrieval or signed attestations'; 'grants no authority'). These are real behavioral disclosures, though the boundary prose is repetitive.

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 passage is long and front-loads payment terms rather than the tool's purpose, repeating the free/paid distinction and the 'bounded computation' claim multiple times. Core intent is not front-loaded, and several sentences are boilerplate that restate the same boundary.

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, all four parameters are undocumented, and the description never explains what the tool returns or how the prepared task is consumed. It over-invests in payment/legal framing while omitting the parameter and result information an agent actually needs 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?

Schema description coverage is 0% with four required parameters (service_id, recipient_id, available_evidence, expected_evidence). The description explains none of them – not the service_id constant, the recipient_id 'mbx_' pattern, nor the evidence arrays and their duplicate/normalization rules. The schema carries almost everything and the description adds nothing.

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 core action is stated: 'Prepare a validated DiligenceOps task for a specific Connect recipient,' which gives a verb and resource. However, it is buried after payment logistics and legal boilerplate, and the description never differentiates this 'work-order-rail' from close siblings like wever_agent-work-order-exchange or wever_agent-decision-packet-rail. Purpose is inferable but the agent must dig for it.

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 lists paid vs free computation paths and notes that 'submission, recipient permission and execution remain separate steps,' which is mild workflow context. It never says when to choose this tool over the many sibling rails, nor which recipient/permission prerequisites actually gate a successful call.

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 destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description meaningfully extends this: single-use consumption ('durably consumes each mandate once'), replay/expiry rejection, required signed-wallet proof even on paid calls, and the 402/x402 payment terms. This adds behavioral context the annotations cannot express.

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

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

The description is dense and repetitive, restating that it does not execute the checkout or transfer funds and that it consumes the mandate once. It is information-rich but not front-loaded on purpose, opening with pricing. Much earns its place, but trimming repetition would improve structure.

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 destructive, open-world payment-verification gateway with no output schema, the description covers pricing, credential requirements, profile scope, and the authoritative starting endpoints. It is nearly complete, with the main gap remaining the undocumented input parameters.

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 all three parameters, so the description carries full responsibility but only vaguely alludes to them ('binds the presenter to the holder wallet', 'challenge_token' via /api/ap2-challenge). It never explains the expected form of 'presentation', 'challenge_token', or the fixed 'mode' value, leaving the parameters undocumented in both places.

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: it 'Verifies allowlisted AP2 direct closed-checkout mandates, binds the presenter to the holder wallet, rejects expiry and replay, and durably consumes each mandate once.' It also names its profile boundary (trusted-provider direct closed-checkout) which helps distinguish it from siblings like x402-payment-gateway. However, the first sentence leads with pricing rather than purpose, slightly diluting focus.

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

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

It clearly defines an operating boundary ('No open mandates, delegation chains, checkout execution, payment execution or fund transfers') and points the agent to the entry endpoints ('Start at /api/ap2-contract and /api/ap2-challenge'). It states when the tool applies but never names a sibling as the alternative, so it stops short of explicit when-not guidance.

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

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

Annotations only give the safety profile (readOnly, openWorld, non-idempotent, non-destructive); the description adds substantially more: 0.10 USDC per call on Base mainnet via x402 exact, a shared pool of 10 signed-wallet free calls per rolling 30 days, the X-Wever-Wallet-Proof binding requirement, and an explicit authority ceiling (no writes, trading, fetches, spending or publication). It even explains the non-idempotency implied by the annotations via per-call usage recording and payment settlement.

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

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

Front-loads purpose and data-source distinction in the first two sentences, then moves to billing/auth, then authority limits. Dense but each sentence carries operational weight; the contract-doc pointer at the end is slightly trailing but still useful.

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 paid, proof-gated tool with no output schema and one parameter, the description covers pricing, quota, auth binding, data provenance and authority scope, and lists the passport's constituent sections. It stops short of describing the actual return shape or the failure/402 flow in detail, deferring that to external docs.

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

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

Schema description coverage is 100%, so the single 'asset' parameter is already fully documented with pattern, length bounds and a case-insensitive example. The description's 'by its id or ticker' adds nothing the schema does not already say, so the baseline 3 applies.

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

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

States a specific verb and resource ('look up a covered tokenized asset by its id or ticker and return its full sourced Asset Passport') and enumerates the payload sections. It also carves out what the tool is not ('not live market quotes'), but it never names the obvious sibling wever_atlas-asset-search, so the agent must infer the routing itself.

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

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

Usage is implied rather than stated: the 'not live market quotes' clause hints at when this is appropriate, and the pointer to /api/atlas-contract covers schema questions. But there is no explicit when-to-use or when-not-to-use against wever_atlas-asset-search, which is the most likely alternative for asset lookups.

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

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

Goes far beyond the annotations: it discloses paid pricing (0.10 USDC/call via x402 exact), a rate limit (10 signed-wallet free calls per rolling 30 days), the required X-Wever-Wallet-Proof binding to exact JSON args and path, header-forwarding behavior, and an explicit read-only authority list. Annotations only cover the safety profile, so this text carries substantial extra operational context.

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

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

Purpose and scope are front-loaded in the first two sentences, and most sentences carry distinct information (data source, result provenance, endpoint, billing, auth, authority). It is dense and slightly over-loaded with negation lists and billing meta, but nothing is truly redundant.

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

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

With no output schema, the description does describe the return shape ('paginated summaries') and result provenance (source dates and provisional/unverified labels), and it covers billing, auth, and authority constraints. Only the limit/offset parameter semantics remain thin, so it is nearly complete for a 4-param read 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?

Schema coverage is 50% (query and category documented; limit and offset not). The description hints at pagination and 'within the result limit' but adds no format or default detail for limit/offset, and its query/category phrasing largely restates the schema. It partially compensates for the gap but not fully.

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 (search) and resource (covered tokenized assets) with the retrieval mechanism (literal text or category) and return shape (paginated summaries). It also distinguishes the data source ('versioned Atlas reference dataset, not live market quotes'), though it never names the nearest sibling (wever_atlas-asset-passport) to route the agent 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?

Provides one useful behavioral rule ('Empty arguments list all covered assets within the result limit') and a pointer to /api/atlas-contract for exact terms, which implies usage. However, it never says when to choose this tool over atlas-asset-passport or any other sibling, so the routing decision is left to inference.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses that release is atomically credited once, that the treasury is order-scoped and simulated, that the order token is a capability rather than authentication, and hard limits (120 virtual USDC, 64 orders, 2 MiB, 24-hour expiry). It also states isolation from production custody/dispute records and that real escrow caps are unchanged.

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 main operation is front-loaded and every following sentence maps to a distinct concern (action routing, exclusion rules, simulation limits, isolation). It is dense and long, and the closing "Real escrow/dispute caps and all other tools are unchanged" is borderline filler, but there is little true 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?

For a five-action, eight-parameter tool with no output schema, the description covers the action surface, rejection conditions, simulation ceilings, and dispute semantics adequately. Gaps remain in describing what status reads return and how idempotency_key interacts with the atomic credit, which matters for a write-capable 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?

Schema description coverage is 0%, so the description carries the burden, and it does name the key inputs: order_id, bearer order_token, delivery_reference, claim {reason_code, statement_sha256}, references, idempotency_key, and the action modes. It explains the role of each but not format constraints (base64-like sizes are reserved for patterns), so it compensates well without being exhaustive.

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

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

The opening clause gives a precise verb+resource ("Confirm simulated delivery of a shipped order") and then enumerates the additional action modes (dispute, dispute-status, dispute-submit-evidence, status). It explicitly positions itself relative to the standalone dispute services ("invokes existing dispute-open service"), so an agent can tell this bridged simulation tool apart from wever_dispute-open / wever_dispute-resolve.

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 routes by action and states key conditions: disputed orders cannot release, resolution is operator-authorized and "not exposed by this bridge", and payment headers / simulation=false are rejected. It does not explicitly say when to prefer the standalone dispute tools over this bridge, so a small routing gap remains, but the context 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?

Goes well beyond the annotations (which only say non-read-only, non-open-world, non-idempotent, non-destructive) by disclosing the synthetic settlement model, no real signer or funds, the 120 virtual USDC simulation ceiling vs the 25 USDC real escrow cap, 24-hour expiry, a 64-active-simulation bound, rejected payment headers, and the absence of inventory/shipping/tax/ownership checks. This is exactly the extra context an agent needs before invoking a money-shaped 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?

Front-loaded with the critical 'Simulation only' qualifier and organized roughly around create-then-continue flow. It is dense and the negative enumeration (no inventory, shipping, tax, ownership assertion, authorization, fulfillment) plus the catalog/API-fee remarks are informative but slightly beyond what is needed to call it.

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

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

For a 7-parameter, multi-action tool with no output schema and only bare annotations, the description covers simulation limits, expiry, capacity, rejection rules, and token handling. It stops short of describing what each action (especially status) returns, but the safety and lifecycle picture is otherwise 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?

Schema description coverage is 0%, so the description must carry the load and it largely does: it explains product_id, buyer_wallet, order_token (bearer token to retain), idempotency_key (exact create retries), fulfillment_reference, and the action values. It does not explain the simulation const flag or the format constraints, which the schema's patterns still cover.

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

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

Names a specific verb+resource ('Create a boutique order with product_id and buyer_wallet') and scopes it as a simulation, then enumerates the order lifecycle actions it also serves. It implicitly separates itself from siblings like wever_boutique-real-money-acceptance ('real checkout is disabled') and the catalog tools ('Catalog tools remain read-only snapshots').

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 describes the call sequence: create with product_id/buyer_wallet, retain the returned bearer order_token, then repeat the same identifiers with action=initiate_payment/simulate_payment/status/confirm_fulfillment. It states the extra requirement for confirm_fulfillment (fulfillment_reference) and the idempotency_key retry contract, and rules out what is rejected.

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, but the description adds substantial context beyond them: it discloses the data source, that prices are USDC catalog equivalents rather than merchant quotes, that tax and shipping are excluded, that null fields are unverified, that sold-out listings are labeled, that no live stock guarantee exists, and that no wallet proof or API fee is required.

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

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

The main purpose and mode selection are front-loaded in the first two sentences. The remaining sentences are dense but each contributes a distinct behavioral caveat; the only cost is that a 12-parameter tool assembled into one long paragraph takes effort to parse.

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 12 parameters, no output schema, and only annotations for safety, the description does well to cover return fields, snapshot-versus-live behavior, pricing semantics, and checkout limits. The main gap is parameter-level semantics for several fields, but overall an agent has enough to invoke the tool correctly.

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

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

Schema description coverage is 0% across 12 parameters, so the description must carry the burden. It lists most parameter names and clarifies store enum values, the availability filter, and the USDC price unit, but it does not explain nwt, sort values, page/page_size limits, or the distinction between min_price/max_price beyond their names.

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

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

The description gives a specific verb and resource ('List all nine curated pieces in the featured seasonal collection') and clearly names the two operating modes: the default nine-piece snapshot versus a full live catalog when store is supplied. It distinguishes itself from the sibling product-detail tool by describing list-level output fields (IDs, names, prices, sizes, photos, descriptions).

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

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

It gives explicit conditions for selecting each mode ('Supply store=women, men, or kids to browse the full live catalog' vs 'Omit store and filters for the legacy nine-piece snapshot'), and it rules out checkout. It does not name the sibling product-detail tool as the alternative for single-item lookups, but the mode-selection guidance is otherwise 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?

Beyond the safety annotations (readOnly/idempotent/non-destructive), the description discloses substantial behavior: versioned snapshot provenance from rebeccabelleboutique.com and Poshmark, 1 USD = 1 USDC price equivalence (not a merchant quote, tax/shipping excluded), null = unverified, sold-out listings labeled, no checkout/orders/escrow, and free anonymous read with no wallet proof. This is exactly the extra context annotations cannot carry.

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

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

The purpose is front-loaded well, but the block is dense and includes a long list of filtering parameters (store, query, size, brand, category, min_price, max_price, nwt, sort, page, page_size) that are irrelevant to a single-id detail tool, bloating an otherwise small operation.

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-param read tool with no output schema, it covers provenance, price semantics, availability labeling, no-checkout, and free access, and it names what is returned (full listing details and collection notes). Its completeness is slightly undermined by instructions that describe parameters this schema does not accept.

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?

With one required param at 0% schema coverage, the description compensates by explaining that the id comes from boutique-list-products and by enumerating live-inventory ID prefixes (rb-#####, mm-#####, lc-#####). That adds real meaning for the otherwise undocumented id. It loses a point for also listing many store/query/size/brand params that do not exist in this 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 opening sentence states a clear verb+resource+scope: read one curated piece by exact ID, sourced from boutique-list-products, returning listing details and collection notes. This distinguishes it from the sibling list tool. However, the later sentences describing store-based catalog browsing muddy the single-item purpose, since this tool takes only an id.

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

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

It implies usage by pointing to boutique-list-products as the ID source and describes the legacy nine-piece snapshot path, but never states explicitly when to use this vs. list-products or any exclusions. The 'Supply store=... to browse the full catalog' guidance does not apply to this tool's schema and misdirects rather than clarifies.

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

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

Beyond the annotations (which only declare non-read-only, idempotent, open-world, non-destructive), the description discloses what the tool will never do ("never signs, submits or initiates transfers and rejects payment headers"), the auth mechanism required per action, and the downstream fee/refund traits of the escrow rail. This is exactly the behavioral context annotations cannot express.

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

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

The purpose is front-loaded and most clauses earn their place, but the paragraph is a dense run of long compound sentences mixing tool behavior, auth, sibling-rail fees and legal disclaimers. It would scan faster as short separated lines; nothing is truly wasted, but structure is a weakness.

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 seven-action tool with no output schema, the description covers the lifecycle (create order, escrow observation, shipment, delivery, receipt verification), the public/authenticated split, and safety disclaimers. It stops short of describing per-action return content or the status action's role, leaving minor gaps given the multi-action surface.

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 reported at 100%, so the baseline is 3; the description adds value on top by indicating which action is public versus proof-bound and by characterizing the create/record/verify steps of the lifecycle. It does not explain the idempotency_key requirement or the distinction between verify_payment and verify_release, so it only partially complements 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 names a specific verb+resource (owner-operated boutique acceptance order for a dedicated 1.00 USDC test product on Base mainnet) and states scope exclusions ("No catalog items"), which separates it from boutique-list-products/product-detail. It is somewhat overloaded with disclaimers, but an agent can identify the tool's function without opening the schema.

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

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

It gives explicit conditions ("quote is public; other actions require a request-bound X-Wever-Wallet-Proof") and routes the funding/release step to the alternative ("the human executes separately approved funding and release through the unchanged wever_agent-escrow-lite tool"). It does not compare against the closer boutique siblings (create-order, record-shipment, confirm-delivery), so the routing is clear but not exhaustive.

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?

Rich disclosure beyond the annotations: 'Exact retries are safe; conflicting tracking is rejected', all USDC stays in escrow, the token is a capability and not authentication, and explicit limits (120 USDC, 64 orders, 2 MiB, 24-hour expiry) plus isolation from production custody/dispute records. This far exceeds what readOnlyHint/idempotentHint/destructiveHint alone convey.

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

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

The core action and required inputs are front-loaded in the first sentence, and most subsequent clauses carry real information. It is dense and leans on disclaimer clauses, but little is pure padding.

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

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

For a nested-object mutation with no output schema and no annotation-adjacent explanation, the description covers escrow behavior, idempotency, limits, and isolation well. It only lightly implies the resulting state ('Marks shipped') without describing the return payload, but that is a minor 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%, so the description must compensate, and it names all parameters and the tracking sub-structure. It adds genuine meaning for order_token (bearer capability, not merchant/buyer auth) but gives no per-field detail on the regex patterns, length bounds, or the const simulation=true, leaving much of the schema self-documenting only.

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

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

States a specific verb (Record) and resource (simulated shipment against a funded boutique order) and enumerates the inputs (order_id, bearer order_token, tracking {carrier, tracking_number}). This clearly distinguishes it from siblings like wever_boutique-create-order and wever_boutique-confirm-delivery.

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 clearly frames the context for use (simulation against a funded order) and gives exclusions ('Rejects payment headers and simulation=false', 'Simulation only, no real funds'). However, it does not explicitly name or route to sibling alternatives (e.g., real-money-acceptance or confirm-delivery), so the when-vs-alternative guidance is implied rather than stated.

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

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

Beyond the annotations (openWorldHint, destructiveHint, non-idempotent), it discloses pricing (0.10 USDC/call, 10 free calls per 30 days), auth requirements (signed wallet, existing credentials, mandates), operational constraints (no redirects, no credentials, public-address validation), and the important caveat that acknowledgment is not proof of downstream work. That is rich context the structured fields do not carry.

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

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

The content is dense but the delivery is a wall of run-on, jargon-heavy sentences (pricing, endpoint, contract pointer, and boundary all concatenated). It is information-rich yet hard to scan; a few structured sentences would have made the same points with less cognitive load.

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

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

For a 5-parameter, no-output-schema tool the description covers payment, auth, operational boundary, endpoint, and defers exact schemas to /api/operations-contract. It is missing the `usage` parameter semantics and any description of the persisted response shape, but overall it is sufficient for an agent 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?

Schema description coverage is 0%, so the description must carry the burden and only partially does: probe mode's callback_url and idempotency_key are inferable from 'bounded HTTPS callback probe' and 'no automatic retries', and retrieve maps to probe_id. The `usage` enum (synthetic vs operational) is never explained, and no format or constraint detail (URL length, key pattern, 64-hex probe_id) is added.

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 specific verbs and resources: send a bounded HTTPS callback probe that persists response/timing/acknowledgment, and retrieve prior observations without resending. That cleanly separates the two modes. It does not name any sibling tool, but the resource (callback health probing) is distinct enough from the payment/rail siblings to be unambiguous.

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 a concrete boundary for when this is and isn't appropriate: 'One point-in-time HTTPS observation' and 'Continuous monitoring and automatic retries are unavailable' effectively exclude the continuous-monitoring use case. It also points to the 402 body for x402 terms. No alternative tool is named for the excluded cases, so it stops short of a full routing statement.

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 destructiveHint=true, readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is partly covered. The description nonetheless adds substantial context the annotations cannot: atomic one-unit reservation, idempotency keys on issuance, credential-bound usage/attribution, the hard line that records never execute work or authorize payment, and that revocation does not undo a committed record. The repeated assertion of non-execution is the main behavioral value here.

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

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

The text is a dense wall of repeated claims: the 'does not execute work, deliver results, or authorize payment' caveat appears at least three times, and the 'GET, contract reads, drafts and all other modes have no x402 fee' point is stated twice verbatim. Billing terms are front-loaded ahead of the tool's actual function, and the structure provides no scannable separation between modes, actors and constraints.

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, multi-mode, credential-driven control plane with no output schema, the description covers the essential behavioral frame: pricing scope, per-mode credential requirements, idempotency, approval binding, atomic reservation, and the immutability/non-execution boundary. It is missing only a concise mode enumeration and any hint about result/inspection semantics, which is a modest gap given the schema already documents per-mode return 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?

Top-level schema description coverage is 0% for the lone 'mode' parameter, but the schema compensates with detailed oneOf branch descriptions for each mode, so the description only needs to add meaning. It does supply useful header semantics ('Operator issuance and grant approval require X-Wever-Operator-Key and Idempotency-Key; consumption requires the target agent's X-Wever-Agent-Key') and AP2 profile details, but it never maps its guidance cleanly onto the mode enum, leaving the agent to reconcile prose with the oneOf branches itself.

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

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

The description does state a core function ('Issue signed mandates and operator-approved action grants, then let credentialed agents consume them to create immutable work-order records'), but this is buried under pricing and liability boilerplate. It never enumerates the eight modes that actually define the tool (read_control_plane, draft_mandate, issue_mandate, issue_action_grant, execute_delegated_action, inspect_action_grant, revoke_mandate, read_audit), and it does no work to distinguish itself from the many similarly named wever_* siblings beyond a passing reference to the AP2 gateway.

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 real guidance on which actor uses which operation (operator issues/approves with X-Wever-Operator-Key; the bound agent consumes with X-Wever-Agent-Key) and on billing scope (only issue_mandate is charged). However, there is no explicit when-to-use-this-vs-a-sibling statement, no description of prerequisites for choosing a mode, and no exclusions relative to tools like wever_agent-work-order-rail or wever_ap2-mandate-gateway.

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 (readOnlyHint=false, openWorldHint=true, destructiveHint=false) cover only the safety profile, but the description adds substantial context: no provider work, callbacks, document retrieval or signed attestations; no authority granted and no server credentials supplied; existing credentials/mandates/action grants still required; pricing (1.00 USDC on Base) and the 10 free signed-wallet calls per rolling 30 days; and a pointer to the 402 body for x402 terms.

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

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

The core purpose sentence is buried mid-paragraph behind pricing and endpoint details, so the description is not front-loaded. Free-tier information is repeated ('Free computation: /api/mcp or /api/service-resolver' and again 'the Labs MCP and resolver computation paths remain free'), and the operating-boundary paragraph restates the caller-supplied-data point.

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 paid, closed-world-of-supplied-data computation with no output schema, the definition covers payment, auth prerequisites, rate limits, negative boundaries and match semantics well. It is close to complete; only the per-parameter meaning of the two evidence arrays is left implicit.

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 for the two top-level arrays is 0%, so the description must carry semantics. 'Compare explicit submitted evidence labels and return exact matched and missing items' does convey exact-match comparison semantics, but it never explains the distinction between expected_evidence and available_evidence, nor the optional/required asymmetry (available minItems 0 vs expected minItems 1) visible only in the schema.

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

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

The description states a specific verb+resource: compare explicit submitted evidence labels and return exact matched and missing items, plus a clear negative scope ('does not read or verify document contents'). It distinguishes itself from document-reading tools, though it never names a specific sibling such as wever_mcp-diligence-rail or wever_return-package-viewer that an agent must choose between.

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 identifies alternative computation paths ('/api/mcp or /api/service-resolver', Labs MCP and resolver remain free) and the paid vs free tier split, which is useful routing context. However it gives no explicit 'use this when X, use sibling Y when Z' guidance, so the agent must infer when this paid run is preferable to the free computation paths or the diligence 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?

Beyond the annotations (destructiveHint, idempotentHint, openWorldHint), the description discloses that the call atomically freezes release and refund, that 0.10 USDC is charged via x402 on Base mainnet under a 10-call/30-day free tier, that X-Wever-Wallet-Proof must be bound to the exact arguments and path, and that disputes expire after 14 days with a signed refund receipt subject to a UTC daily cap. That is unusually rich destructive/authorization/pricing 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 action and target are front-loaded in the first clause, and the dense remainder is mostly load-bearing (rejection rules, fee model, auth header, expiry). Some fragments ('No new principal enters.') border on cryptic, but there is little pure padding.

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

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

For a complex, paid, authorization-gated mutation with a nested-object schema, no output schema and no annotations covering pricing, the description covers preconditions, cost, auth binding, expiry and recovery routing. The main gap is that the shape of the returned receipt/state is never described, which matters since no output schema exists.

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

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

With 0% schema description coverage, the description partially compensates: 'claim reference' maps to the nested claim object, and 'escrow ... or ... work order' implies the oneOf choice between escrow_id and order_id. It says nothing about idempotency_key semantics or the reason_code enum, leaving roughly half the parameters undocumented in both schema and prose.

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

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

The description states a specific verb and resource – 'Either escrow party opens a dispute against already funded escrow or a funded work order' – and scopes the precondition (already funded). It is a clear, agent-legible action, though it never names or routes against dispute-adjacent siblings such as wever_dispute-submit-evidence or wever_workorder-dispute, so it stops short of full sibling differentiation.

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 concrete when-not conditions ('Rejects locked value above 25.00 USDC, unfunded or already disposed funds, and unrelated wallets') and points to /api/dispute-contract for authorization and recovery limits. It does not, however, tell the agent which sibling to use instead for evidence submission or resolution, so it is clear context without explicit alternatives.

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 flag destructive/idempotent/openWorld, and the description substantially extends them: durable nonces preventing duplicate movement on retries, a 100.00 USDC/UTC-day resolution cap, operator-signature requirement, x402 fee of 0.10 USDC plus free-call allowance, expiry-refund behavior with signed timeout receipt, and a pending external audit disclaimer. This is unusually rich disclosure consistent with destructiveHint=true.

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 signature/auth requirement is front-loaded, followed by outcomes, extension rules, pricing, and expiry. It is dense and information-heavy but nearly every sentence contributes operational facts; only the fee/free-call and audit-pending clauses feel like they could be trimmed from a tool-selection standpoint.

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

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

No output schema exists, yet the description covers resolution modes, extension, expiry refunds, fee model, authorization, and caps, and points to /api/dispute-contract for schemas and recovery limits. For a 9-parameter destructive tool this is nearly complete, lacking only explicit per-parameter detail.

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

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

Schema coverage is only 11% (just reason_uri), so the description must carry the load. It defines outcome values and the 'split amounts summing to the locked total' semantics for payee/payer_amount_atomic, and clarifies operator_authorization as a domain-bound signature, but dispute_id, reason_sha256, and idempotency_key are left to the reader.

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+resource (resolving a dispute) and enumerates the three settlement outcomes (release/refund/split) plus the extend action, which cleanly separates it from siblings like dispute-open and dispute-status. It never names a sibling explicitly for differentiation, but the purpose is unmistakable.

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 conditional guidance on action=extend ('permits one operator-authorized 14-day extension before expiry') and routes schema questions to /api/dispute-contract, but there is no explicit when-to-use vs. siblings (e.g., dispute-open/submit-evidence) and no stated preconditions for choosing resolve vs. extend beyond timing.

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

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

Goes well past the readOnlyHint/idempotentHint annotations: discloses the paid URL, 0.10 USDC per call via x402 exact on Base mainnet, the shared 10 free signed-wallet calls per rolling 30 days, the mandatory X-Wever-Wallet-Proof header bound to the exact JSON args and path, that fees are separate from locked principal, the 14-day expiry with signed timeout refund subject to settlement confirmation and UTC daily cap, and that external custody/security audit is still pending.

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

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

Purpose is front-loaded in the first clause, then payment/auth/mutation-boundary details follow in reasonable order. The single dense block is somewhat run-on (payment, expiry, audit and contract pointer all chained), but nearly every sentence carries information an agent needs.

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

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

For a one-parameter read tool with no output schema, it covers the operation, payment/auth requirements, mutation prohibitions, expiry behavior and where to find schemas. The one notable gap is that nothing describes the returned receipt-chain contents or the dispute_id it must supply.

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, but it never explains dispute_id — not the dp_ prefix, the 64-hex format, nor whether it identifies the dispute being read. 'Requires a party wallet proof' concerns auth, not the parameter.

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 (Read) and resource (the dispute and full operator-signed receipt chain) and enumerates the scope it covers: opening, evidence submissions, extension, resolution or timeout. This clearly separates it from the mutation siblings wever_dispute-open, wever_dispute-submit-evidence and wever_dispute-resolve.

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

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

Explicitly frames this as the read path ('Read-only: no settlement, signing or reconciliation'), which routes an agent away from the mutating dispute tools, and points to /api/dispute-contract for schemas and recovery limits. It does not, however, name a sibling alternative or state when reading is preferable to e.g. wever_dispute-resolve.

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

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

Goes well beyond the annotations, disclosing that raw personal information is rejected, that both parties can read the evidence and its signed receipt, that fees are separate from locked principal and grant no resolution authority, that disputes expire after 14 days with timeout refunds, and the x402/wallet-proof auth model. These are exactly the mutation, auth, cost, and lifecycle traits an agent needs that the annotations cannot express.

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

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

Front-loads the core action before the payment, expiry, and audit caveats, and most sentences carry operative constraints. It is dense and includes arguably boilerplate tails ('External custody and security audit remains pending. Company-authored.'), but little of it is strictly redundant.

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, monetized, mutation tool with no output schema, the description supplies the missing behavioral and economic context (payment model, wallet proof, expiry/refund, contract pointer). It is only short on per-parameter detail, which the 0%-covered schema leaves as a 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% and the description does not compensate. It conveys the gist that references are 'evidence hashes and URIs' and that no raw personal data is allowed, but says nothing about the dispute_id format, the idempotency_key semantics, or the 1-4 item bound. Two of three parameters are effectively unexplained in prose.

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

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

States a specific verb and resource: 'Either party submits bounded evidence hashes and URIs,' which is precise about what the tool does. It is distinguishable from siblings like dispute-open and dispute-resolve by the evidence-submission focus, though it never explicitly names those alternatives. Clear but not maximally differentiated.

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?

Provides an implicit precondition ('Closed or expired disputes reject evidence') and points to /api/dispute-contract for schemas and authorization, which implies usage context. However, it never states when to reach for this tool versus dispute-open, dispute-resolve, or dispute-status. Usage is inferable but not 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 goes well beyond the annotations by disclosing cost (0.10 USDC per call on Base), a free tier (10 signed-wallet calls over rolling 30 days), the endpoint (POST /api/mcp-diligence-rail), and negative behaviors: no server connection, no callbacks, no document retrieval, no signed attestations, no authority granted. It does not address rate limits or return shape, which keeps it from a 5.

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

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

The purpose sentence is buried behind pricing, and the same non-authority disclaimer is asserted three times ('This does not connect to a server or grant authority,' 'This adapter grants no authority,' 'This current operation is a bounded computation on caller-supplied data'). That redundancy crowds out the front-loaded statement an agent actually needs.

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

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

It covers pricing, boundaries, endpoint and credential expectations for a paid computation tool, which is substantive. But with no output schema and zero schema description coverage, it leaves the input contract and the result of the inventory (what the flagged findings look like) unexplained.

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

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

With schema description coverage at 0%, the description must compensate, and it does only partially: 'Inventory submitted MCP tool declarations' implies the single 'tools' array input. It says nothing about the constraints encoded in the schema (maxItems 16, 64-char name pattern, 256-byte description limit, name-required rule) that are consequential for correct invocation.

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: 'Inventory submitted MCP tool declarations and flag missing or consequential annotations.' This is a recognizable auditing action, though it is buried mid-paragraph behind pricing boilerplate. It doesn't explicitly differentiate from siblings like wever_diligenceops-paid-run or wever_permission-ledger, so it stops short of a 5.

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

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

Offers some routing context ('Free computation: /api/mcp or /api/service-resolver' and 'the Labs MCP and resolver computation paths remain free'), which implies when to use the free paths vs this paid one. However, there is no explicit when-to-use statement, no stated exclusions, and no naming of the sibling tools it competes with in the diligence/ledger family.

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 supply the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false, non-idempotent), and the description adds real context: the call is a paid settlement, the 402 body carries x402 terms, no server credentials are supplied, and settlement grants no spending authority. It does not, however, describe what a successful/failed inspection returns or what min_confirmations does at runtime, and the repeated 'read-only inspection' phrasing sits in tension with readOnlyHint=false (a payment transfer is a state change).

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 are duplicated verbatim ('Read-only canonical Base USDC receipt inspection for the configured Wever recipient' and 'Settlement evidence grants no mandate, resource permission or execution authority'), and a third concept (no spending authority) is restated three times. The task-relevant purpose sentence is not front-loaded; the opening sentence is about pricing.

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 7-required-parameter, paid, open-world tool with no output schema, the description covers the commercial/authority boundary reasonably but leaves the entire parameter surface and the return payload unexplained. An agent cannot call this correctly from the description alone.

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 required parameters (mode, transaction_hash, payer, payee, amount_atomic, authorization_nonce, min_confirmations). The description contributes nothing about any of them beyond hinting at a 'configured Wever recipient'; an agent must infer the atomic-amount format, nonce requirement, and confirmation floor entirely from regexes and bounds.

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?

Buried in boilerplate, the operative phrase 'Read-only canonical Base USDC receipt inspection for the configured Wever recipient' does state a specific verb and resource, and the POST endpoint is named. However, nearly half the text is about payment terms and disclaimers rather than what the tool does, and no sibling (e.g. wever_receipt-passport, wever_x402-payment-gateway) is named to differentiate it. Purpose is inferable but not front-loaded or distinguishing.

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 explains how access is paid (0.10 USDC/call, free tier, 402 body) but never says when to choose this inspector over the many sibling rails (receipt-passport, x402-payment-gateway, proof-inbox). No preconditions beyond 'credentials remain required', and no exclusions or alternative-tool routing are given.

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?

Extraordinarily rich beyond the annotations: it discloses that no funds move, that the $0.10 fee is separate from the payout and confers no disbursement authority, that a per-call X-Wever-Wallet-Proof bound to the JSON arguments and API path is mandatory even for paid calls, that the shared 10 free calls are consumed over 30 days, and that keys/custody/sweep remain manual. It also surfaces the holder-binding v2 / replay-ledger verification path and the audit prerequisite. The only mild tension is destructiveHint=true against 'No money moves,' but the description is disclosing commitment/irreversibility of the authorization rather than contradicting the annotation.

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

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

The core action is front-loaded in the first sentence, followed by the return value, then cost/auth/safety caveats — a sensible order for a high-risk paid tool. It is dense and long, but for a payment-authorization primitive most sentences (cost, wallet proof, custody, audit) carry decision-relevant information; only the 'no yield, conversion or fiat' clause feels like marginal marketing copy.

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 this complex — signature binding, replay defense, x402 paid access, custody constraints — the description covers the flow, the cost model, the auth requirement and the safety posture, and it states the return value even though no output schema exists. Its one real gap is parameter coverage (0% in schema, partially supplemented in prose) and its deferral of exact schemas to /api/payout-contract.

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

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

Schema description coverage is 0%, so the description must compensate. It gives real semantics for presentation (trusted-issuer AP2 signed presentation), principal_signature (EIP-712 from a configured treasury holder) and expiry, and clarifies that no private keys are accepted — but payout_id, idempotency_key and challenge_token receive no explanation at all. Half the parameters are still opaque, and the 'recipient, amount and expiry' phrasing does not map cleanly onto the actual schema fields.

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: binding an AP2 signed presentation plus a separate EIP-712 principal_signature to a payout's recipient, amount and expiry, and returns 'authorized' with a signed receipt. It also implicitly separates itself from the execution sibling by stating 'No money moves' and calling itself 'A disbursement primitive, not a bank.' However, it never names payout-create, payout-execute or payout-status, so the agent must infer the ordering rather than being told it.

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?

Usage is implied rather than stated: 'No money moves' and 'grants no disbursement authority' signal this is the authorization gate before any execution, and the reader is pointed at /api/payout-contract for the flow. There is no explicit 'use this before payout-execute' or 'do not use when X' guidance, and no sibling is named, so the agent has to reconstruct the pipeline itself.

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

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

Goes well beyond the annotations by disclosing hard caps (25.00 USDC per payout, 100.00 daily), the required X-Wever-Wallet-Proof bound to exact JSON arguments and API path, the paid URL pricing (0.10 USDC x402 on Base), the free-call allowance, and custody constraints (no private keys, manual wallet funding). The 'No money moves' claim is consistent with destructiveHint=true applying to the immutable record creation, and idempotentHint aligns with idempotency_key, so no contradiction.

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

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

The operation, caps, and auth are front-loaded effectively, but the back half drifts into tangential custody/legal boilerplate ('Ledger keys never reach the server', 'sweep and reclaim remain manual', 'Externally audited', 'Company-authored') that does not help an agent select or invoke the tool.

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

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

With no output schema, the description correctly states the return ('created with a signed receipt'), covers authorization, pricing, and caps, and points to /api/payout-contract for exact schemas. The only gap is that the 'usage' enum parameter is left unexplained.

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

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

Schema description coverage is 0%, so the description carries the burden. It names all five required parameters and adds meaningful constraint context (the 25.00 USDC cap on amount_usdc), but leaves the 'usage' enum, the address pattern, the amount string format, and idempotency_key format entirely to the schema.

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

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

States a specific verb and resource ('Create an immutable payout instruction') and enumerates the core fields (recipient, amount_usdc, idempotency_key, memo, rail_reference). It also distinguishes its lifecycle stage from the execute sibling by declaring 'No money moves', though it never names the alternative tools 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?

Usage is implied through 'immutable payout instruction' and 'No money moves', suggesting this is the first step before an actual disbursement, but there is no explicit when-to-use or when-to-prefer-a-sibling guidance despite payout-authorize/execute/status existing. The pointer to '/api/payout-contract' helps but is not usage 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?

Far exceeds the annotations: it discloses idempotency mechanics (persisted transfer nonce prevents duplicate payment on retries), the return payload (executed status, confirmed tx hash, signed receipt), the auth header requirement (X-Wever-Wallet-Proof bound to exact args and path), and the paid-call pricing model. It also clarifies no private keys are accepted and funding/sweep remain manual, which materially shapes agent behavior.

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

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

The core action, preconditions and return value are front-loaded, which is good, but the description is bloated with pricing detail and legal/marketing filler ('A disbursement primitive, not a bank: no yield, conversion or fiat', 'Company-authored; usage remains explicitly labeled') that dilutes the actionable 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?

Given no output schema, the description still explains the return shape (executed status, independently confirmed tx hash, signed receipt). Authentication, idempotency, fees and the manual-custody model are all covered, so 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?

Schema coverage is 0%, so the description must compensate. It conveys the semantics of idempotency_key (nonce preventing duplicate payment on retries) and the fact that payout_id must reference an authorized mandate, though it doesn't restate the format constraints (po_ prefix, key charset) that the schema pattern already enforces.

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 ('Disburse native USDC on Base from the dedicated service-operated payout wallet') with the exact precondition (authorized payout with a valid unexpired holder-bound mandate). This clearly distinguishes it from siblings like wever_payout-authorize, wever_payout-create and wever_payout-status.

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

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

States the gating condition for use ('only for an authorized payout with a valid unexpired holder-bound mandate') and points to /api/payout-contract for the authorization flow, which implies the prerequisite authorize step. It never names an alternative sibling explicitly (e.g. when to use authorize vs execute), so it stops short of a 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?

Goes well beyond the annotations: it discloses the paid model (0.10 USDC x402 exact on Base mainnet), the shared 10-call free tier over 30 days, that every call requires X-Wever-Wallet-Proof bound to the exact JSON arguments and API path, and that no private keys are accepted. The readOnlyHint and idempotentHint are confirmed rather than contradicted, and the custody/funding caveats add genuine invocation-relevant context.

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?

Core purpose and scope are correctly front-loaded in the first two sentences, but the remainder mixes necessary call metadata (fee, auth) with legal/trust boilerplate ('A disbursement primitive, not a bank…', 'External custody and security audit required…', 'Company-authored') that does not help an agent invoke the tool. Roughly 11 sentences is oversized for a 2-param read.

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 read-only tool with no output schema, the description covers scope, auth, pricing and custody adequately, and defers return/authorization detail to /api/payout-contract. It still lacks any statement of what a returned receipt or error condition looks like, leaving a modest 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%, so the description must carry the parameter burden. It identifies both lookup keys and clarifies that idempotency_key refers to the original create key, but it omits the po_ pattern/format and does not resolve the oneOf requirement semantics (required list is empty). Partial compensation only.

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

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

The first sentence names a precise verb (Read) and resource (a payout and its signed transition receipts) plus the two lookup keys. The clause 'Read-only: no payout state change, signing, reconciliation or transaction submission' cleanly routes it away from the write siblings (payout-create/authorize/execute).

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 makes clear this is the read path for an existing payout and points to /api/payout-contract for schemas and the authorization flow. It never explicitly names a sibling alternative or an exclusion condition, so the routing is contextually implied rather than stated.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is partly covered. The description adds genuinely non-structured behavior: cost (0.10 USDC per call on Base, 10 free calls/30 days), a mandatory fresh signed wallet proof even for paid calls, recipient enforcement for handoffs, and the caveat that stored evidence is not auto-verified. These are useful operational facts not derivable from annotations.

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

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

The text is a dense block of pricing, legal boilerplate, and repeating boundary statements ('Store, list and retrieve durable verification proofs in a private authenticated wallet inbox' appears twice). It is not front-loaded on the action; pricing leads. Much of the content is disclaimer filler that does not help invocation.

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 multi-mode tool with 6 parameters, nested proof objects, 0% schema coverage, and no output schema, the description leaves core mechanics unexplained: what each mode returns, pagination behavior, idempotency semantics, and how a proof_id is obtained. It covers cost/auth caveats but not enough for an agent to call all three modes correctly.

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

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

Schema description coverage is 0% across 6 parameters with nested objects and enums, so the description carries the full explanatory burden and largely fails it. It loosely maps 'store, list and retrieve' onto the mode enum, but says nothing about idempotency_key, offset/limit pagination, proof_id format, or the kind/content/label fields.

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 set and resource: 'Store, list and retrieve durable verification proofs in a private authenticated wallet inbox.' That is concrete and matches the three schema modes. It does not differentiate itself from siblings like proof-relay or receipt-passport, which share the proofs domain, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus proof-relay, receipt-passport, or agent-handoff-pack, all of which touch similar proof/handoff artifacts. The pricing line and the repeated 'operating boundary' sentence describe what the service is, not when an agent should select it over 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 declare readOnlyHint=false and openWorldHint=true, but the description adds genuinely useful behavioral detail: no destination is contacted, no acknowledgment obtained, nothing delivered or persisted, and no execution authority is created. It also notes that payment access records are durable, which explains the non-read-only annotation. This is real context beyond structured 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?

The text is highly repetitive, restating the no-authority/no-delivery boundary three or four times ('creates no execution authority', 'grants no authority', 'never supplies server credentials'). Payment terms lead the description while the actual purpose trails, so it is not front-loaded around what an agent needs.

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

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

For a four-parameter, 0%-coverage tool with no output schema and nested union types, the description should carry the full explanatory load. It supplies rich boundary/behavioral framing but leaves parameters and expected output entirely unexplained, so an agent still cannot construct a correct call from the description alone.

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 four required parameters, so the schema documents none of them semantically. The description alludes loosely to 'source/destination binding' and 'caller-supplied data', but never explains the mode constant, the agent/callback destination kinds, the receipt/passport/proof reference kinds, or payload_sha256. It does not compensate for the coverage gap.

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

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

The operative sentence 'Prepare a reference envelope and deterministic source/destination binding digest' names a specific verb and resource, but it is buried under dense payment and legal boilerplate. It never distinguishes itself from close siblings like wever_proof-inbox or wever_receipt-passport, so an agent cannot route confidently between them.

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 covers pricing/access (x402 Base USDC or free tier) but gives no guidance on when to choose this tool over its many siblings, nor any exclusions. Usage is only implied through the 'prepare_proof_relay' framing.

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

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

Goes well beyond the annotations by disclosing the auth requirement (configured X-Wever-Agent-Key), the cost model (item price + flat $8 shipping, $0 tax, no buyer API fees), the immutability of the intent, and the boutique quantity restriction. However, it never reconciles the 'Creates no payment or approval' / immutable framing with the destructiveHint=true annotation, which an agent will notice as unexplained tension.

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?

Roughly six short sentences, each carrying one distinct fact, with the core action front-loaded before cost, auth, and the follow-up workflow. No filler or restated boilerplate.

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

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

With no output schema, the description does tell the agent what comes back (an exact plain-language quote, a human review URL, and a customer_approval token for purchase-execute). It omits idempotency semantics and any pointer to wever_purchase-status for checking a created intent, and the referenced approval_mode is not a parameter an agent can inspect.

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

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

Schema description coverage is 0% across five required parameters, so the description must carry the load. It adds real meaning for two of them (quantity is effectively 1 per unique boutique catalog listing, and delivery_address drives the quote/shipping), but says nothing about idempotency_key, business_id, or item_id format or purpose.

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 ('Create an immutable purchase intent and exact plain-language quote') and immediately clarifies scope by noting it 'Creates no payment or approval', which separates it from wever_purchase-execute. An agent can tell what this tool produces without opening the schema.

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

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

It gives an explicit branch: if approval_mode is customer_agent, obtain the customer's approval of the quote and address and then call purchase-execute with customer_approval; otherwise use the returned human review URL. Both the alternative tool and the routing condition are named, leaving nothing to inference.

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

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

Annotations already cover the safety profile (idempotent, destructive, open-world), so the bar is lower, and the description adds real value beyond them: private statement retention, that only its digest hits the rail, operator-driven resolution, per-dispute (300 USDC) and daily (350 USDC) boutique limits, and the required X-Wever-Agent-Key header. It stops short of describing the post-submission flow.

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 tightly packed sentences with purpose front-loaded, followed by behavior/limits and then auth. Dense but each clause carries information; no preamble or restatement of the name.

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

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

With no output schema, the description supplies the key operational facts an agent needs — auth requirement, cost limits, retention model, and delegation target. The remaining gap is parameter-level detail, mitigated only partly by the schema patterns and enum.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, but it only partly does: it explains that the 'statement' is retained and its digest is transmitted. The roles of intent_id, reason_code, and idempotency_key are left entirely to the bare schema (patterns/enum only).

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

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

States a specific verb ('Open a dispute') and scopes it to 'your funded purchase', and names the underlying route wever_dispute-open, which separates it from the sibling wever_workorder-dispute. Clear purpose, though it does not explicitly contrast itself with calling wever_dispute-open directly.

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?

Implies usage ('for your funded purchase', 'existing operator resolution ... apply') and shows the relationship to wever_dispute-open, but never states when to prefer this facade over the underlying dispute tool or the workorder-dispute sibling. Guidance is 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?

Annotations declare the safety profile (destructive, idempotent, open-world), and the description adds behavior beyond that: approval is recorded before AP2 and escrow funding, there is no immediate treasury release, and exact retries reuse saved requests and 'cannot replace consent or create a second payment.' It also states the auth requirement (X-Wever-Agent-Key), which no annotation conveys.

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?

Each sentence adds a distinct constraint (consent rules, side-effect ordering, retry semantics, auth), and the primary purpose is front-loaded. It is dense and long, but there is little that could be dropped without losing a real 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?

For a complex, money-moving tool with a nested object, no output schema, and 0% schema coverage, the description covers purpose, caller eligibility, consent validity, side-effect ordering, idempotency, and auth. It stops short of describing failure modes or the state returned after execution, leaving a small residual 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?

With 0% schema description coverage, the description carries the burden and mostly succeeds, giving meaning to every nested customer_approval field (quote_sha256 as the saved quote hash, amount_atomic as six-decimal USDC, currency USD, approval_text from the quote, approved_at as Unix seconds, stable approval_id). The one gap is intent_id itself, whose role is only implied rather than described.

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

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

The first sentence states a specific verb+resource+condition: 'Execute a purchase after customer approval, without merchant review.' This cleanly separates it from siblings like wever_purchase-create-intent (which creates the intent) and wever_purchase-status (which only reads state). An agent can select it without opening the schema.

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

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

It explicitly routes by caller type: delegated customer agents may supply customer_approval attesting human consent, while 'Other agents require the human review page.' It also states when to omit the field ('to retry an already approved intent') and draws a hard boundary: 'Never supply consent before the human approves.' This is complete when/when-not/alternative guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value: the auth requirement and the boundary that "no wallet or signing instructions are returned." That output-content constraint is information annotations cannot carry.

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 tight sentences with the operation front-loaded and no wasted phrasing. The trailing sentence about wallet/signing is short and informative, though slightly tangential to the core purpose.

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

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

For a single-parameter read tool whose annotations cover the safety profile, the description gives a good sense of returned state (quote, approval, fulfillment, completion). The only real omission is any explanation of the required intent_id, and there is no output schema to lean on.

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

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

Schema description coverage is 0% and there is a single undocumented parameter (intent_id with a strict ^pi_[a-f0-9]{64}$ pattern). The description says "your own" but never explains what intent_id is, where it comes from, or its format, so it fails to compensate for the coverage gap.

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

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

The description uses a specific verb ("Read") and enumerates the resource scope precisely: purchase quote, recorded human approval, fulfillment, and completion state. This clearly separates it from create/execute/dispute siblings, though it never names an alternative 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?

It states a prerequisite ("Requires the same configured X-Wever-Agent-Key"), which implies an established session, but gives no explicit when-to-use or when-not guidance relative to wever_purchase-create-intent or wever_purchase-execute. Usage is left to inference.

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

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

Adds substantial behavior beyond the annotations: paid x402 terms, 10 free signed-wallet calls per rolling 30 days, no granted authority, never supplies server credentials, and that acceptance inputs stay labeled synthetic. Annotations already cover the destructive/openWorld/idempotency profile, so this is genuinely additive context.

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 dense wall of semicolon-joined clauses that front-loads billing rather than the action, forcing the agent to dig through payment, boundary, and credential text before reaching what the tool actually does. Sentences are run-on and repeat boilerplate ('grants no authority', 'never supplies server credentials').

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?

Annotations cover the safety profile and a contract URL is given for exact schemas, and the description does hint at returned comparisons. But with no output schema and zero parameter documentation for a complex nested case structure, an agent still lacks what it needs to construct `cases` or interpret results.

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

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

Schema description coverage is 0% across all 5 required parameters, so the description must compensate, but it never explains `cases` (six oneOf shapes), `repeats`, `idempotency_key`, the `usage` enum values, or the fixed `mode` const. Only the passing phrase 'labeled synthetic' faintly hints at the usage enum.

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 ('Execute supported bounded Wever computations') plus a distinguishing scope (measure runs, compare actual outputs against caller-specified expectations). However, 'bounded Wever computations' is opaque jargon and the description does little to separate this playground/harness tool from the ~19 similarly named 'rail' siblings.

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

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

Gives real usage context: price (0.10 USDC per call on Base), a free tier, and explicit operating boundaries (no external agent execution, no money movement, credentials/mandates required), plus a pointer to /api/operations-contract. But it never says when to pick this tool over a sibling rail tool, so routing is left to inference.

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

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

Annotations declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, idempotentHint=false. The description adds pricing terms (0.10 USDC, free calls) and boundary notes (fresh wallet proof required, stored evidence not auto-verified). However, it does not disclose what 'destructive' means here: does issuing a passport consume a free call, invalidate prior records, or fail idempotently? The annotations already cover the safety profile, and the description doesn't enrich it significantly beyond payment details.

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

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

Front-loads the paid URL term, then the core action, then a dense block of boundary statements repeated twice ('backed by completed, wallet-owned Wever computation records' appears in both the first and second sentences). Some sentences like 'This adapter grants no authority and never supplies server credentials' are boilerplate that may not help the agent. Structure is somewhat redundant but not bloated.

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

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

No output schema, 5 parameters with 0% schema description coverage, and annotations carry the safety profile. The description does not explain the return values, the shape of a passport, or the result of verification. For a complex tool with branching modes and nested objects (work oneOf), this is inadequate.

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

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

Schema description coverage is 0%, so the description must compensate, but it provides no meaning for any parameter (mode, work, usage, idempotency_key, passport). The schema only has patterns and enums without descriptions, so the agent is left to guess what 'work.kind' or 'usage: synthetic/operational' entail. This is a severe gap for a 5-parameter tool.

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

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

The description states a specific verb+resource: 'Issue and verify signed receipt passports backed by completed, wallet-owned Wever computation records.' This distinguishes it from siblings like proof-inbox or trust-scorecard. It is slightly muddled by the pricing preamble and DRM-like boundary language, but the core action is clear.

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?

Implied usage via modes (issue vs verify) and mentions of paid vs free calls, but no explicit when-to-use guidance versus alternatives. It doesn't say when an agent should call this instead of wever_proof-inbox or wever_agent-trust-scorecard.

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 only flag destructive/openWorld/non-idempotent; the description adds substantial behavioral detail beyond that: every call requires an X-Wever-Wallet-Proof bound to the exact request body, attribution rejects self-referrals and permits only the first code, claims reserve earnings and create a linked payout instruction, claim_id must be stable for retries, amounts are bounded 1.00–25.00 USDC, outstanding accruals cap at 200.00 USDC and fail closed, plus the shared 100 USDC/day payout cap and paid-URL pricing. That is exactly the kind of mutation/auth/limit context annotations cannot convey.

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 action list is front-loaded, which is good, but the remainder is a dense wall of long sentences mixing auth, economics, caps, retry semantics, and pricing without any structural separation. Every clause is informative, yet the sheer density and lack of chunking make it harder to scan than it needs to 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 multi-action payment tool with no output schema and a oneOf schema, the description covers authentication, action semantics, amount bounds, retry/reconciliation flow, caps, and where to find the full contract (402 body, /api/referral-contract). It is close to complete; minor gaps remain around what the earnings/receipt responses actually contain, though the signed-receipt guarantee is stated.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: amount_usdc is optional and requests an exact amount within the available balance (omit to take the balance up to 25 USDC), and claim_id is required to be stable across retries. It also explains the role of code_token (signed, binds attribution) beyond the raw type/pattern constraints.

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

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

The first sentence enumerates all five operations with specific verbs and resources (create rail-signed code, attribute wallet with code_token, inspect earnings, claim USDC, verify receipt), so an agent can map an intent to the correct action without opening the schema. It also names the sibling payout tools (wever_payout-authorize / wever_payout-execute) used by the treasury holder, differentiating itself from those.

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 concrete selection conditions: omit amount_usdc to claim the available balance, supply it for an exact amount within the available balance; retry the original claim after execution to reconcile; the treasury holder should use wever_payout-authorize/execute instead. It stops short of explicitly stating when NOT to use this tool versus other rails (e.g., subscription-rail, payout-create), so it is clear context without full 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?

Annotations already set destructiveHint/readOnlyHint false-equivalents, and the description adds non-structured context: pricing and free-call quota, the 402 response body, mandatory signed mandates/single-use grants, and the explicit promise that the adapter 'grants no authority and never supplies server credentials.' That said, the retrieval framing sits uneasily with destructiveHint=true and the description never explains what is irreversible (the 0.10 USDC charge), which is the one behavior the annotation is pointing at.

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?

Pricing is front-loaded and the core purpose follows immediately, which is good structure. But the text is padded with overlapping security boilerplate ('grants no authority and never supplies server credentials' next to 'credentials... remain required') and an ops-contract pointer that adds length without adding decision-relevant meaning.

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

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

For a two-parameter retrieval endpoint with no output schema, the description covers the commercial and authority context well and says what is returned at a high level ('exact result and verified digest'). It is incomplete on the two things the agent most needs at call time: the meaning of mode/work and their required identifier formats, which are undocumented in both the schema and the description.

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

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

Schema description coverage is 0% for both required parameters. The description never explains 'mode' (a const 'retrieve') or the 'work' oneOf branches ('wallet_free_call' with a nonce vs 'settled_payment' with a payment_id). Only a loose mapping exists through the mention of '10 signed-wallet free calls' and the paid URL, which is not enough to disambiguate which branch to supply.

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

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

The description gives a specific verb+resource: 'Retrieve a wallet-owned completed Wever computation from durable billing records, including its exact result and verified digest.' That is far more than a restatement of the title 'Return Package Viewer' and lets an agent distinguish it from relay/inbox/passport siblings. It stops short of explicitly naming which sibling it is not, and the surrounding boilerplate dilutes the signal.

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?

'Operating boundary: Retained owned Wever computation records only. Missing, expired or unsupported records are unavailable' gives a real when-not condition and scope limit. However, no alternative tool is ever named for the cases it excludes (missing/expired records, other wallets' records), so the agent must infer routing on its own.

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 (destructiveHint=true, idempotentHint=false, readOnlyHint=false) only sketch the safety profile, but the description adds substantial behavior: cancel has 'no mid-cycle refund,' 'no stacking within one wallet and plan scope,' auto_renew=true is rejected, expired/exhausted quota returns a per-call 402, and verification checks signature plus durable wallet record. It also documents auth requirements (X-Wever-Wallet-Proof) and idempotency-relevant constraints (stable purchase_id).

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

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

The core purpose is front-loaded, but the body is a dense run-on that mixes subscription mechanics, payment rails, auth headers, and endpoint boilerplate in one block. Some material is redundant (the shared free-call allowance is mentioned twice) and the trailing 'Paid URL / POST / Public keys' prose reads like appended marketing rather than tool guidance.

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

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

With no output schema, the description partially compensates by describing returns: 'Confirmed settlement returns a record-backed Ed25519 subscription receipt' and 'action=status shows quota and cycle end.' For a six-action tool it covers the full action surface, though the return shape of action=plans and cancel is only described qualitatively.

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 reported at 100%, so the baseline is 3, but the description goes beyond it by explaining what the fields mean operationally: purchase_id must be 'stable' across retries, plan is a server-configured quoted plan, and tool is only required for single-tool subscriptions. It also documents header parameters (Payment-Signature, X-Wever-Wallet-Proof) that do not appear in the schema at all.

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

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

The opening sentence names a specific operation and resource: 'Prepay wallet-bound 30-day tool subscriptions.' It then enumerates every supported action (plans, subscribe, status, cancel, cancel_auto_renew, verify_receipt), so an agent knows exactly what the tool covers. It also indirectly differentiates from the sibling AP2/x402 rails by describing how subscriptions interact with them.

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?

Usage context per action is explicit: 'action=subscribe requires a stable 64-hex purchase_id and plan name; single-tool also requires the covered MCP tool name,' and 'Manual renewal requires a fresh subscribe after expiry.' It also states when to omit the Payment-Signature. It stops short of naming an alternative sibling tool to use for one-off (non-subscription) payments, so it is clear context rather than full when-not guidance.

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

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

Annotations already declare read-only/open-world/non-destructive, yet the description adds substantial context: 0.10 USDC per call, 10 free signed-wallet calls per rolling 30 days, the required X-Wever-Wallet-Proof binding to exact JSON args and path, and an explicit statement that it cannot sign, submit, transfer or spend. This is rich disclosure well beyond the annotations.

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

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

The purpose is front-loaded, which is good, but the middle is dense and partly redundant, e.g. the convoluted 'API access billing is separate from wallet visibility...' sentence. Several billing/auth clauses repeat rather than sharpen the point.

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 paid read-only tool with no output schema, it covers cost, free tier, auth header binding, and safety limits, and it defers return-value schemas to /api/treasury-contract and the 402 body. It is close to self-contained, only leaning on external endpoints for the response shape.

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

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

Schema coverage is 100% for the single parameter, and the schema already documents the EIP-55 checksum requirement. The description's restatement of 'must use the exact EIP-55 checksum' adds emphasis but no meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: 'Read a wallet's native USDC balance and ETH balance for gas visibility on Base mainnet.' An agent can tell this apart from flow-oriented siblings like wever_treasury-flows. It stops short of explicitly naming an alternative, so it is clear but not sibling-differentiating.

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?

Usage context is implied ('for gas visibility') and it points to /api/treasury-contract and the 402 body for schemas, but it never states when to use this versus alternatives, nor any when-not condition. Guidance is present but inferential.

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?

Far exceeds the annotations: it discloses the paid URL, price (0.10 USDC per call via x402 exact), the shared 10 free calls over rolling 30 days, that billing is separate from wallet visibility, and that X-Wever-Wallet-Proof must bind to the exact JSON arguments and this path rather than /mcp. It also enumerates what the tool cannot do (sign, submit, transfer, spend), which the readOnlyHint alone does not spell out.

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

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

Purpose is front-loaded and there is no filler, but the description is long for a 4-parameter read tool, and the billing/auth-header material is dense enough to compete with the core read semantics. Every sentence is relevant, but the density could be tightened.

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

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

With no output schema, the description names the returned fields (amounts, timestamps, transaction hashes) and points to /api/treasury-contract for schemas, coverage and billing terms, which covers the main gaps. Minor incompleteness remains around result volume/pagination given limit defaults to 20.

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 75% and the description reinforces the key detail: wallet_address must use the exact EIP-55 checksum. It also characterizes limit and the UTC time window as bounding the returned history, adding meaning beyond the raw Schema types.

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?

Opens with a specific verb+resource+scope: 'Read recent native USDC transfers into and out of a wallet on Base mainnet,' including the fields returned. This clearly separates it from the sibling wever_treasury-balance (which reads balances, not transfers).

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 concrete constraints on usage (optional limit/time window, EIP-55 checksum requirement, directing the agent to /api/treasury-contract and the 402 body for schemas and terms). However, it never explicitly states when to prefer this tool over the sibling treasury tools, leaving selection to inference.

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

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

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) set the safety baseline, and the description adds substantive context beyond them: per-call cost (0.10 USDC on Base), a 10-call signed-wallet free tier over 30 days, that payment access records are durable, that no execution authority/delivery occurs, and that existing credentials, mandates and single-use grants remain required. This is rich disclosure and consistent with the annotations.

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

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

The text is long and heavily repetitive, restating the same non-authority boundary three times ('not a ... authority grant', 'creates no execution authority', 'grants no authority') and repeating the caller-supplied-data caveat. Pricing is front-loaded, but much of the body is legal boilerplate that does not earn its place.

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

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

For a non-read-only (readOnlyHint=false) tool with 6 undocumented parameters and no output schema, the description should cover both parameter meaning and return behavior. It documents authority/pricing boundaries well but is silent on what the six inputs are or what the call returns, so an agent still lacks key details 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?

Schema description coverage is 0% across 6 required parameters, so the description carries the full burden, yet it explains none of them. It alludes obliquely to items ('caller-supplied USD estimates') and currency ('USD'), but says nothing about agent_id, payment_reference, allowance_reference, or the mode const, leaving the agent to infer required input meaning from raw schema.

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

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

The description states a concrete verb+resource: 'Itemize and total caller-supplied USD estimates.' It also negatively differentiates from siblings by declaring this is 'not a provider quote, checkout session, payment request or authority grant' and gives the endpoint (POST /api/unified-agent-checkout). It stops short of naming a specific sibling tool as the alternative, so it lands 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?

There is partial guidance: the pricing/free-tier line and 'Read the backend 402 body for x402 terms' tell the agent how access is gated, and the disclaimers implicitly say when this tool is NOT the right one (quote, checkout, mandate). However, it never explicitly states when to use this versus alternatives like x402-payment-gateway, agent-invoice-rail, or ap2-mandate-gateway, leaving routing to inference.

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

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

Annotations only flag destructive/openWorld/non-idempotent, but the description discloses pricing (0.10 USDC x402 exact on Base), the shared 10 free-call allowance, the required X-Wever-Wallet-Proof binding, the 25.00 USDC escrow cap, dispute freeze and refund behavior, and the fact that live acceptance is a manual operator step. That is behaviorally rich context well beyond the structured hints.

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

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

Front-loads the key eligibility rule, which is good, but the body is a dense run-on of payment rails, state machine, and policy caveats, much of which duplicates material the description itself says lives in /api/workorder-contract.

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

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

With no output schema and a complex paid rail, the description covers the payment path, escrow cap, state transitions, dispute/refund behavior, and security constraints, and points to the contract document for schemas and evidence bounds. Return-value expectations remain unstated, but the pointer mitigates most of that.

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

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

Schema description coverage is 0% and neither required parameter is explained. order_id is only implied by 'funded order', and idempotency_key is never mentioned at all, so the description does not compensate for the documentation gap on a mutation call.

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 (accept) plus resource (funded order) with the governing constraint (named worker wallet, before deadline). It is clearly distinguishable from sibling mutation tools like wever_workorder-fund, wever_workorder-deliver, and wever_workorder-release.

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

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

Gives an explicit precondition for use (order must be funded and within deadline, caller must be the named worker wallet) and redirects to /api/workorder-contract for schemas and bounds. It never names an alternative sibling to use instead when those conditions fail, so it stops short of full when-not guidance.

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

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

Goes far beyond the annotations: paid URL at 0.10 USDC per call on Base mainnet via x402 exact, 10 free signed-wallet calls per rolling 30 days, mandatory X-Wever-Wallet-Proof bound to the exact JSON args and path, 25 USDC order cap, escrow-lite rail with fees and principal kept separate, dispute/expiry refund rules, and explicit prohibitions (no private keys, no payee substitution, no granted authority). This is unusually rich 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?

Core purpose is front-loaded in the first sentence, and most of the dense clauses carry load-bearing payment, proof and refund rules. There is minor redundancy (the 25.00 USDC cap is stated twice) and the sentence stack is heavy, but the length is defensible for a payment-bearing tool.

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

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

Covers payment, proof, caps, lifecycle states, dispute/refund behavior and defers schema detail to /api/workorder-contract, which is appropriate. With no output schema it does not describe the response shape (e.g. returned order id), which is the main remaining gap.

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

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

With only 25% schema coverage, the description compensates by mapping the core inputs (worker wallet, title, description, acceptance criteria, USDC price, deadline) to their meaning and adding the 25 USDC cap on price. It leaves idempotency_key and usage undocumented, which matters given idempotentHint=false.

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 ('Creates immutable work terms for an order') and immediately enumerates the fields the hirer must supply. It is clearly distinguishable from the sibling lifecycle tools (workorder-accept, -fund, -deliver, -release, -dispute) because it is the creation step.

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

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

Usage is implied rather than stated: the description lists the normal state sequence (open, funded, accepted, delivered, released), which positions this as the entry point, and points to /api/workorder-contract for schemas. But it never explicitly says when to call this versus workorder-fund or workorder-accept, nor names a prerequisite order.

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

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

Goes well beyond the annotations: it discloses pricing (0.10 USDC per call on Base mainnet via x402 exact), the shared 10 free signed-wallet calls per rolling 30 days, the mandatory X-Wever-Wallet-Proof bound to the JSON args and path, the 25.00 USDC escrow cap, the order state machine, dispute/expiry refund behavior, and explicit prohibitions (no private keys, no payee substitution, no granted authority). This is unusually rich behavioral context for a mutating, destructive, non-idempotent 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?

Front-loads the authorization constraint and the non-acceptance caveat before payment and escrow mechanics. Sentences are long and dense, particularly the pricing/escrow block, but nearly every clause carries distinct operational information rather than 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?

With no output schema it still covers payment, auth proof binding, state transitions, refund paths and safety constraints, and it points to /api/workorder-contract for schemas and evidence bounds. The main gap is that it never indicates what a successful call returns or how delivery evidence can be confirmed afterward.

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 only 25%, so the schema is largely silent, yet the description only gestures at 'deliverable reference and proof hash' conceptually. It adds no format, uniqueness, or lifecycle meaning for order_id ('wo_' + 64 hex) or the required idempotency_key, despite the annotation declaring the tool non-idempotent.

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 actor, verb and resource: 'Only the named worker wallet may submit a deliverable reference and proof hash for an accepted order.' It explicitly disambiguates from sibling lifecycle tools by noting 'submission is not automatic acceptance or payment', separating it from workorder-accept and workorder-release.

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 clear preconditions: the caller must be the named worker wallet and the order must be in 'accepted' state, and it distinguishes this step from acceptance and payment. It does not explicitly name the alternative sibling tools (workorder-accept, workorder-release, workorder-dispute) an agent should use instead at the next 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?

With annotations covering the destructive/open-world/idempotency hints, the description adds substantial behavioral context: the freeze-and-refund semantics, the normal state machine, the 25.00 USDC order cap, the 0.10 USDC x402 access fee with shared free calls, the mandatory X-Wever-Wallet-Proof binding to exact JSON args and path, and safety constraints (no private keys, no payee substitution, adapter grants no authority).

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

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

The core action and its release-blocking effect are front-loaded in the first two sentences. The remaining content is dense and information-rich, though somewhat repetitive (repeated "under the existing" rail phrasing and authority disclaimers) for a single-operation tool.

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

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

No output schema exists, so the description carries return/behavior burden; it covers auth, payment, escrow caps, state transitions, and the dispute effect, and points to /api/workorder-contract for schemas and recovery. An agent has enough to call it correctly, though exact response shape is left to the external contract.

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 only 25%, so the description must compensate. It adds meaning to evidence_reference ("bounded evidence in the proof inbox") and alludes to evidence bounds and proof binding, but does not clarify order_id, proof_hash, or idempotency_key semantics, deferring schemas to /api/workorder-contract.

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+resource+effect: either authenticated party freezes the order, records bounded evidence, and this blocks further release. It clearly distinguishes dispute from the sibling release/deliver/accept flow. It stops short of naming a specific sibling alternative, 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?

It gives clear usage context: either authenticated party may invoke it, and only before release, with the expiry refund to the original hirer remaining available afterward. It notes arbitration UI is outside v1. No explicit alternatives or when-not exclusions are named, so 4.

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 annotations already declaring destructive, non-idempotent, open-world behavior, the description adds substantial context beyond them: escrow principal is separate from the API access fee, the order value cap is 25.00 USDC, disputed orders freeze release and retain an expiry refund path, expired funded orders refund only the hirer, no private keys or arbitrary payee/payer substitution are accepted, and live funded acceptance remains a manual operator step.

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

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

The core action is front-loaded and the dense detail is mostly non-redundant for a financial escrow mutation. The state list and dispute/expiry clauses lengthen the definition, but each sentence adds behavioral or routing 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?

For a complex financial mutation with no output schema and 0% schema description coverage, the definition covers the state transition, authorization requirements, refund/dispute behavior, and where to find further schemas. The main remaining gaps are explicit return-value description and parameter-level semantics.

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

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

Schema description coverage is 0% for four required parameters. The description indirectly touches funding_payment semantics (0.10 USDC, x402 exact, Base mainnet) and the caller-signed authorization concept, but it never explains order_id, idempotency_key, or payer_terms_signature, so it does not compensate for the schema's missing parameter documentation.

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

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

The first sentence states a specific verb and resource: the hirer funds the order via escrow-lite using caller-signed principal authorization. It also implies the state transition ('open order to funded'), which separates it from create/accept/deliver/release siblings, though it does not name an alternative 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?