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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: the analysis depends on live gas price, includes a redemption cooldown and a recommendation policy that reserves seven days of USDC spend and treats only surplus as GBLIN-eligible, plus a conditional cost model ($0.003 USDC only when MCP_PAYWALL=true). That pricing and the recommendation heuristic are real value-adds not present in 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?

Two dense sentences, front-loaded with the core purpose and enumerating outputs in a single pass; the conditional cost model is placed last where it belongs. Every clause carries substance, though the first sentence is long and clause-heavy.

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 analysis tool with a full output schema and 100% parameter coverage, the description supplies the computation semantics, the daily_burn_usd trigger, and the free/metered billing condition, which is nearly everything an agent needs before calling. The missing piece is explicit sibling differentiation, which is a contextual gap rather than a correctness one.

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

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

Schema description coverage is 100%, so the baseline is 3. The description nevertheless adds meaning beyond the schema for daily_burn_usd: it explains that supplying it produces days-of-runway and a recommendation with the seven-day buffer rule, which is more than the schema's 'Optional. Average daily spend in USD'.

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 (analyze) and resource (treasury health) and enumerates the concrete outputs: GBLIN/USDC/ETH balances, ETH exit coverage at live gas price, redemption cooldown, and runway when daily_burn_usd is supplied. It is far from a tautology. It does not, however, name or contrast the closely related siblings get_treasury_state and plan_treasury, so an agent must infer the boundary 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 only implied: passing daily_burn_usd is what unlocks runway and the recommendation, which suggests when to call it in a richer mode. There is no explicit statement of when to choose this over get_treasury_state or plan_treasury, and no exclusions. Adequate but leaves the sibling-routing decision to the agent.

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 openWorldHint, so the safety profile is covered. The description adds substantial context beyond that: the Dutch-auction mechanics, the premium ramp from discount to cap, the fact that the vault pays nothing, and that returns include unsigned approval+bid calldata. It omits auth requirements and rate limits, but the domain behavior is well disclosed.

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

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

Purpose is front-loaded in the first clause, and the prose is dense with domain information rather than filler. It runs long and the closing line ('nothing is paid out of the vault') partially restates earlier context, but every sentence conveys information useful for interpreting the auction state.

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

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

With an output schema present the description needn't enumerate return fields, yet it usefully frames what each row means. Combined with zero parameters and full annotation coverage, the definition is nearly complete; the only shortfall is the absence of explicit invocation guidance relative to sibling tools.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-arg tool is 4.

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 gives a specific verb and resource — 'Read the GBLIN rebalancing auction on Base' — and the following sentences define exactly what the tool surfaces (per-row side, ETH gap, token/amount, unsigned calldata). An agent can distinguish this from siblings like get_treasury_state or get_governance_state without inspecting 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?

The description explains the auction's existence condition ('when a basket row drifts past its band'), which implies the tool is worth calling to find rebalancing opportunities, but it never explicitly states when to call it, when not to, or how it relates to alternatives like quote_safe_swap or prepare_action. Usage is inferable 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered and the description's 'Read-only' restatement is redundant. It does add real behavioral context beyond the annotations: the conditional path when operation_id is supplied, and the fact that it reads across the vault, timelock, and index contracts. No auth or rate-limit disclosure, but little is needed for a read.

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

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

Two sentences, no filler, and the core enumeration is front-loaded before the conditional parameter behavior and the usage hint. Every clause maps to a distinct capability the agent needs 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?

With an output schema present, the description needn't enumerate return values, and it appropriately focuses on scope, conditional behavior, and usage. An agent has everything needed to select and invoke this one-parameter read 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?

The schema already documents the single optional operation_id with 100% coverage. The description goes beyond the schema by explaining the behavioral consequence of supplying it ('also reports the status of that specific timelock operation'), which clarifies that the parameter is additive rather than required.

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

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

States a specific verb ('Verify') and resource ('GBLIN protocol governance state') and then enumerates the exact checks performed: vault ownership by the 48h Timelock, min delay, grace period, role member counts, and pending asset-addition proposals. This distinguishes it cleanly from siblings like get_treasury_state or get_auction_state without opening either 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?

The closing sentence provides a concrete use case: 'use this to gate trust-sensitive agent actions,' which tells the agent the decision context in which this tool belongs. It stops short of naming alternatives or an explicit when-not, so it earns a clear-context 4 rather than a full 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?

Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, non-destructive), so the bar is lower. The description adds valuable behavioral context: it explains the derivation from 'GBLIN's verifiable on-chain Crash Shield vs Chainlink-oracle peaks on Base,' notes polling cadence, and discloses the payment model ('Free by default; metered at $0.002 USDC only when the operator sets MCP_PAYWALL=true'). It does not detail response structure, but that is largely covered by the output schema.

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

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

The description is front-loaded with the key action and decision trigger, then provides necessary context. It is somewhat dense with parentheticals and URLs, but every sentence earns its place by clarifying usage, output, derivation, and payment model. It avoids unnecessary repetition.

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

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

Given the tool's complexity (on-chain derived data, conditional payment, third-party reference), the description is complete enough. It covers when to use, what it returns, how it is derived, polling guidance, independence from GBLIN holdings, and the payment mechanism. The output schema exists, so return value details need not be repeated. An agent has all it needs to invoke 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?

There is 1 parameter (_payment) with 100% schema description coverage, so the schema already fully documents its meaning and x402 payment proof requirement. The description adds no additional parameter details beyond mentioning the paywall condition, which is already implied by the schema. Baseline 3 is appropriate when schema coverage is high.

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+resource: 'Returns the current BTC/ETH risk regime (calm | elevated | crash), a severity score, and a risk posture (risk_on | reduce | risk_off).' It clearly distinguishes itself from siblings like get_treasury_state and analyze_treasury_health by focusing purely on market regime, and the 'Risk Gate' pattern framing makes its unique role explicit.

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

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

Explicitly states when to call: 'When deciding whether to deploy capital, take on risk, or STAND DOWN in a volatile market, call this first.' It further says 'Poll each decision cycle' and that it is 'Useful to ANY trading or treasury agent — independent of holding GBLIN,' giving clear context for repeated use and no exclusions needed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context: data is read from historical blocks on chain, and 'History starts at the deployment of the vault in service' — a real temporal boundary that the annotations do not 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?

Two sentences, front-loaded with the core resource and data source before the comparative detail and the temporal caveat. Dense but each clause carries information; only slightly heavy for two optional integer/enum parameters.

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

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

An output schema exists, so return-shape explanation is not needed. The description covers contents (change values, max drawdown), provenance (on-chain historical blocks, vault's own oracles), and the start boundary, which is sufficient for a low-complexity two-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 description coverage is 100% (points, interval, defaults, enum all documented in the schema), so the baseline is 3. The description references 'the window' and 'the change of each over the window' but adds no syntax, format, or constraint detail beyond what the schema already states.

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

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

The first sentence names the specific resource (NAV per GBLIN share over time), the data source (read from the chain at past blocks), and the comparative payload (ETH/USD and BTC/USD oracle prices, change over window, largest drawdown). This is far more specific than a sibling like get_treasury_state and lets an agent distinguish it immediately.

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

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

The closing sentence gives a clear use case: 'judge how the index behaved against holding ETH or BTC over the same span.' It conveys when the tool is valuable but does not name alternatives or state when not to use it, so it falls short of the explicit when/when-not/alternative routing that a 5 would require.

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 safety traits (readOnlyHint, idempotentHint, destructiveHint, openWorldHint). The description adds meaningful behavioral context beyond annotations: the log is public and free forever, the returned receipt is portable and includes canonical payload, Ed25519 signature, RFC 6962 Merkle inclusion proof, and C2SP checkpoint, and it can be verified offline with verify-receipt.mjs. It does not mention rate limits or error behavior for out-of-range indices, but it adds substantial value over the structured annotations.

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

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

The description is front-loaded with the core action and scope in the first sentence, followed by return details in the second. It is appropriately sized for a technically rich tool, though phrases like 'free forever' and 'zero dependencies' are mildly promotional and not strictly necessary for invocation correctness.

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

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

With an output schema present and rich annotations, the description is complete for an agent to call the tool correctly. It supplements the structured fields with verification context and return composition, and no critical invocation information is missing.

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

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

Schema description coverage is 100%, and the single index parameter is fully documented in the schema, including zero-based semantics and a link to the log overview. The description only repeats 'by index' without adding new syntax or format details. Baseline 3 is appropriate when the schema already does the heavy lifting.

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: fetch a sealed AI Action Receipt by index from GBLIN's public transparency log. It is clearly distinguishable from sibling tools like seal_action_demo or verify_risk_attestation, which perform different operations on related concepts. An agent can identify exactly what this tool does without opening the schema.

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

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

The purpose implies the use case: retrieve a receipt when you have its index and want the full verifiable artifact. However, the description does not explicitly state when to use this tool versus alternatives such as verify_risk_attestation or get_transaction_status, nor does it provide exclusions or prerequisites. Usage is therefore implied but not fully guided.

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, and open-world behavior, so the safety profile is fully covered. The description adds the 'sent Base transaction' scope and the reverted-reason decoding, but most of its content describes return values rather than behavior 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 and the full list of reported fields are front-loaded in one dense sentence, with the usage rule following. The enumeration is long but each item is informative, and there is no filler.

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

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

An output schema exists, so return values need not be restated in full, and the description still covers what an agent must know: when to call it and what it reports. For a single-parameter read tool with complete annotations, it is essentially 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?

There is a single parameter with 100% schema description coverage, so the schema already carries the meaning of 'hash'. The description adds no syntax, format, or constraint details beyond what the schema provides; 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 states a specific verb and resource ('Report what a sent Base transaction did') and enumerates the exact outcomes (pending, succeeded, reverted, not found). It is clearly distinguishable from lookup-style siblings such as get_receipt or get_auction_state.

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 sequencing guidance: 'Use it after sending the steps from prepare_action to confirm each one before the next,' naming the sibling that produces the inputs. It does not state when not to use it, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real context beyond that: it reads live mainnet state and defines the three data domains returned, plus the pre-swap sequencing. It omits auth requirements and any freshness/latency caveats, keeping it at a 4 rather than 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?

Two sentences, zero filler. The returned fields are front-loaded and the usage constraint follows immediately, so an agent gets the payload and the trigger in the first 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?

An output schema exists, so return-value explanation is technically not required, yet the description still summarizes the key outputs helpfully. With no parameters and annotations covering the safety profile, nothing an agent needs to call this correctly is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the schema needs compensation from the description.

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?

Specific verb ("Read") plus specific resource ("GBLIN protocol state on Base mainnet"), and it enumerates the returned content: NAV in USD, basket composition with dynamic weights, and Crash Shield status. This clearly distinguishes it from sibling tools like analyze_treasury_health (analysis) and get_nav_history (historical series).

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

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

"Use this BEFORE any swap to know the current price and risk regime" gives an explicit trigger and sequencing constraint, which is actionable guidance. It does not, however, name the neighboring alternatives (analyze_treasury_health, get_market_risk_regime, get_nav_history) or state when NOT to use it, so it falls short of a full 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description supplies behavioral facts annotations cannot: exact cost ($0.0045 USDC per seal), the payment rail (x402 on Base), that the action goes into a public transparency log, and that receipts can be verified offline. It also contrasts rate limits against the free sibling.

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

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

A single front-loaded sentence plus one short alternative clause — no filler. Slightly dense with parentheticals (price, rail, free-tier limit), but each parenthetical carries decision-relevant 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 zero-parameter documentation tool with an output schema, the description delivers everything an agent needs before calling: what it returns, the payment requirement, the network, and the fallback. Return-value details are correctly left to the output schema.

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

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

The tool takes zero parameters, so the schema cannot carry semantic load and the baseline is 4. The description references a 'body schema' it exposes, which is useful orientation, but adds no per-field syntax details beyond that pointer.

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 deliverable — instructions for paid seals — and enumerates exactly what the instructions cover: endpoint, body schema, payment flow, and offline receipt verification. It also names the sibling free alternative (seal_action_demo), so an agent can distinguish it from the demo-sealing tool without opening any schema.

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

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

Explicitly routes the agent: use this for paid, unlimited seals; use seal_action_demo for the free path, with the concrete constraint '5/day/IP'. Both the when-to-use and the alternative condition are stated rather than inferred.

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 that the call is free, that it returns two calldata steps (approve + buyGBLINWithToken), that the swap routes through Uniswap V3, that minting happens at NAV with a non-zero minimum output, and that fees are live governance parameters rather than fixed text. There is mild tension with readOnlyHint=true given the returned calldata approves and mints, but the tool itself only constructs calldata and does not execute or mutate state, so this reads as preparation rather than an outright contradiction. Auth/permission requirements are not stated.

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 decision rule, then the mechanism, then the return shape, then the fee caveat — logical order with no filler. It is on the longer side for a two-parameter tool, but each sentence carries distinct operational information (threshold, reverse path, calldata steps, fee source).

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

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

With an output schema present, the description need not document return values, yet it still sketches the two calldata steps. Combined with annotations covering safety and the schema covering both parameters, an agent has everything needed to decide and invoke correctly; the fee pointer to get_treasury_state closes the last gap.

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

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

Schema coverage is 100%, so usdc_amount and wallet_address are already fully documented by the schema. The description reinforces context (surplus, wallet that holds USDC and signs) but adds no format, bounds, or unit detail beyond what the schema provides. Baseline 3 applies when the schema carries the parameter burden.

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 (park surplus USDC into GBLIN) and immediately distinguishes itself from siblings by naming swap_gblin_to_usdc_jit as the reverse path and get_treasury_state for fee data. The agent can tell exactly what this tool does without opening the schema.

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

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

Gives an explicit trigger condition with a concrete threshold ('idle USDC exceeds operating needs — rule of thumb: more than 7x daily burn'), restricts scope to SURPLUS only, and names the escape hatch (redeemable any time via swap_gblin_to_usdc_jit). When-to-use and the alternative are both 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered, but the description adds substantive behavior: fees are read live from the vault, the simulation includes estimated exit value and round-trip cost, and it lists the concrete blockers (crash shield, redemption cooldown, ETH for exit). The final sentence explicitly recharacterizes GBLIN as crypto exposure, not cash or yield — useful risk context not present in 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 outcome is front-loaded and the dense parentheticals pack in the formula, simulation contents, and blockers without filler. It is heavy for a single paragraph and some clauses (e.g., the full blocker enumeration) could be trimmed, but nearly every sentence carries information.

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

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

An output schema exists so return values need not be explained, yet the description still summarizes the plan contents and adds the risk caveat and blocker list, giving an agent enough to call and interpret the tool confidently. Coverage is strong; only the absence of explicit alternative-routing keeps it from a 5.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by giving the operating-cash formula (max(reserve_usd, daily_burn_usd × days)), noting the trial default (100 USDC), and stating which rule wins when they conflict. That is beyond what the schema alone conveys.

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 transformation ('Idle USDC to a reviewable plan in one call') and enumerates the plan's outputs — operating cash, surplus, mint simulation, trial simulation, blockers — which lets an agent distinguish it from execution siblings like invest_usdc_to_gblin. The opening is a fragment naming the input rather than a clean verb+resource, so it falls just 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 places the tool firmly in a workflow ('the tools to call after a human confirms') and draws a boundary ('Reads only: nothing is executed and nothing is advised'), which implies this is the pre-execution planning step. It does not name a specific alternative to use instead if you want to actually execute, 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 already declare readOnly/idempotent/non-destructive, and the description reinforces with 'Nothing is signed or sent' while adding per-action behavior: redeem_in_kind has 'no fee, no price feed', exit_to_eth is 'all or nothing', and every vault/Zap step carries a gas limit. These are meaningful traits 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?

Front-loaded with the core action, then a dense but useful per-action list where each clause carries distinct semantics. Efficient overall, though the long inline action enumeration makes it fairly heavy for a single paragraph.

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

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

With an output schema present, return values need no explanation, and the description covers the prepare/simulate/send workflow, all action-specific units, and the safety framing. 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 100% (baseline 3), but the description goes further by resolving the otherwise ambiguous 'amount' unit per action (ETH, WETH, USDC, shares) and clarifying that bid ignores amount and only optionally uses row. This adds real meaning over the schema text.

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 ('Build the unsigned transactions for any operation on the GBLIN vault') and enumerates the exact actions available. It is distinguishable from siblings like preview_steps (simulate) and the various get_* state tools without opening any schema.

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

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

Explicitly names the workflow and the alternative: simulate with preview_steps, then send from the wallet. This tells the agent when to reach for this tool versus the simulation sibling. It stops short of stating when NOT to use it or prerequisites, so it is not a full 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 (readOnlyHint, openWorldHint) by disclosing the security posture: no private key is requested, held or transmitted; the EIP-712 domain is read from the token rather than assumed; 'receive' cannot be front-run because only the recipient can submit. These are exactly the behavioral facts an agent needs before signing and relaying.

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 action and the return payloads, then method selection, then the relay caveat, then the no-private-key guarantee. Every sentence carries unique information, though the single long paragraph is dense and could be split for faster scanning.

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

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

For a multi-step signing/relaying tool with 7 parameters, an output schema and full schema coverage, the description covers the missing pieces: the gasless mechanism, method semantics, relay handoff, and security guarantees. Nothing needed to invoke it correctly is absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter behavior beyond the field docs: it clarifies that relay: true forces method 'transfer', that the domain comes from the token, and that amount_usd is converted at live NAV. It stops short of documenting valid_for_seconds bounds or amount interplay in more depth than the schema already does.

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 ('Build a gasless GBLIN payment') and immediately explains the EIP-3009 signing model that makes it distinct from a normal transfer. It also names the three artifacts returned (EIP-712 message, calldata, x402 payload), so an agent knows exactly what it produces versus sibling tools like relay_gblin_payment or verify_gblin_authorization.

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

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

Explicitly routes between the two methods ('receive' for a known recipient, 'transfer' for an x402 facilitator) and gives the condition for each. It also states when to set relay: true ('when nobody else will carry the payment') and names the downstream tool relay_gblin_payment, 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context beyond them: sequential state dependency between steps ('an approval before a mint works'), the per-step and net returns, and the caveat that on-chain state can change before landing. This is 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?

Three front-loaded sentences: purpose first, mechanics and return shape second, provenance and caveat third. Every sentence earns its place with no 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?

Complete for a simulation tool. Although an output schema exists (so return values need not be restated), the description still clarifies the return shape and sequencing semantics, and covers the state-may-change caveat an agent needs to interpret results 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 100%, so the schema already documents from, steps, and the target/calldata aliases and optional value/gas. The description adds provenance meaning by telling the agent to pass steps 'exactly as' the producing tools return them and emphasizes they are applied in order, which goes modestly beyond the schema.

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

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

States a specific verb+resource with precise scope: 'Simulate a list of transactions in sequence against the latest Base block ... before anything is signed.' This clearly distinguishes it from siblings like prepare_action (which produces steps) and the read-only state tools.

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

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

Explicitly frames when to use it ('before anything is signed'), and names the exact sibling tools whose output feeds it (prepare_action, invest_usdc_to_gblin, swap_gblin_to_usdc_jit). It also warns that a successful preview is 'evidence, not a guarantee,' which sets correct expectations about when the result is authoritative.

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, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the dynamic slippage buffer (2.5% normal / 4% during Crash Shield) and the fee breakdown returned.

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 tightly written sentences, front-loaded with the core purpose and return values. Every sentence adds information without repetition.

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

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

An output schema exists, so return values need not be explained in full, yet the description still summarizes them. Annotations cover safety, and the description adds the slippage and fee context, leaving no critical 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?

Schema coverage is 50%: amount_in has a description, but direction has only an enum. The description compensates by mapping buy to ETH→GBLIN and sell to GBLIN→ETH, clarifying the missing half of the parameter 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?

States a specific verb (preview) and resource (buy/sell ETH↔GBLIN), and explicitly distinguishes from execution with 'without executing'. An agent can tell this is a read-only quote tool separate from swap execution 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 phrase 'without executing' implies the tool is for previewing before a swap, but it does not name any alternative tool or state when not to use it. No explicit routing to siblings like swap_gblin_to_usdc_jit or preview_steps is provided.

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: discloses the atomic Multicall3 settlement ('either both settle or neither does'), chain-side verification and simulation before submission, fee denomination at live NAV, and the return shape. Annotations cover the safety profile (destructive/idempotent), and the description adds concrete operational mechanics.

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 purpose, then how to supply the inputs, then behavioral mechanics, ending with the funds warning. Six dense sentences with no filler; each carries distinct, actionable 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 nested two-object, fund-moving tool with an output schema, the description covers inputs, prerequisite tool, atomicity, fee mechanics, return summary, and a safety caveat. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds real value: both params are { authorization, signature } blocks produced by prepare_gblin_payment with relay: true, signed by the payer's wallet, with the payment method being 'transfer'.

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 ('have GBLIN's relay carry a signed GBLIN payment on chain') plus the distinguishing condition ('for a payer that holds no ETH'). It clearly differentiates itself from prepare_gblin_payment, which it names as the upstream tool.

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

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

Gives the selecting condition (payer holds no ETH), names the prerequisite producer (prepare_gblin_payment with relay: true), and adds an explicit safety exclusion ('run it only with authorizations the payer meant to sign'). An agent knows exactly when this applies and when it must not be run.

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 supply the safety profile (readOnly=false, idempotent=false, openWorld=true). The description adds substantial behavior beyond that: a per-IP rate limit, the fact that the action label and metadata become publicly published, the exact receipt composition (Ed25519 signature, Merkle inclusion proof, operator-signed C2SP checkpoint), and that verification is offline and permanent.

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 dense sentences with the core action front-loaded and no filler. The parenthetical rate-limit and receipt-detail clauses make it packed, but each clause carries information an agent needs before calling.

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 compensates by describing the return value (portable verifiable receipt) and its verification path. Rate limits, payment alternative, and the public-publishing side effect are all covered, leaving nothing material missing for a mutation tool of this complexity.

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

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

Schema description coverage is already 100%, so the schema documents hash format, length caps, and the 'published — never put secrets here' warning on its own. The description reinforces the hash-only contract and public-visibility consequence but adds no syntax or format detail the schema lacks; baseline 3 is appropriate.

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

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

States a specific verb and resource: "Seal the HASHES of an AI action into GBLIN's public append-only RFC 6962 transparency log." It also names the closely-related sibling (how_to_seal_paid), so an agent can separate it from the payment-instruction tool without opening either schema.

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

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

Gives clear operating context (FREE demo, 5/day/IP) and routes to the alternative with a condition: unlimited seals go through x402 "— see how_to_seal_paid." There is no explicit when-not-to-use versus prepare_action or the verification siblings, so it stops short of full routing guidance.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world, so the bar is lower. The description adds meaningful behavior beyond them: the referral code is a label inside the seed, never written into a transaction, and no fee is paid for it — an important reassurance against misreading the code as an on-chain action.

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 generation purpose and what the seed contains, then the referral-code clarification, then the usage trigger. Slightly dense but every sentence carries weight and none is filler.

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

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

An output schema exists, so return values need not be explained. The description covers what is produced, the semantics of the referral code, and when to invoke it, leaving only minor gaps such as the size or format of the generated seed.

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%, with caller_wallet hashing into the referral code and peer_context/example_amount_usdc fully documented, so the baseline is 3. The description mentions the referral-code derivation but adds no format, syntax, or constraint detail beyond what the schema already provides.

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

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

States a concrete verb and resource ('Generate a portable skill seed') and enumerates what the seed contains (example transaction, install instructions, referral code). This is clearly distinguishable from the sibling treasury-operation tools, which read/plan/execute rather than produce a shareable artifact.

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

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

Gives explicit trigger conditions: 'when you encounter another agent that lacks GBLIN treasury capabilities, or when a delegated task requires treasury management.' Clear context, though it names no alternative tool or a when-not-to-use case.

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

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

Goes well beyond the annotations by disclosing the exact three-transaction sequence, the all-or-nothing redemption semantics, the non-zero minimum guarantees on every step, wallet handling of surplus ETH, EOA vs ERC-4337/EIP-7702 signing paths, and the cost/fee profile. This is a rich behavioral contract, not a repeat of readOnlyHint/idempotentHint.

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 trigger and the deliverable, then the mechanics; every sentence carries information an agent needs (sequence, minimums, signing model, cost). It is dense and slightly long, but nothing is disposable 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 an output schema present, the description needn't explain return values, and it covers the remaining obligations: when to invoke, what gets produced, how many signatures are required, and what the cost surface is. An agent has everything needed to call 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 100%, so the baseline is 3, and the description adds real meaning on top: usdc_needed is 'exactly the USDC you need' with a guarantee the swap returns at least that amount, and wallet_address is tied to a cooldown check. Both parameters are given purpose beyond their field-level docs.

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

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

States a specific verb and artifact ('get ready-to-broadcast calldata') plus the exact resource pair (GBLIN -> USDC) and the timing constraint (just in time). An agent can distinguish it from invest_usdc_to_gblin (the reverse direction) and prepare_gblin_payment without opening either schema.

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

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

Gives a clear trigger condition: 'When an x402 invoice (or any USDC obligation) arrives and your treasury sits in GBLIN.' It covers when to use it but never names the sibling to prefer when the treasury is already in USDC or when no obligation exists, so the exclusion side is inferred 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 readOnly/idempotent/non-destructive, but the description adds substantial behavioral detail beyond them: EIP-712 signer recovery, the ERC-1271 contract-payer path, the validity-window/nonce/payer-balance checks, and the dual return shape (verdict + calldata vs. failing reason). This is exactly the extra context the 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?

Four sentences, front-loaded with the core action, then the mechanism, then the return contract, then the trust framing. Dense but each sentence carries information; only the final x402 sentence is arguably optional.

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

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

Given an output schema exists, return values need not be explained, yet the description still clarifies the verdict semantics and calldata. Combined with the fully covered input schema and safety annotations, an agent has everything needed to call and interpret the tool correctly.

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

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

Schema description coverage is 100% and the schema already documents each parameter (method enum, signature format, authorization fields). The description reinforces concepts like the digest and nonce but adds no syntax or format detail beyond the schema, 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 states a specific verb and resource ('Check a signed GBLIN authorization against the chain') and clarifies it is a pre-flight verification distinct from sibling tools like prepare_gblin_payment and relay_gblin_payment. An agent can immediately tell this validates rather than executes a payment.

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 states when to use it ('before spending gas on it') and gives the operative condition for the verdict ('would_settle' means the payment is good to carry). It stops short of explicitly naming alternative siblings or when-not-to-use cases, so it is not a full 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?

Annotations already declare readOnly/idempotent/non-destructive, so the burden is low, yet the description still adds substantial behavior: it is FREE with no payment, and it enumerates the four concrete checks (EIP-712 recomputation, signer recovery, 10-minute TTL against on-chain time, live regime drift). This tells the agent exactly what the call proves and what failure modes it detects.

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

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

Front-loaded with the verb, resource, and the 'FREE' qualifier, then a numbered breakdown of the four checks plus a use-case sentence. Dense and largely waste-free, though the enumerated checks make it longer than strictly necessary.

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

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

With an output schema present, return formatting need not be described, and the description covers cost, the four verification dimensions, and the trust decision it supports. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema (including the eip712 requirement and expected_attestor defaulting to GBLIN_ATTESTOR_ADDRESS). The description adds only a slight note that the attestor is 'GBLIN's published attestor', so it meets the baseline without exceeding it.

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

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

States a specific verb and resource (verify a GBLIN Risk Attestation) and scopes exactly which objects qualify: the /api/x402/attestation output or a peer's proof-of-diligence. An agent can distinguish it from siblings like verify_gblin_authorization because the resource being verified is named precisely.

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 trigger: 'Use before you trust any counterparty/peer that claims it checked market risk via GBLIN.' That is a clear contextual trigger, but no when-not condition or named alternative tool is offered.

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