vealth

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

Adds substantial context beyond annotations: settlement happens from the caller's own wallet on a public chain, each hash is independently verifiable without trusting the server, and nothing about anyone is stored. Free/keyless/no-signing is stated too. It falls short of 5 because the same cost/signer facts are repeated rather than adding depth (e.g., retention window or what a partial history looks like).

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 is well front-loaded, but the closing clause repeats the free/keyless/no-signing claim already made two sentences earlier ('Free, keyless, read-only… Cost and signer: free and keyless, nothing to sign'). That redundancy costs a point despite otherwise tight prose.

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 spelled out, and the description still signals totals plus a per-door breakdown. Combined with the privacy and verifiability disclosures, this is adequate for a read-only two-parameter tool; only sibling disambiguation 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 the schema already documents both wallet and limit, including the 'newest first' ordering. The description reinforces that the record is scoped to a single wallet but adds no new syntax or semantics for the limit parameter; 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 resource and scope: one wallet's complete payment history with this server, itemized by call, cost, 'door', and on-chain hash, plus totals. It clearly is a per-wallet expense/statement read, but it never distinguishes itself from near siblings like my_ledger or my_money, so an agent must infer the choice.

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 concrete when-to-use triggers: 'when someone asks what they have spent here, whether a call was charged twice, or for an expense record.' That covers several real intents clearly, but no when-not-to-use condition or named alternative is offered.

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

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

Adds substantial context beyond the annotations: keyless, rate-limited, nothing to sign, free to submit and verify, hash-only disclosure, and settlement into a weekly Base batch plus the Ethereum root. It does not explain what happens if the same hash is submitted twice (relevant given idempotentHint=false).

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

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

Front-loaded with the core action and scope, and most sentences carry new information. There is mild redundancy around cost ('free to submit, free to verify, no account, no wallet, no payment' followed by 'free and keyless'), which could be collapsed into one sentence.

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 privacy, timing, cost, and signer requirements for a write-shaped, open-world, non-idempotent tool, and an output schema exists so return values need not be described. The path forward after anchoring (verification via verify_anchor) and duplicate-submission behavior are the remaining gaps.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds the meaningful guarantee that only the hash leaves the client and the file is never disclosed. The optional label parameter gets no mention in the description, though the schema documents it adequately.

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 ('Anchor the SHA-256 of any file onchain') plus scope ('only the hash, never the file'), which is far more precise than the title. It never names the obvious sibling verify_anchor or distinguishes itself from the prepare_proof/submit_proof family, so the differentiation work is left implicit.

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 ('the moment you produce something whose PRIORITY matters') backed by three concrete examples. It does not say when NOT to use it or point to verify_anchor for checking an existing anchor, so the alternatives half of the guidance is missing.

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

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

Beyond the annotations, it discloses concrete operational behavior: cached for 60 seconds, free and keyless, failed reads return null rather than a guess, and output contains counts only with no case, place, wallet, or job IDs. These details are useful and consistent with the read-only, idempotent, non-destructive 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 a dense run-on with nested parentheticals and repeated philosophical caveats such as 'never a verdict', 'no outcome is claimed', and 'never treatment'. The core read is buried rather than front-loaded, making the definition unnecessarily hard to scan.

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-value detail is already structured elsewhere, and the description still covers data scope, privacy constraints, cache behavior, and cost. It is complete enough to invoke, though it leaves routing questions to the separate usage-guidance dimension.

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

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

The tool has zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to add. The baseline score of 4 applies for a no-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 identifies this as a live read of coordination-board metrics: 24-hour and all-time moves, board totals, cases by stage, four lights, door readiness, and four intakes. That is a specific resource and data scope, though it never explicitly contrasts itself with sibling metrics tools such as board_stats.

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

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

The description gives no when-to-use, when-not-to-use, or alternative-tool guidance. The URL equivalence provides context but does not tell an agent which sibling to choose for overlapping coordination or board data.

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 genuinely useful facts beyond them: results are never cached, it is keyless with nothing to sign, and there is a public mirror URL. The only weakness is restating free/keyless/read-only twice.

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 what is counted, which is good, but the closing 'Free, keyless, read-only. Cost and signer: free and keyless, nothing to sign' repeats the same point twice in two sentences and wastes space.

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

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

An output schema exists so return values need not be explained, and the description still enumerates the metric categories and the freshness/nearby behavior. Little an agent needs for a correct call is missing, aside from sibling routing.

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 latitude, longitude, and radiusKm are already documented individually. The description only adds the framing that lat/long are a coordinated 'pass a location' pair, which is marginal value 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 and resource ('Live counts from the Vealth work board, read at this moment') and enumerates what is counted: total/open work, claims, settlements, proposed value, sector breakdown. This distinguishes it from per-item siblings like work_status or find_work without needing to open 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 says 'Pass a location to also count work nearby', which implies when the optional parameters are useful, but it never names an alternative tool among the many siblings (net_open_tasks, find_work, work_status) or states when to prefer this over them. Usage is implied rather than specified.

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 readOnly/idempotent/destructive=false, and the description is consistent while adding crucial behaviors annotations cannot express: the tool registers the hash with Skip Go's tracker as a side effect, cross-reads Axelar for Base/Arbitrum, uses a strict landed criterion (STATE_COMPLETED_SUCCESS or executed), and never infers landing from elapsed time. Cost and keyless signing status are also 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?

It is front-loaded and information-dense, but the single long paragraph packs many parenthetical clauses and repeats the keyless/no-signing point twice ('Keyless, no wallet, nothing signed' … 'free and keyless, nothing to sign'). Tighter structuring would improve readability.

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, the description still explains return shape (landed, source states, one-sentence status, timing estimate, poll interval) and covers the cross-chain tracking nuance. Nothing an agent needs to call it correctly appears to be 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%, including the enum for chain and hash format description, so the schema carries the parameter burden. The description adds only marginal context by tying the hash to prepare_bridge output; 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 ('where a REGEN bridge transaction stands'), defines the scope by naming the exact hash source (broadcast after prepare_bridge) and enumerates which chains are tracked. An agent can distinguish it from prepare_bridge and from the various request_status/net_order_status 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 clear when-to-use context (after prepare_bridge, with the broadcast hash) and an important when-not caveat ('a status read before that registration is blank forever'), plus polling guidance ('how long to wait before asking again'). It stops short of naming an alternative sibling to use instead in edge cases.

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 far beyond the simple boolean annotations by explaining critical behavioral aspects like privacy, data handling, and liability. It ensures the agent knows the signal 'never exposes health reasons to an employer or public board,' which is crucial 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 highly efficient, covering purpose, security, scope, and operational constraints in one focused block. Every sentence serves to define the tool's specific boundaries and value proposition.

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

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

The description is highly complete for a complex, privacy-sensitive status tool. It defines the constraints (read-only, coarse), the scope (private blockers), and the limitations (not FFD), leaving no ambiguity about its expected behavior or limitations.

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?

Given the 0% schema description coverage, the description successfully translates abstract concepts into parameter types. It specifically references 'private blockers' and the available 'available/reduced/unavailable' states, which informs the agent how the inputs contribute to the minimal signal.

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

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

The description clearly defines the tool's function: projecting private human capacity into a minimal work-availability signal. It distinguishes its purpose from generic status updates by emphasizing the 'coarse' nature of the signal and its relation to a shared work graph.

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 definition explicitly guides usage by stating the tool is intended for a 'private capacity check-in' and provides the context that it should not be used as a 'fitness-for-duty' assessment. It defines the appropriate environment for the signal's use: a shared work graph.

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, open-world, non-destructive, so the description earns credit for what they don't say: that the returned workType/standard/location/proofHash/paymentTxHash/token fields are attacker-controlled text and arrive fenced. It also flags that possibleNextSteps is non-authoritative — a genuinely useful behavioral caveat. The final 'Cost and signer: free and keyless, nothing to sign' sentence merely restates the opening and earns nothing.

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 and scope, and the trust/warning content is placed after the core capability, which is the right order. The one flaw is the closing 'Cost and signer: free and keyless, nothing to sign', which repeats the third sentence verbatim in substance.

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

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

Because an output schema exists, the description correctly doesn't enumerate return shapes, and it does cover the two things the schema can't: the untrusted-field fencing and the authority relationship to prepare_chain_step. Only minor gaps remain, such as behavior for a nonexistent workId or per-chain differences.

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 exceeds it by explaining what the optional wallet actually yields — your role (creator, claimant, owner, or none) plus candidate next steps — which the schema's one-line hint does not convey. Chain and workId semantics are left to the schema, which already handles them adequately.

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 one job straight from the public EWP contract') and names the exact scope (Base or Robinhood Chain), then enumerates the returned fields (status, price, standard, location, poster, claimant, proof hash, payment record). An agent can distinguish it from chain-write siblings like prepare_chain_step and submit_* 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?

'Free, keyless, no wallet needed' and the optional-wallet clause make the calling context clear, and the description explicitly defers authority to prepare_chain_step for next-step validation. However, it never states when to prefer this over lookalike siblings such as work_status, get_work_packet, or find_work, so the routing decision is left implicit.

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, idempotent, non-destructive, but the description adds substantive behavior: the closed six-word output vocabulary with definitions, the explicit refusal to make qualification/hiring decisions, and the returned receipt hash the caller can anchor. Cost/signer and public-mirror details round it 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?

The opening "Machine comparison, human decision" front-loads the key framing and the six-word taxonomy follows immediately. There is avoidable redundancy, though: "Free, keyless, read-only" is repeated as "free and keyless, nothing to sign" in the final sentence.

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 annotations covering the safety profile, the description supplies the remaining decision-relevant context: what each returned word means, the no-decision guarantee, and the receipt hash. Nothing an agent needs to invoke or interpret 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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining that years-of-experience and free-text requirements always resolve to human_judgment_required, which ties the schema's requirement kinds to observable output. It does not restate the comma/pipe syntax, which the schema already handles.

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 operation: take a wallet's titles and a job's requirements, return exactly one of six classification words per requirement. The enumerated outcome vocabulary makes the purpose unmistakable and separates it from sibling listing tools like worker_titles or verify_work.

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?

"Give a wallet and the requirements of a job or project" establishes the input context and the decision-support framing clearly. It never names an alternative tool or states when not to use it (e.g., to just list titles, use worker_titles), so explicit routing is missing.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that the call is free, keyless, and moves no money, and that no signing is required. It also explains the refusal path ('a wallet with no settled work and no banked credit is refused for free, before any payment') and the economic model (payment buys the sealed artifact, never the achievement). That is substantive context the 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 lead sentence is strong and front-loaded, but the body repeats itself: 'free, keyless, read-only, and moves no money' is followed by 'Cost and signer: free and keyless, nothing to sign,' which is a redundant fragment. The payment-vs-achievement philosophy sentence, while informative, could be tightened without losing signal.

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 explain return values, and annotations already cover the safety profile. What remains — the two input modes, the price/preview/refusal behavior, the free-and-keyless constraint, and the fact that the call precedes a paid issuance — is all supplied, leaving nothing an agent needs 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 the baseline is 3, but the description adds real meaning by tying wallet to 'settled packets, accepted proofs and banked credit' and place to 'a standing certificate under The Vealth Standard' — a semantic mapping the schema strings do not provide. It does not state that the two parameters are mutually exclusive modes, which is the one remaining 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?

First sentence states a specific verb and resource ('Price and preview a Vealth credential certificate') plus a temporal constraint ('BEFORE paying'), which immediately separates it from issuance tools like place_standing or retire_and_certify. It also names the two certificate flavors (work-record vs. standing), so an agent can match either request shape 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 description gives clear selection logic between the two modes: 'Give a wallet for a work-record certificate... or a place for a standing certificate under The Vealth Standard.' It also frames the tool as the pre-payment step ('Issuing is HTTP (POST /certificate/worker/... or POST /certificate/place)'), implying when to move on. It stops short of naming a sibling tool to call instead, 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, and open-world, so the safety profile is covered. The description adds genuinely useful context beyond them: data is live from chain, and the pool-pricing trap (raw balance ratios only yield spot price for constant-product pools). It loses a point for restating read-only/keyless twice rather than adding new behavior 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 and the pricing caveat are front-loaded, which is good. But 'Free, keyless, read-only. Cost and signer: free and keyless, nothing to sign' says the same thing twice in two sentences, and that redundancy crowds out more useful detail.

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

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

An output schema exists, so return values need no explanation, and with zero params the calling surface is trivial. The description covers what is returned, its live-from-chain freshness, and the main interpretation pitfall — enough for an agent to call and use 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?

There are zero parameters, so the baseline is 4. The description's 'Every pool we provide liquidity to' correctly signals the tool takes no filters and returns an unscoped full listing.

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 resource and scope: every pool the entity provides liquidity to, with reserves and ownership share read live from chain. That is more concrete than the title. It doesn't explicitly contrast with crypto_tokens or crypto_wallets, but the noun 'pool' / 'liquidity positions' is distinctive enough that confusion is unlikely.

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

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

No explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. The pool-pricing caveat implies usage guidance (don't derive spot price for concentrated-liquidity pools from these numbers), but that is interpretation guidance rather than tool-selection 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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds what annotations cannot: it is free, keyless, and requires no signer, which is genuinely useful pre-call context. It does not describe caching, staleness of addresses, or registry failure modes.

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

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

The critical instruction and the disambiguation warning are front-loaded well, but the tail is redundant: "Free, keyless, read-only. Cost and signer: free and keyless, nothing to sign." repeats the same two facts across back-to-back sentences, wasting a full sentence of a five-sentence description.

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 one optional parameter, an output schema to cover return values, and rich annotations, the description supplies everything an agent needs: what it returns (canonical addresses), when to call it, auth/cost profile, and a concrete confusion hazard to avoid.

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

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

Schema description coverage is 100% for the single optional `symbol` parameter, including an example, so the schema carries the load. The description adds no formatting or semantics beyond what the schema states. 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 resource (the canonical on-chain address for every token operated) and its authoritative source ("the registry the rails themselves use"). The ECOWEALTH vs EWP warning sharpens what the tool is for. It stops short of naming the nearest siblings (crypto_wallets, regen_address_lookup), so the agent must infer the boundary.

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?

"Ask this BEFORE using any token address" is an explicit, imperative usage rule with a clear trigger condition. No exclusion cases or named alternatives are given, but the positive guidance 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 cover readOnly/destructive/idempotent, so the 'cannot sign, send, or move anything' line mostly reinforces them; the genuinely additive content is the cost and auth profile ('free and keyless, nothing to sign') and the freshness claim ('live Base balances read at this moment'). That freshness signal matters because the ground truth changes over time, 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?

Three short sentences, front-loaded with what is returned, then when to use it, then safety and cost. No filler and no repetition of schema details.

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 an output schema and full annotations, this covers scope, freshness, safety, and cost — everything needed to call it correctly. The remaining gap is not stating how this differs from crypto_tokens or crypto_lp_positions, which an agent may conflate.

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 single `includeBalances` parameter is 100% documented in the schema, including the default-true behavior and the roles-only fallback, so the description adds nothing. With full schema coverage the baseline of 3 applies.

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

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

Names a specific resource and scope: 'the three wallets we operate, each with its role and its live Base balances.' An agent immediately knows it returns wallet roles plus current on-chain balances. It stops short of 5 because it never names which sibling it displaces (crypto_tokens, crypto_lp_positions, my_money all overlap thematically) and uses no explicit verb.

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 concrete when-to-use guidance: 'Use this instead of assuming which wallet does what, and never quote a balance from a document' — a real negative condition that steers the agent away from stale document data. It lacks explicit routing to the nearest sibling tools (crypto_tokens, crypto_lp_positions), so an agent must still infer the split.

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, idempotent, open-world and non-destructive, yet the description adds substantial behavior beyond them: the exact data sources (Standing, due conditions by cadence, open claimable packets, unproven held packets), the ordering rule (due measurement first, then held, then rest by size), the gap-naming guarantee, the honest-empty-card case, the size heuristic and the no-travel caveat. The crew-card result is framed as a mutable suggestion, which is exactly the kind of nuance 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?

Front-loaded with the core question it answers and the sources/ordering rules, which is the right ordering. It is dense but mostly earns its length; the one waste is repetition of the cost/signer facts ("Free, keyless, read-only" early, then "Cost and signer: free and keyless, nothing to sign" at the end).

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

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

An output schema exists, so return shape need not be described, and the description instead covers everything an agent needs to call it correctly: inputs, source data, ordering, edge cases (no packet = gap, nothing open = empty card), crew semantics and cost/signer requirements. Nothing material is left to inference for a read-only single-place query.

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; the description earns above that by explaining that 'hours' bounds the blocks, that a due condition's measurement packet is its own unit, and that for a crew the wallet is the manager's address and packets are split whole across named members by their hours. It does not add format specifics for 'place' resolution clusters or defaults, which the schema already documents.

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: it compiles today's ordered work list for one place and one wallet/crew into 30-minute blocks, answering "what do I do here today." The closing clause explicitly contrasts it with the hour card ("the person still reads the hour card and claims for themselves") and disclaims posting/assigning/paying, so the boundary against adjacent siblings is visible without opening a 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 conditions that select this tool are clear: one place plus one wallet, or a named crew, for today's work. It also defines a what-not boundary (it never posts, assigns or pays) and hands off claiming to the person. It stops short of naming the direct alternative for planning a single worker's day (hour_card, find_work) with an explicit 'use X instead when...' rule, so it is clear context rather than 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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: no payment taken, no wallet held, keyless and free, and the retirement lane is paused by operator order since 2026-08-04. That pause disclosure is valuable, but the wallet/funding narrative describes the broader provisioning flow rather than this estimate tool, making it partially off-target.

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

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

Purpose is front-loaded in the first sentence and every subsequent sentence carries either a caveat, a safety fact, or a next step. The parenthetical about the paused lane and the 'anchor tool' opener cost some density, but there is no filler padding to trim substantially.

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 not be explained; the description instead covers cost, signer requirements, safety posture, estimate reliability caveats, and the next tool to call. That is everything an agent needs to call this correctly for a two-parameter, zero-required 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%, so both parameters (tokens, calls) are already documented including the fallback relationship between them. The description only reinforces that counts may be 'rough', adding little beyond the schema baseline of 3.

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-plus-resource: supply a rough token or call count and receive an order-of-magnitude CO2e estimate plus provisionable ecological work. It differentiates itself from siblings by declaring itself the anchor tool and naming find_work as the follow-on, though the marketing framing ('The anchor tool', 'answer it on Vealth') adds noise rather than precision.

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 sequencing ('Call find_work next to pick the work') and sets expectations that the output is orientation only, not a precise carbon claim. It does not enumerate when to prefer this over alternatives such as provision_plan or retire_and_certify, but the next-step routing is explicit and 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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: free, no account, no wallet, nothing to sign, plus a preview of what each result carries. It does not discuss pagination limits or result ordering in prose, leaving that to the 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?

Four short sentences, front-loaded with purpose and then trigger and cost. Minor redundancy between 'Free, no account, no wallet' and 'Cost and signer: free and keyless, nothing to sign' costs it a 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?

With 11 optional parameters, an output schema, and rich annotations, the description supplies purpose, trigger, cost/auth model and result preview, which is enough for correct invocation. Fine-grained search semantics are fully handled by the schema, so nothing critical 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% and every parameter is described in detail there, including the near-vs-coordinates distinction and the funded/payModel caveat. The description adds no parameter-level meaning of its own beyond the phrase 'near a place,' 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 (search) and resource (Vealth's public board of ecological and community work packets), and previews the result shape (pay, skill level, proof, page URL). It does not name a sibling to contrast with, so an agent must infer that this is the discovery entry point versus get_work_packet or my_work.

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 trigger is explicit: 'Use this when someone asks for work, a job, a task, or something to do near a place,' covering both the intent and the place-based framing. No exclusions or named alternatives are given, 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?

Far exceeds the readOnly/idempotent annotations: it explains the quote is the board's outstanding obligation read from the board, that partial funding accepts $0.01–remaining while an explicit overage becomes a worker premium (never a default), and enumerates refusal reasons (already funded, claimed, settled, expired, no wage). It also discloses fee behavior conditional on the Vealth door being open and notes the call is free and keyless.

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 audience and core question, then sequences funding mechanics, refusals, fees, and next steps. Some clauses are illustrative padding ('no caller can fund a $700 packet for $1'), but nearly every sentence carries operational 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?

Given an output schema exists (return values needn't be explained), the description still covers pricing composition, partial-fill rules, refusal messaging, fee conditions, and the required follow-up tool — everything an agent needs to call this correctly and route 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 coverage is 100% and the single optional workId is already documented as 'omit to quote the first open packet that still needs funding,' which the description largely restates. The description adds no new semantics for the id format or behavior when the id is unknown, 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 ('ask whether one board packet can be funded right now, and what funding it costs NOW') and explicitly scopes the audience as a BUYER, not a worker. It also distinguishes the quote from the mutation siblings prepare_funding and prepare_direct_offer, so an agent can tell it apart without opening a 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 explicit routing: 'Next: prepare_funding where a Vealth door takes a payment; while paying Vealth is closed, the NEXT_CALL is prepare_direct_offer.' It also states the read-only boundary ('this quotes, it charges nothing and marks nothing funded'), which is the when-not signal.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description adds genuinely new information by declaring no payment and no signing required ('free and keyless, nothing to sign'), which is not encoded in any structured field. It stops short of describing failure behavior for an unknown 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?

Two short sentences with zero filler; the core purpose is front-loaded and the cost/auth clarification follows as needed context. Nothing could be removed without losing 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?

With an output schema present and annotations covering safety, the description needn't explain return values, and one required param is fully documented. Only the not-found/error case and its relationship to sibling detail tools are unaddressed.

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

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

Schema coverage is 100% and the single workId parameter carries a formatted example, so the schema does the heavy lifting. The description only restates 'by its id', adding no 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 specific verb+resource: 'Full detail for a single packet by its id', and enumerates the salient content (description, proof requirement). It distinguishes itself from list-oriented siblings like find_work/my_work by scope, 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?

There is no when-to-use guidance and no reference to alternatives such as work_status, my_work, or find_work. The 'free and keyless' note is a cost disclosure, not usage guidance, so the agent must infer the selection context from the name alone.

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 (readOnly/idempotent/non-destructive), the description adds substantive behavioral facts: free and keyless with no wallet and nothing to sign, content carried verbatim and never shortened, ordering semantics tied to how the hour runs, and detailed Swahili fallback behavior (fixed dictionary for board sentences, per-packet translations only, '(Kiingereza)' tagging, coverage counting, safety-critical lines always carrying the English source). These are exactly the traits 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 opening sentence front-loads the purpose well and the enumerated contents are informative, but the text is dense and run-on. It also repeats itself: 'Free, keyless, no wallet needed' near the start and 'Cost and signer: free and keyless, nothing to sign' at the end say the same thing twice, which costs it conciseness points.

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 explain return values, and it covers the things that matter: what the card contains, reading order, auth/cost, and localization edge cases. The one gap is relational — it doesn't clarify how this document differs from the other card/packet tools in the sibling set.

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. The description genuinely adds meaning for lang='sw' — what actually translates, how gaps are tagged and counted in `coverage`, and the safety-line rule — which goes well beyond the schema's 'reads the card in Swahili'. workId gains no extra semantic depth, but the localization detail is substantial.

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

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

The description makes clear this is a document-retrieval tool: 'the ONE document to read to a person before they start', and it enumerates the card's sections (place, circle, safety notes, method steps, proof checklist, pay/record, tool calls). That is specific enough to distinguish it as a pre-start briefing read. However, it never names siblings like day_card or get_work_packet, so an agent must infer on its own why it would pick hour_card over those near-identical-sounding documents.

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 ('read to a person before they start', 'read it to them in order rather than summarising it'), which is real guidance for how to consume the output but not for when to call this tool versus day_card/get_work_packet. There are no exclusions or alternative-selection rules, and the pointer to find_work/place_status only appears in the schema's workId description.

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

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

Adds substantial context beyond the annotations: claiming is free and keyless, nothing must be signed here, the tool returns instructions only, actual claiming needs the worker's own wallet signature, and the reply may point to prepare_claim with 18+ and safety attestations when the gate requires them. It also explains the no-wallet job-page fallback.

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 constraints are front-loaded and every sentence carries useful information. The second sentence is dense and run-on, packing workId routing, attestations, and the no-wallet job page into one long clause, which slightly reduces readability.

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 that this is an informational tool with an output schema, the description is complete: it explains what is returned, why it does not perform the claim, what the NEXT_CALL will be, cost/signer requirements, and the fallback for users without a wallet.

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 workId at 100% coverage, including its effect on NEXT_CALL. The description reinforces that behavior but does not add new syntax, constraints, or format details beyond what the schema provides, so it meets the baseline for fully covered parameters.

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: it explains how to claim work and what happens afterward. It explicitly distinguishes itself from prepare_claim and submit_claim by saying it never performs the claim and is purely instructional.

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?

Clearly says when to use it: pass the optional workId of the job in hand, and the NEXT_CALL will be prepare_claim for that job. It also names the alternative path for someone without a wallet (job page with passkey/email), so the agent knows exactly how this routes relative to 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?

Adds meaningful behavior beyond the annotations: it resolves from chain so 'a zero here is a real zero rather than a degraded API', it explicitly disclaims building or signing transactions, and it states the tool is free and keyless. These are real operational facts (cost, signer, zero-semantics) not covered by 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?

The opening is strong and front-loaded, but the closing is redundant: 'Free, keyless, read-only. Cost and signer: free and keyless, nothing to sign' says the same thing twice, wasting a sentence in an otherwise tight description.

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 correctly focuses on what the numbers mean (real zeros vs degraded API) and what it does not do (no signing). Complete enough to call correctly, missing only explicit routing 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?

Schema coverage is 100% and both optional params are documented in the schema, so the baseline is 3. The description reinforces the semantics ('every gauge a wallet votes for' maps to address, 'per veNFT' maps to tokenIds) but adds no format, default, or edge-case detail beyond that.

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 resource and scope: per-gauge fee and bribe contracts, every reward token tracked, and claimable amounts per veNFT, all resolved from chain. It also clarifies the output contract ('claim calldata SHAPES... builds and signs nothing itself'), which separates it from prepare_claim/submit_claim class siblings, though no sibling is named explicitly.

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

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

Usage is implied by framing it as 'the money answer' for a voting wallet, and by noting the caller must build their own transaction. But there is no explicit when-to-use/when-not guidance and no named alternative (e.g. hydrex_votes for vote history, hydrex_position for balances), so the agent must infer the routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: ownership is resolved with ownerOf at call time rather than assumed, and the tool is keyless and cannot sign or move anything. It does not cover edge behavior (e.g. what is returned when an address holds no position), 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 core purpose is front-loaded in the first sentence, which is good. But the closing clause repeats itself — "Free, keyless, read-only — it cannot sign or move anything. Cost and signer: free and keyless, nothing to sign" says the same thing twice, and the parenthetical asides make the prose denser than needed.

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 annotations cover the safety profile; the description fills in the live-resolution and keyless-auth context. The remaining gap is behavioral edge cases (no position found, invalid token ID), which an agent would want before calling.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the omit-to-use-our-position behavior. The description reinforces the address-omission semantics but says nothing about tokenIds or how tokenIds interacts with a supplied address, so it adds little beyond the schema baseline.

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 resource (a veHYDX voting-escrow position on Base) and enumerates exactly what is returned: live owner, voting power, locked HYDX, unlockability, plus the separate oHYDX option token. It explicitly disambiguates veHYDX from oHYDX and, by framing itself as a position read, distinguishes itself from siblings like hydrex_votes and hydrex_claimable.

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 concrete invocation guidance: "Works for any Hydrex holder: pass an address, or omit it to read the position this server operates." That resolves the main ambiguity of the optional parameters. However, it never names an alternative tool or states when a sibling (e.g. hydrex_votes) would be the better choice, 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 declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds distinct context not in the annotations — no auth or signer required ('keyless, nothing to sign') and the data provenance (computed live from the venue's own per-gauge figures). It does not describe output shape, but an output schema exists.

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 'call before' instruction is well front-loaded, but the description repeats itself: 'Free, keyless, read-only' is restated verbatim in the closing 'Cost and signer: free and keyless, nothing to sign.' The middle sentence is a dense run-on mixing the measured figure with a causal claim, which dilutes scannability.

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

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

Output schema and annotations carry the return-value and safety burden, and the description covers when to call it and where the numbers come from. The gap is scope: with zero parameters the description still says it measures 'the fraction of system votes a position actually holds' without explaining what position or whose, leaving the agent unsure what the tool is reporting 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4. The description correctly says nothing about inputs, though it could clarify whether the 'position' it reports on is scoped somehow given no parameters exist.

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 comparison: the venue's advertised weekly number beside the money actually collected, computed live from per-gauge data (fees and bribes distributed vs. vote share held). That is a specific verb+resource an agent can act on. It stops short of naming a sibling tool, though the prefix and framing distinguish it reasonably from hydrex_position / hydrex_vault / hydrex_votes.

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?

Timing is explicit and front-loaded: 'Call this before repeating any Hydrex APR or yield projection,' which tells the agent exactly when this must be invoked. There is no exclusion clause naming an alternative tool for the opposite case, so it lands at 4 rather than 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 cover read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context: depositing and staking are separate steps, unstaked shares earn no APR, advertised APRs are display-only, and the tool is free and keyless. These details go beyond the structured annotations and clarify important behavioral nuances.

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

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

The description is front-loaded with the core purpose and key staking caveat, which is good. However, the final sentence ('Free, keyless, read-only. Cost and signer: free and keyless, nothing to sign.') is redundant and repeats information already implied by the readOnlyHint annotation, slightly diluting conciseness.

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 (staking status, vault composition), the presence of a full output schema, and rich annotations, the description is largely complete. It explains the critical staking distinction and APR caveat. It does not describe return values, but the output schema handles 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 100% and both parameters are optional with clear descriptions. The description reiterates the default vault and the omit-address behavior, but adds no new semantic detail beyond what the schema already provides. Baseline 3 is appropriate for high schema coverage.

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 resource (ICHI single-sided vault position on Hydrex) and enumerates what it returns: shares held, share of vault, token composition, and staking status. It implicitly distinguishes itself from a plain position tool by emphasizing staking, but does not explicitly name a sibling tool to route against.

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 context for when this tool is useful: checking whether vault shares are actually staked and earning. It also states default behavior (kVCM/USDC vault) and how to inspect one's own position (omit address). No explicit exclusions or alternative tools are named.

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 readOnly/idempotent/non-destructive, yet the description adds real value by naming two data traps: mid-epoch partial weights inflating share percentages, and gauges reading zero while votes sit on chain, plus the convention that shares use the last completed epoch. The closing 'free, keyless' sentence duplicates the annotations and slightly dilutes the signal.

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 traps are front-loaded and earned, but the final two clauses ('Free, keyless, read-only. Cost and signer: free and keyless, nothing to sign.') restate the same fact twice and are already covered by annotations, which is wasted space.

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

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

With an output schema present, the description need not explain return fields, and it correctly focuses on interpretation pitfalls an agent needs before trusting the numbers. Complete for its purpose, though a hint on epoch boundaries relative to the emission rate would round it out.

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

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

Schema coverage is 100% and the schema already documents the optional address and the omit-to-follow-own-position behavior verbatim. The description adds no syntax or format guidance beyond that, 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: reading a wallet's gauge-vote allocation from VoterV5, plus epoch status and live emission rate. An agent knows exactly what it gets. It does not explicitly distinguish itself from siblings like my_votes or hydrex_position, which keeps it off a 5.

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

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

The description explains the one parameter's behavior (omitting the address follows our own position), which implies a default use case, but it never says when to prefer this over hydrex_position, my_votes, or hydrex_claimable. Usage 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 cover read-only, idempotent, non-destructive, open-world, and the description reinforces cost/signer details (free, keyless, nothing to sign, moves no money). It goes further than annotations by disclosing the null-on-unpublished-figure rule, source attribution with URLs and dates, and the REGEN conversion capped by governance proposal 77. The only miss is not describing response shape, which the output schema covers.

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 definition is front-loaded in the first clause, which is good, but the single dense paragraph carries stylistic filler ('on this planet', 'rather than trust this server') and a redundant tail: 'Free, keyless, read-only, moves no money. Cost and signer: free and keyless, nothing to sign.' repeats the same facts twice.

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 lookup with an output schema, the description covers derivation, provenance, null handling, and the REGEN settlement rule — everything needed to interpret the number. It stops short of distinguishing this from adjacent tools like hour_card or board_stats, which is the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly adds no parameter noise and instead spends its words on the returned value's 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 resource and unit: one number in US dollars per hour representing the global value of an hour of ordinary work, plus how it is derived (ILOSTAT mean earnings weighted by employee count, divided by average weekly hours). An agent knows exactly what value comes back, which is not inferable from the bare name 'labor_unit'.

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 concrete use contexts: judge whether a packet's pay is fair before claiming it, or price work about to be posted. It does not name a sibling alternative (e.g. hour_card, board_stats) or state when not to use it, so routing between related pricing tools still requires 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?

Goes well beyond the annotations by disclosing critical behavioral traits: it is board-side, not chain-side; credits sent outside a settlement door, retired by the holder, or spent elsewhere will not appear. It also clarifies cost/signer requirements ('free, keyless, nothing to sign') and notes that the reply itself states its board-side nature. These are exactly the kind of exclusions an agent needs to avoid misinterpreting returned figures.

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 in the first sentence, and most content earns its place by clarifying board-side scope and exclusions. Minor redundancy exists: 'Free, keyless, no wallet connection needed, just the address' is echoed later by 'Cost and signer: free and keyless, nothing to sign.' The all-caps emphasis is a stylistic quirk, not a structural flaw.

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 financial statement tool with an output schema and rich annotations, the description covers scope, exclusions, cost/auth, and when to use it. It leaves no essential behavioral question unanswered for an agent calling it with a wallet address.

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% (single workerWallet parameter with its own description: 'Address only, never a private key'). The description repeats that only an address is needed but adds no syntax or formatting detail beyond the schema. Baseline 3 is appropriate when the schema fully documents the only 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?

Starts with a specific verb+resource ('The time-bank statement for one wallet') and enumerates exactly which figures it reports (hours claimed, accepted, settled, VSH credit in/out, board-record holding). It explicitly distinguishes itself from a chain balance and names the authoritative alternative. An agent can tell this is a read-only board-side statement, not a generic ledger.

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 when-to-use ('whenever the person asks how they are doing, what they have earned, or what they can spend') and when-not ('Read Regen Ledger for the real balance'). However, it does not route among the many sibling statement tools (account_statement, hour_card, my_ledger, my_money), leaving some ambiguity about which board statement to pick.

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 establish read-only, idempotent, open-world behavior, and the description goes further: unreadable sources are named under 'unreadable' with counts reported as unknown rather than zero, some records lack per-wallet reads, default ordering is newest-first with order/limit for paging, and only an address is accepted (never a private key). It also flags derived data (conditions inferred from settled jobs) and the epistemic status of each record type — a real addition over 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 opening clause is well front-loaded and answers the core question immediately, but the body is one dense paragraph mixing field enumeration, epistemic disclaimers, failure modes and paging, plus a stray typo ('VEALTH'). The semantic caveat is valuable but runs long and could be restructured into distinct sentences without losing 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?

With an output schema and full annotations carrying safety and return shape, the description still covers the non-obvious gaps an agent needs: partial-failure semantics (unknown vs zero), derived-versus-declared distinctions, and ordering defaults. Little that affects a correct call is missing, though explicit sibling routing 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 wallet, order and limit are already fully documented, and the description largely repeats them ('pass order and limit to page', 'address only, never a private key'). The one useful addition is that the summary always reflects the whole record regardless of limit, but that is already stated in the schema text — 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?

The description names a specific verb and scope: it returns the complete event-by-event record for one wallet, each row paired with its receipt. It enumerates what falls inside (claimed jobs, proofs, settlements, credits, payouts, votes, titles, acceptor proofs, derived conditions), so an agent can tell it apart from narrower siblings like my_work or account_statement without inspecting schemas.

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 the tool composes what my_work, my_money, my_votes and worker_titles already read and that it stores nothing, which implies those narrower tools exist for scoped reads. But it never says when to prefer this over a sibling or when to fall back to one — the routing choice 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 already cover read-only, idempotent, open-world, and non-destructive behavior, but the description adds substantial context beyond them. It explains that every figure is board-recorded rather than chain-read, that credits are receipts and never spendable money, that the board prices no token, that there is no cash-out rail, and that the call is free and keyless. These are important behavioral constraints and there is no contradiction 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 purpose is front-loaded in the first sentence, but the description is long and repetitive. Several all-caps sentences restate the board-versus-chain point and the credit-is-not-money point, and the phrase 'exactly three doors' is left undefined. Some caveats earn their place, but overall the text is overlong for the information it conveys.

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 aggregate read with an output schema, the description explains the tool's nature, major caveats, cost, and broad usage trigger. The output schema can carry return-value detail and the parameter schema covers inputs. It still omits routing guidance against many overlapping siblings and leaves 'three doors' unexplained, so it is strong but not 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 100%, and both lang and workerWallet are fully documented in the schema. The description mentions reading one wallet and being free/keyless, but it adds no syntax, format, or semantic details beyond the schema. With the schema doing the heavy lifting, the baseline score of 3 is appropriate.

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

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

The description states a specific verb/resource: it reads one wallet's whole money picture and enumerates settled dollars, other settled tokens, receipts, standing offers, hours, ledger entries, and three doors. It clearly distinguishes this as a board-side record rather than a chain balance. It does not name or differentiate from overlapping siblings such as account_statement, my_ledger, my_hours, or my_next_step, so it falls 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 a broad trigger: use whenever the person asks what they have, what they are owed, or what to do next with it. But with many overlapping siblings, especially my_next_step, my_ledger, my_hours, and account_statement, it provides no explicit alternatives or exclusions. The usage guidance is therefore implied rather than fully actionable.

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 safe-read profile, yet the description adds substantial invariants: it never offers an entry-level person a never-entry-level or unlisted work type, never offers a packet the wallet cannot claim, never skips a rung, never asserts fitness, never lets a declared title move a level, and names unreadable sources as unknown rather than zero. It also discloses that watcher training is never a credential and gates no seat, and that pay is proposed unless funded — behavioral detail unavailable anywhere in 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 in the first sentence, but the body is a single dense run-on that stacks multiple rules into comma-chained clauses and repeats the free/keyless/read-only claim twice (mid-text and in the cost and signer line). The content earns its place, yet the structure makes it hard to scan.

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

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

An output schema exists, so return shape need not be explained. For a tool this rule-heavy, the description still covers fallback behavior, no-record behavior, the never-offer constraints, and the epistemic caveats about unknown data — everything an agent needs to call it correctly and interpret the answer.

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 genuinely new semantics: lat/lng may be omitted and the tool then uses where the last accepted job was and says so, and the wallet must be an address and never a private key. Radius defaulting is left 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?

The opening states a specific verb and resource: it reads one wallet's own record and names ONE open claimable packet near their place plus ONE training step leading to the next rung, with reasons. That is far more precise than the title. It does not name which siblings it competes with (find_work, next_action, my_work, start_here), so an agent still has to infer the boundary, which keeps it from a 5.

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

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

Usage context is clear and conditional: a person with no record gets an entry-level first job and the reply says so; when the record says a seat is next it additionally names watcher/reviewer training; a place can be omitted and it falls back to the last accepted job. What is missing is explicit routing against alternatives — nothing says when to prefer find_work or next_action instead of this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety bar is pre-cleared. The description adds real value beyond them: pledges are intent only, nothing is held or moved until funding settles, and it records nothing about the caller. It does not describe result size or whether historical/withdrawn votes are included.

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 and largely substantive, but the closing sentence "Cost and signer: free and keyless, nothing to sign" repeats the earlier "Free, keyless, read-only" clause and does not earn its place. The redundancy costs it a point despite otherwise tight phrasing.

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 needn't explain return shape, and it covers the one semantic distinction an agent could misread: pledged ≠ funded. What it omits (pagination, whether withdrawn votes still appear) is minor given the structured fields.

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 parameter already documents "0x… address only, never a private key." The description adds no format, casing, or normalization detail beyond the schema, so the baseline 3 for high-coverage schemas 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: one wallet's whole demand history, covering every packet voted for/against and every packet pledged to back. It is unambiguous about scope. It doesn't name a sibling (e.g., hydrex_votes, prepare_vote) to contrast against, which keeps it 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?

"Use this when someone asks what they voted for, whether their vote is still active, or what they have pledged" gives concrete triggering conditions. It also implicitly routes funding questions elsewhere by noting payment settles through prepare_funding. No explicit when-not conditions or named read-alternatives 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world, but the description adds non-obvious traits: it is free, keyless, stores nothing about the person, and therefore cannot know the last-check time unless `since` is passed. That is exactly the kind of context annotations cannot carry. It omits anything about result size or pagination, keeping 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 core inventory is front-loaded in the first sentence, which is good, but the prose is dense and oversized, and the free/keyless claim is stated twice ('Free, keyless, read-only…' and again 'Cost and signer: free and keyless, nothing to sign'). Several clauses could be trimmed without losing 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 shape need not be spelled out; the description still enumerates what categories of results come back and why. Privacy, cost, and auth posture are covered, leaving only minor gaps such as expected result size. Complete enough for an agent 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, but the description adds rationale the schema lacks: it explains why `since` matters (nothing is stored, so without it everything is listed) and ties the nearby-work section to the optional location input. It does not restate wallet/near mechanics beyond that, which 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?

Uses a specific verb-plus-resource framing: it returns everything for ONE wallet — claimed packets, their statuses, pending/rejected proofs, settled receipts, and nearby open work. An agent can tell it is a personal dashboard rather than a search or single-packet lookup, though it never names the nearest siblings (work_status, my_ledger, my_next_step) to sharpen the distinction.

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

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

Gives concrete trigger questions — 'how their work is going, whether they got paid, whether anyone reviewed their proof, or what to pick up next' — which maps cleanly onto user intents. It also explains the operational context (no email or notifications, so this is how a person stays with the process). No explicit when-not-use or named alternatives, 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?

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, and the description adds cost/auth context: 'free, keyless, moves no money, nothing to sign.' It also clarifies the semantic boundary that a contract is not activation, payment, or outcome. Some repetition of 'read-only' 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 core purpose is front-loaded, but the description is a long run-on list of every returned facet and then repeats 'free, keyless' in two consecutive sentences. With an output schema already present, that enumeration is largely redundant and should have been 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?

Given a one-parameter read-only tool with rich annotations and an output schema, the description gives enough context about scope, safety, and the evidence-ladder caveat to call it correctly. It could be improved by naming net_programs as the source of ids, but that is already in the 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?

Schema coverage is 100% and the single 'id' parameter is already documented with its source in net_programs and an example. The description adds no further meaning about the id format or constraints, 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?

The description states a specific resource ('One NET demand mechanism') and enumerates the contract facets returned, so an agent knows it retrieves full details for a single mechanism. It does not explicitly contrast itself with sibling tools such as net_programs or net_review_evidence, keeping it below 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 by saying it returns the mechanism 'in full' and warns that a contract is not activation, adoption, payment, or an outcome, which sets a when-not boundary. However, it names no alternatives and gives no explicit routing guidance, so an agent must infer when to choose it over related tools.

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

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

Although annotations cover 'readOnlyHint: true,' the description adds crucial behavioral context by detailing the lack of financial friction ('no money moves,' 'free, keyless'), and the contents of the listing (deliverable, price, judge, deadline). This greatly enhances the agent's understanding of the operation's safety and function beyond metadata.

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 highly efficient; the initial sentences establish the core function, and subsequent sentences handle necessary, specific limitations (cost/commitment) in a logical progression without bloat.

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 complexity of a finance/work platform, the description is highly complete. It covers the nature of the data (what's listed), the safety of the action (read-only, no commitment), and the scoping methods (limit, programId), leaving no critical behavioral question unanswered.

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?

Since schema coverage is 100%, the description doesn't need to explain parameter formats. However, it adds semantic value by explaining that `programId` scopes the task search to specific domains, providing context for the abstract IDs listed 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 clearly identifies the purpose as listing 'specialist tasks' that a provider can take. It successfully defines the resource, differentiating it from general work searches by using specific scope and listing the categories of tasks (e.g., data integrity, research replication).

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 provides explicit operational guidance, stating that 'Reading a task commits nobody' and that agreement to the NET amount happens separately. This establishes a critical boundary between discovery (reading) and commitment (agree/pay), preventing incorrect tool use.

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, it discloses cost (free), auth (keyless, nothing to sign), a dry-run semantic (dry-run orders never show a payment), and the non-mutating guarantee. That auth/cost/dry-run context is genuinely additive. Some overlap with readOnlyHint (read-only, changes nothing) is redundant but harmless.

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 primary purpose is front-loaded and the two modes are easy to scan. There is mild redundancy between 'Free, keyless, read-only' and 'Cost and signer: free and keyless, nothing to sign,' which slightly dilutes an otherwise efficient description.

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 covering return values, full annotation coverage, and 100% schema description coverage, the description supplies the remaining needed context: both operating modes, dry-run behavior, and access/cost model. An agent has everything required 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 description coverage is 100%, so the baseline is 3. The description confirms the refusal parameter's purpose (plain meaning plus next step) but adds little syntax or format detail beyond the schema's own 'insufficient_net_coverage' example and NETORD_ pattern.

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 one NET service order') and enumerates what the order object contains: state, who acts next, product gates, and a verifiable service receipt. It also covers the second mode (refusal-code lookup). It does not, however, name or distinguish itself from nearby siblings like next_action, request_status, or work_status, 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 clear usage context for both entry points: pass an order to inspect state/gates/receipt, or pass a refusal code to get its meaning and next step. It stops short of explicit exclusions or naming the alternative tool to use instead, which is why it isn't 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?

Annotations already declare readOnly, idempotent, non-destructive behavior, but the description adds material context: declared site authority remains unverified until a human verifier confirms it, NET figures are house references rather than executable prices, and nothing is recorded, posted, signed, reserved, or paid. These disclosures go beyond the structured annotations and are behaviorally important for the agent.

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 the content is substantive, but the description repeats the free/keyless/no-signature point twice ('Free, keyless, moves no money' and 'Cost and signer: free and keyless, nothing to sign'). The long initial sentence also packs many concepts together, reducing clarity.

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

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

The tool has a complex nested input and an output schema, so the description does not need to explain return values. It covers the key caveats around authority verification, NET references, and absence of side effects. It could be more complete by explicitly relating this preview to sibling tools such as provision_plan or prepare_place, but the core context is present.

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

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

Schema description coverage is 100%, and the nested commission parameter is already well documented in the schema. The description provides only high-level framing of what the preview evaluates and does not add field-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description gives a specific verb ('Preview') and resource ('commissioning repeated upkeep at a real place'), and enumerates what the preview covers: governed work, authority, dated cycles, measurement, and NET requirement. It does not explicitly distinguish itself from nearby siblings such as provision_plan or prepare_place, so it falls 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?

The description implies this is a preview before commissioning and notes that it is free, keyless, and moves no money. However, it does not explicitly state when to use this versus prepare_place, provision_plan, or submit_place, leaving the agent to infer the 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?

Beyond the read-only annotations, it discloses important behavior: evidence-ladder levels are derived from evidence and never configuration, most mechanisms are contract-complete only, and discovery requires no wallet, registration, or NET. It also states the tool is free, keyless, read-only, moves no money, and requires nothing to sign.

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 main sentence is dense and the access/cost information is repeated: free/keyless/read-only/no money appears in both the body and the closing cost-and-signer line. It is informative but 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?

Given the output schema and rich annotations, the description is complete enough for an agent to call it correctly: it explains the input intent, the returned evidence levels, what code runs mechanisms, and the wallet/registration-free access model.

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 schema already documents limit, family, and objective. The description reinforces that the objective should be plain-language, but it does not add meaningful semantics for limit or family beyond the schema.

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

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

The description uses a specific verb-and-resource framing: it takes a plain-language objective and returns the NET programs and demand mechanisms that fit. It also distinguishes the output from a single-mechanism lookup by returning a set of programs with evidence levels and running code.

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 describes when to use the tool: when the user can state a NET objective in plain words and wants matching programs and mechanisms. It also states access prerequisites, but it does not explicitly name sibling alternatives such as net_mechanism or net_review_evidence and when to use those instead.

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 readOnly/idempotent annotations, it discloses cost (free, keyless), that it moves no money and requires nothing to sign, and critically frames the meaning of its output ('no machine-checkable blockers never means the work happened or was good'). That interpretive caveat is exactly the kind of behavioral context annotations can't 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 purpose and the key caveats are front-loaded and earn their place. There is mild redundancy between 'Free, keyless, moves no money' and the closing 'Cost and signer: free and keyless, nothing to sign,' which repeats information rather than adding 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?

With an output schema present, annotations covering the safety profile, and full schema coverage, the description needn't explain returns. It completes the picture with the dry-run framing and the crucial output-interpretation caveat, leaving nothing an agent needs 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?

With a single fully-specified parameter (100% schema coverage including nested package structure), the schema carries the semantic load, so the baseline is 4. The description adds no field-level detail beyond what the schema already documents.

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 — a reproducible 'second read' of a 'work-evidence package you hold' — and enumerates exactly what it surfaces (missing evidence, impossible captures, checklist, artifact hash). This clearly separates it from siblings like verify_work or prepare_evidence_surface by scoping it to a dry-run review of a caller-supplied package.

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 timing guidance ('before it goes to the human who accepts it') and explicit exclusions (creates no order/receipt, never accepts or rejects). It does not name a specific alternative sibling to use instead, which keeps it just 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.