vealth

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses keyless access, that it stores nothing, that payments settle on a public chain, and that hashes are independently verifiable without trusting the server. This adds materially useful trust and privacy context for a financial-history tool.

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

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

Four sentences, front-loaded with the core result, followed by usage triggers and trust/privacy context. There is no filler or repetition; every sentence contributes a distinct fact an agent needs.

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

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

The description is self-sufficient: it states the data returned, use cases, verification model, and access characteristics, while the output schema and 100% parameter coverage supply the remaining structure. There is no missing invocation-critical information.

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 reinforces the 'wallet' parameter by explaining the result is per-wallet payment history, but it adds no parameter-level detail beyond the schema, and 'limit' behavior is already documented 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 opens with a specific and complete statement: 'One wallet's complete payment history with this server', and enumerates exact contents (settled calls, cost, door, on-chain hash, totals, per-door breakdown). This sharply distinguishes it from the many payment and submission siblings in the tool list.

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

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

It gives explicit triggers: 'Use it when someone asks what they have spent here, whether a call was charged twice, or for an expense record.' It does not name exclusion cases or sibling alternatives, but the context is clear enough that an agent can select this over future-facing or action-oriented payment 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?

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds valuable behavioral context beyond these: the onchain batching delay ('next weekly Base batch'), the privacy guarantee (only hash sent), and the zero-cost aspect. It does not contradict any annotation and provides useful operational detail 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?

A single well-organized paragraph that front-loads the core action and immediately explains why and when to use it. Every sentence earns its place: purpose, usage contexts, privacy, mechanics, and cost. No filler or redundancy.

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

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

Given the tool's complexity (write, non-idempotent, delayed onchain effect), the description covers all critical aspects: what happens (lands in batch and Ethereum root), cost (free), prerequisites (none), and the long-term verification capability. An output schema exists, so return values are covered elsewhere. An agent has enough to decide and safely call this tool.

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

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

Schema description coverage is 100%: both 'label' and 'sha256' have descriptive text including the shasum command and security warning. The description reinforces the hash-only policy but adds no new parameter-level semantics beyond the schema. Baseline of 3 is appropriate since the schema already carries the full parameter documentation.

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

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

The description states a specific action ('Anchor the SHA-256 of any file onchain') with a specific resource (file hash) and outcome (proving existence by a time). It clearly distinguishes from siblings like verify_anchor and other submit_* tools by focusing on the anchoring action and its priority-preservation purpose.

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

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

The description explicitly says 'Use it the moment you produce something whose PRIORITY matters' and provides concrete examples (security finding, research, draft). It also clarifies what the tool does NOT do ('You send only the hash, never the file') and implies a contrast with verification tools. This is more than sufficient for an agent to decide when to invoke it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'Never cached' indicates real-time data, and 'keyless' clarifies access requirements. This enriches transparency without contradicting 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 two sentences, front-loaded with the core purpose and metrics, then adds usage context (location) and operational details (never cached, public mirror, free, keyless). Every sentence contributes meaningful information with no redundancy or fluff.

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 detail return formats; it appropriately lists the main returned metrics (total/open work, claims, settlements, proposed value, sector breakdown). Optional location behavior is explained, and annotations cover the read-only, idempotent nature. Nothing essential is missing for an agent to invoke this tool correctly.

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

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

Schema description coverage is 100%, with each parameter (latitude, radiusKm, longitude) having a clear description. The tool description adds a high-level concept of 'location' and 'nearby' but does not provide additional syntax or format details beyond what the schema already offers. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Live counts from the Vealth work board' with specific metrics (total/open work, claims, settlements, proposed value, sector breakdown). It uses a specific verb ('read', 'count') and resource, and the unique functionality of optional location-based nearby counting distinguishes it from siblings like find_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 description provides some usage guidance: 'Pass a location to also count work nearby' and notes that it is free and read-only, but it does not explicitly mention when to use this tool versus alternatives or when not to use it. The context is clear enough to infer appropriate use, but lacks explicit routing or exclusions.

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

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

The description is unusually transparent about mechanics: it registers the hash with Skip Go's tracker, reads Skip state, may also read Axelar, and never infers landing from elapsed time. However, the description directly contradicts the readOnlyHint annotation by saying the tool 'registers the hash' with a tracker, which is a state-changing action. Per the rubric, this contradiction forces a score of 1.

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

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

The description is long but every sentence carries operational value: prerequisite, side effect, source-chain differences, return semantics, landing criteria, measured times, and wait interval. It is front-loaded with the core purpose before detailed behavior, and there is no filler.

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

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

For an agent to call and poll this tool correctly, the description covers the prerequisite, the one-time registration effect, cross-chain behavior, what landed means, and how long to wait between calls. An output schema exists for return fields, so the description does not need to restate them. The only serious flaw is the annotation contradiction, not a completeness gap.

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

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

Schema description coverage is 100%, so the schema already fully documents chain and tx_hash. The description adds contextual behavior such as Base/Arbitrum additionally reading Axelar, but it does not add standalone parameter-level meaning beyond what the schema 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?

The description states a clear, specific operation: determining where a REGEN bridge transaction stands using the hash the caller broadcast after prepare_bridge. It distinguishes itself from siblings by scoping to REGEN bridge transactions, naming its dependency on prepare_bridge, and explaining its keyless nature.

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

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

The description explicitly says to call it after prepare_bridge and warns that a status read before registration is blank forever. It also gives polling guidance by saying how long to wait before asking again. It does not explicitly say when not to use it or name alternative status tools, 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?

Beyond the annotations (read-only, open-world, idempotent), the description adds substantial behavioral detail: every requirement maps to exactly one of six semantic categories, the reply never decides or says 'qualified,' and it includes a receipt hash for anchoring. This is rich context that helps an agent correctly interpret results.

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

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

The description is dense and front-loaded, with the core 'machine comparison, human decision' sentence first and the six output words defined compactly. It loses a point for the redundant 'read-only' closing (already in annotations) and the public mirror URL, which add marginal value for an agent selecting or invoking the tool.

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

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

Given the six-way classification semantics and the receipt-hash behavior, the description is nearly complete on its own. The output schema exists, so return-field details need not be explained in prose. An agent knows enough to invoke it correctly and interpret all possible outcomes.

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 percent, with detailed schema descriptions for both wallet and require. The tool description reinforces the job-vs-requirements framing but does not add syntax or semantics beyond what the input schema already provides, so the baseline score of 3 applies.

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

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

The description and title clearly identify a comparison tool: a wallet's titles are placed beside a job's requirements, and each requirement resolves to one of six enumerated words. This is distinct from sibling tools like worker_titles (which likely lists titles) and verify_work (which likely verifies a single fact).

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 states the stated usage context: give a wallet and the requirements of a job or project. It does not explicitly name alternatives or state when not to use it, but the comparison purpose is clear enough that an agent can infer when this tool is relevant.

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, openWorldHint, and destructiveHint=false, so the safety profile is known. The description adds concrete behavioral details beyond that: it is free, keyless, moves no money, returns a refusal reason when a wallet has no settled work/no banked credit, and notes that facts are public and readable at their own endpoint. It also mentions the HTTP endpoints for issuance, which adds transparency about the workflow. No contradiction with 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 lengthy (about 180 words) and packs in extra details like the HTTP issuing endpoints and the statement about facts being public. While it is front-loaded with the core purpose, some sentences (e.g., the issuing endpoint specifics) could be trimmed without losing essential meaning. It is not verbose enough to be a serious problem, but it is not as concise as it could be.

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

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

For a two-parameter optional tool with an output schema, the description covers the essentials: what it returns (price, content, refusal reason), how to choose the input, refusals, costs, and read-only safety. The output schema presumably details return fields, so the description doesn't need to. It could explicitly state whether exactly one parameter is required, but the 'or' phrasing implies that. Overall, it is 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 description coverage is 100%, so both parameters have meaningful descriptions. The description adds further nuance: it explains that a wallet for a work-record certificate includes settled packets, accepted proofs, and banked credit, and that a place is for a standing certificate under The Vealth Standard. It also clarifies the refusal condition involving the wallet parameters, which enriches parameter understanding beyond the schema.

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

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

The description clearly states the tool's purpose: to price and preview a Vealth credential certificate before payment. It names the resource (credential certificate) and the action (price and preview), and distinguishes between two certificate types (work-record and place). The title reinforces this, and no sibling tool overlaps with this exact pre-purchase preview behavior.

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 when to use the tool (before paying, for pricing/preview) and provides guidance on selecting the parameter type (wallet for work-record, place for standing certificate). It implies it is not for actual issuance since it says 'BEFORE paying' and notes that payment buys the artifact. It doesn't explicitly name alternative tools, but the context makes usage boundaries clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable context beyond those: it discloses the data source ('the file the code itself obeys') and clarifies that a stopped lane is stopped by decision, not broken – an important interpretive nuance that prevents misinterpretation. This exceeds what annotations provide.

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 concise sentences. The first states purpose and data source in a front-loaded manner; the second adds a meaningful clarification about stopped lanes. The phrase 'Free, keyless, read-only' is a short, useful note about access, adding no unnecessary length. Every word earns its place.

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

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

With no parameters and an output schema available (indicated by 'has output schema: true'), the description covers purpose, data source, and interpretation of results ('and why', 'stopped by decision'). It is complete for an agent to decide when to invoke it and to correctly interpret the response. No essential information is missing.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The description appropriately omits parameter details, meeting the baseline for zero-parameter tools. No additional parameter explanation is needed.

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

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

The description clearly states the tool reports whether each recurring-spend lane is running or stopped, and why, sourced from the configuration file the code obeys. It distinguishes itself from all siblings by focusing on 'recurring-spend lanes', a concept not covered by any other tool. The title reinforces the purpose.

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

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

The description implies usage by specifying the authoritative data source ('read from the file the code itself obeys'), making it clear this is the canonical source for lane status. While it does not explicitly name alternatives or exclusion conditions, the 'recurring-spend lane' concept is unique among siblings, so an agent would correctly select this tool for such queries. Missing explicit 'when not to use' guidance is a minor gap.

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 and non-destructive behavior; the description adds meaningful context: data is read live from chain, the operation is keyless and free, and it discloses a real analytical pitfall about spot pricing. This goes well beyond the annotations.

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

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

Every sentence earns its place: scope, live data source, the pricing limitation, and access characteristics are all covered in a compact three-sentence description. Information is front-loaded and there is no repetition of schema or annotation content.

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

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

Given zero parameters, rich annotations, and the presence of an output schema, the description fully covers what an agent needs: the resource scope, freshness of data, access requirements, and a caution about interpretation. Nothing essential is missing.

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

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

The tool has zero parameters, so there is nothing for the description to clarify. The schema is already complete, and the description's live-chain note adds relevant context even though no parameter semantics are needed.

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

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

The description states a specific verb and resource: it lists every pool the user provides liquidity to, with reserves and share read live from chain. It is clearly distinguishable from siblings like gmx_get_positions by specifying LP positions generally rather than a particular protocol.

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 when to use the tool: when you need our LP positions and live reserves. It also provides an exclusion by warning against using raw balance ratios for pricing in concentrated-liquidity pools, though it does not explicitly name an alternative 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 establish read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: the call is free and keyless, the route list is intentionally closed, and the governing rules include gas pricing, a per-transaction fee cap, and EARTH's one-way token physics. This gives the agent useful expectations about cost, authentication, and domain constraints.

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

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

Three short sentences, each earning its place: the first defines scope and content, the second clarifies intentional absence, and the third states access cost, authentication, and safety. The most important scoping information is front-loaded.

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

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

For a read-only, zero-parameter reference tool with an output schema, this description is complete. It names the exact content area, the laws covered, the closed-set behavior, and the lack of authentication requirements. An agent can decide whether to call this tool and what to expect from it without further ambiguity.

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 the schema covers 100% of them, so the description carries no parameter-documentation burden. It appropriately focuses on what the resource contains rather than repeating empty schema fields.

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

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

The description clearly states that the tool exposes the authoritative, restricted set of asset conversions the system may perform, along with the rules governing them. It goes beyond the title by emphasizing that unlisted edges are intentionally absent, which gives the tool a well-defined scope. It does not explicitly name a sibling tool to differentiate from, but the phrase 'the only asset conversions our rails may perform' is specific enough.

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 that this tool should be used to determine which conversion routes are permitted and that anything not listed is intentionally unsupported. However, it never explicitly states when to prefer this tool over alternatives like crypto_lanes, prepare_bridge, or payment_options. The usage context is inferable but not directly 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?

While the readOnlyHint annotation already indicates safety, the description adds meaningful behavioral context: the tool is the canonical source used by the rails themselves, requires no key or payment, and the ECOWEALTH/EWP confusion has previously broken a live session. This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded with purpose, followed by critical usage guidance and a real-world warning. Every sentence earns its place, and there is no filler or 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 single-optional-parameter, read-only registry lookup with an output schema, the description is complete. It tells the agent why the tool exists, when to call it, what danger to avoid, and that no authentication is needed. Nothing essential is missing.

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

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

The schema already fully documents the only parameter, `symbol`, with an example. The description does not introduce new parameter-level details beyond the schema, so it earns the baseline 3. It does reinforce the example symbol but does not explain edge cases like omitting the parameter.

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

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

The description clearly states the tool's function: it returns the canonical on-chain address for every token the system operates on, sourced from the registry that the rails themselves use. It distinguishes itself as the authoritative token-address reference, especially with the explicit warning about ECOWEALTH versus EWP, which sets it apart from sibling token tools.

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

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

The description gives explicit timing guidance: 'Ask this BEFORE using any token address.' It clearly explains the critical context for safe use, though it does not explicitly list when-not-to-use or alternative sibling tools, which would be needed for 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 readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds the live-read aspect ('read at this moment') and the warning against quoting from documents, providing context beyond the annotations. No contradiction.

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

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

The description is two concise sentences. The core purpose is front-loaded in the first sentence, with usage and safety notes in the second. Every sentence earns its place with no redundancy.

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

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

For a simple read-only tool with one optional parameter and an output schema, the description covers purpose, usage, and behavioral characteristics (live read, read-only). It is complete enough for an agent to call it correctly without missing critical information.

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 parameter includeBalances is fully described in the schema (100% coverage), including its effect and default. The tool description does not add additional meaning beyond what the schema already provides, so a 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 clearly states the tool returns the three wallets, their roles, and live Base balances. It uses specific verbs and a resource, and distinguishes itself from sibling tools like crypto_tokens or crypto_lp_positions by focusing on wallet identity and balances.

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

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

The description explicitly instructs to use this tool instead of assuming wallet roles or quoting balances from documents, giving clear when-to-use and when-not-to-use guidance. It also implies the alternative (assumptions/documents) without naming a specific sibling, which is sufficient.

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 indicate read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral context beyond that: 'Vealth does NOT sell paper offsets,' the retirement lane 'is paused by operator order since 2026-08-04,' and 'this server never takes payment or holds a wallet.' This critically prevents the agent from assuming the tool can execute transactions or quote accurate carbon claims.

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

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

The description is dense and front-loaded with the core purpose ('anchor tool' + estimate + work), but it includes a lengthy digression about Vealth's business model and the paused retirement lane. That context is valuable but not strictly necessary to invoke the tool correctly, so it is slightly less concise than an ideal definition.

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 has no required parameters, a full output schema, and strong annotations, the description covers everything needed: what the estimate means, what it does not mean, what to do next, and the tool's non-transactional nature. An agent has enough context to call it correctly and interpret the result appropriately.

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% — both 'calls' and 'tokens' are fully described with approximate semantics. The description only reiterates that the values are 'rough' and that either can be used, without adding units, ranges, or parameter relationships. Baseline 3 is appropriate because the schema already handles the semantic load.

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

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

The description clearly states a specific action: take a rough token or call count and produce an order-of-magnitude CO2e estimate plus provisioning options. It distinguishes itself from siblings by calling itself 'the anchor tool' and explicitly directing the user to 'Call find_work next,' preventing confusion with actual provisioning tools like provision_work or funding_quote.

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

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

The description gives clear context on when to use the tool: when you want an orientation-level estimate for an AI session. It also provides a direct next-step routing instruction ('Call find_work next to pick the work') and warns that the estimate is 'orientation only, never a precise carbon claim.' It does not explicitly enumerate when not to use it, but the guidance is sufficient for this simple estimation 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 cover read-only, open-world, idempotent, and non-destructive behavior, so the bar is lower. The description adds genuine value beyond them: 'Free, no account, no wallet' and 'public board' tell the agent no credentials or wallet setup are needed. No rate-limit or pagination behavior is disclosed, but the schema's page parameter partly covers that.

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

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

Three sentences with zero waste: purpose first, then result contents and access requirements, then the usage trigger. Every sentence earns its place and adds selection-relevant information.

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

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

With an output schema present, four rich annotations, and 100% parameter coverage, the description only needs to enable correct selection, which it does. The only gap is not explicitly disambiguating from related siblings like get_work_packet when the user already knows a specific packet, but the 'public board' framing largely covers this.

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's 'near a place' phrasing aligns with the near parameter but adds no semantics beyond what the schema already provides, which includes rich detail like the exact-word-matching caveat and the remote filter's agent relevance.

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: 'Search Vealth's public board of real ecological and community work packets.' The 'public board' qualifier clearly distinguishes it from siblings like get_work_packet, my_work, and verify_work, and listing result contents (pay, skill level, proof, URL) sharpens what the tool returns.

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 an explicit trigger: 'Use this when someone asks for work, a job, a task, or something to do near a place.' This is clear context for when to invoke, though it does not name sibling alternatives or state when-not-to-use cases (e.g., when the user references a specific packet ID via get_work_packet).

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

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

The description goes well beyond the annotations by explaining that the quote is read from the board, never from caller input, that it reflects the outstanding obligation, and that a refusal comes in the board's own words. It also explicitly states 'this quotes, it charges nothing and marks nothing funded,' which aligns with and reinforces the readOnlyHint/idempotentHint annotations.

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

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

The description is front-loaded with the core purpose and audience, then adds necessary behavioral caveats and a next-step pointer. It is somewhat long, but nearly every sentence adds important context about quote accuracy, partial funding, refusals, and read-only behavior, so the length is justified.

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 tool has one optional parameter, a rich output schema, and strong annotations, the description is amply complete. It covers edge cases like partially funded packets, explicit premiums, stale wage quotes, refusal wording, and the distinction between quoting and funding, leaving no important ambiguity for an agent.

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 the single optional workId parameter and the omission behavior. The description reinforces the semantics but adds little beyond the schema for this tool; the partial-funding and premium details mostly apply to prepare_funding rather than funding_quote's own 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?

The description names a specific verb ('quote'), a specific resource ('board packet'), and an explicit audience ('BUYER, not a worker'), immediately distinguishing this from worker-side tools. It also clarifies that this tool only asks about funding and cost, not performs funding, which separates it clearly from prepare_funding.

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

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

The description explicitly states when this tool is appropriate: a buyer wanting to know whether a packet can be funded and at what current cost. It directly names the next action ('Call prepare_funding next to actually pay') and excludes workers from its intended audience, giving clear 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, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the return content (full description and proof requirement) but does not disclose error behavior or edge cases. Given annotations, this is adequate but not rich.

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

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

A single, front-loaded sentence that states the core purpose and content without any filler. Every word earns its place.

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

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

The tool is simple with one parameter and has an output schema, so the description need not detail return structure. It covers what the tool does and what is included. It does not explicitly mention missing-id behavior, but that is likely covered by the output schema or expected error handling. Adequate for a tool of this complexity.

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

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

Schema description coverage is 100%, and the workId parameter is fully documented with an example. The description only repeats 'by its id', adding no extra semantic value beyond the schema. Baseline of 3 applies given 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 states a specific verb 'get' with a specific resource 'single work packet' and clearly scopes it by 'its id'. It also lists key content ('full description and proof requirement'), which distinguishes it from siblings like 'my_work' (likely a list) and 'work_status' (likely status only). No ambiguity remains.

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

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

The description clearly implies when to use it: when you have a workId and need full detail. It provides clear context but does not explicitly name alternatives or when not to use this tool. That is a minor gap given the obvious distinguishing purpose among siblings.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'no signing needed' and 'free', plus specifies the network (Arbitrum) and protocol version (GMX v2). It does not disclose return format or pagination behavior, so it adds limited context beyond what annotations already 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?

A single, efficient sentence that front-loads the action and resource, then adds necessary usage constraints (read-only, no signing, free). No unnecessary words or repetition.

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

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

Given the single parameter is fully documented in the schema, an output schema exists, and annotations cover safety, the description is complete for an agent to invoke it correctly. It states the resource, network, and read-only nature, leaving nothing critical missing.

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

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

The schema describes the only parameter, wallet, as '0x… Arbitrum wallet address to check' with 100% coverage. The description does not add any additional parameter semantics, so the baseline of 3 is appropriate since the schema fully documents the parameter.

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

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

The description clearly states the verb 'Read', the resource 'all pending orders', and the scope 'for a wallet on GMX v2 (Arbitrum)'. It also lists example order types (limit, stop-loss) which distinguishes it from sibling tools like gmx_get_positions (positions) and gmx_get_prices (prices).

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 context is clear: this is a read-only tool for fetching pending orders, and the description explicitly says 'Read-only, no signing needed'. This implies when to use it (to check orders) and distinguishes from submission tools like submit_gmx_order, without explicitly naming alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Read-only' is redundant. However, it adds valuable context that annotations do not cover: 'no signing needed' and 'free', which are operational constraints an agent must know. This extra information justifies a score above the baseline.

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

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

The description is a single sentence of 20 words that front-loads the core action and scope. Every element (read, all open perpetual positions, wallet, GMX v2, Arbitrum) is necessary; there is no filler or redundancy.

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

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

For a simple read-only tool with one parameter, 100% schema coverage, and a provided output schema, the description is complete. It specifies the network and protocol, which are critical for correct invocation, and the annotations cover safety and idempotency. No missing information would prevent an agent from calling 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 schema fully documents the 'wallet' parameter as a '0x… Arbitrum wallet address to check'. The description merely repeats 'wallet' without adding syntax, format, or behavior details beyond the schema. Since the schema does the heavy lifting, a 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 states a specific verb ('read'), a precise resource ('all open perpetual positions'), and scopes it to 'a wallet on GMX v2 (Arbitrum)'. This clearly differentiates from sibling tools like gmx_get_orders or gmx_get_prices, which handle different aspects of the protocol.

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

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

The description provides clear context by specifying that this tool reads perpetual positions, which implies its appropriate use case. However, it does not explicitly compare to alternatives (e.g., 'use gmx_get_orders for orders') or state when not to use it, leaving some inference to the agent.

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

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

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds useful beyond-annotation context: 'no signing needed, free.' It also specifies the network (Arbitrum) and that it covers 'all tradeable assets,' which helps set expectations without contradicting 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 entire description is a single, front-loaded sentence that communicates the action, scope, network, and safety profile. There is no filler or repetition of the title. Every clause adds information an agent needs.

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

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

Given zero parameters, a present output schema, and comprehensive annotations, the description fully covers what an agent needs to know: what to expect, the network, the asset scope, and the read-only nature. No critical operational context 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?

There are zero parameters, so the schema carries no parameter details. The description clarifies that the tool fetches all tradeable assets with no filtering, which explains why no parameters are required. This matches the baseline for parameterless tools.

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

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

The description uses a specific verb and resource: 'Fetch current mark prices for all tradeable assets on GMX v2 (Arbitrum).' This clearly distinguishes it from trading tools like submit_gmx_order and account-oriented tools like crypto_wallets. The scope is precise and immediately actionable.

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

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

The description makes the context clear: this is for retrieving current mark prices on GMX v2. It implicitly signals use for read-only price queries before an order, but it does not explicitly name alternatives or state when not to use it. Since the tool is simple and zero-parameter, the context is sufficient.

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 supply readOnly, idempotent, and non-destructive hints, and the description adds genuinely valuable behavior: the tool is free and keyless, packet words are carried verbatim and never shortened, and the Swahili translation behavior is carefully explained including coverage counting and the safety-line English source. No contradiction with annotations.

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

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

The text is front-loaded with the purpose and a content list, and every sentence carries relevant information. However, it is a long, dense single block that would be easier to navigate if broken into paragraphs or bullets, making it heavier than strictly necessary for a two-parameter tool.

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

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

With only two params, a rich output schema, and annotations already covering safety and idempotency, the description covers almost everything an agent needs: content, ordering, language mode, constraints, and usage instructions. Minor edge cases like invalid workId are not addressed, but the output schema and low parameter complexity make the description complete enough.

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 base baseline is 3, but the description goes further by spelling out what lang='sw' actually changes: translation from a fixed dictionary, conditional translation of packet words, coverage counting, and safety-line handling. This enriches the lang parameter beyond the schema's simple enum.

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

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

The description clearly identifies the hour card as a document to read to a person before they start, and enumerates its contents in detail, which differentiates it from packet retrieval and status tools. It lacks an explicit operation verb like 'returns' and does not name sibling alternatives, 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?

The description gives concrete usage context: read it before starting, read it in order rather than summarising, and optionally in Swahili. It does not explicitly state when not to use this tool or mention which sibling tool should be chosen 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by explicitly stating 'Returns instructions, never performs the claim' and explains why (wallet signature required), plus the cost note 'Claiming is free.' This goes beyond the annotations by clarifying the exact behavior and rationale, though it doesn't detail the output structure or any edge cases.

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

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

The description is two concise sentences that front-load the core purpose ('Explains exactly how to claim work and what happens after') and then add essential context (free, no action, reason). Every sentence earns its place with no filler or repetition.

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

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

For a parameterless, read-only informational tool, the description is complete. It tells the agent what the tool does, what it does not do, and why. Combined with the rich annotations and presence of an output schema, an agent has everything needed to correctly invoke this tool without further investigation.

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 0 parameters, so the schema is trivially covered at 100%. The description correctly adds no parameter information because none is needed. This meets the baseline of 4 for a parameterless 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 clearly states the tool's purpose: 'Explains exactly how to claim work and what happens after.' It uses a specific verb (explains) and resource (claim work), and explicitly distinguishes itself from action tools like 'prepare_claim' and 'submit_claim' by noting it 'never performs the claim.' This makes it easy for an agent to know this is an informational tool, not an action.

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 when to use it: when you need instructions on claiming. It clarifies it does not perform the claim, which directs agents toward other tools for actual claiming, but it does not name those alternatives explicitly. The context 'claims requires the worker's own wallet signature' provides rationale, but a direct reference to sibling tools would make it 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, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond these: data is resolved directly from chain ('a zero here is a real zero rather than a degraded API'), it is free and keyless, and it returns only calldata shapes without executing or signing anything. No contradiction with 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 compact three-sentence paragraph that front-loads the core purpose and includes useful behavioral details. Minor stylistic flourishes such as 'The money answer' and 'rather than a degraded API' add character but are not strictly necessary, preventing a perfect score.

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

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

The description covers data source, scope, per-NFT granularity, non-execution behavior, cost, and auth requirements, while the existing output schema handles return-value details. Nothing critical is missing for an agent to decide when to invoke this tool and what to expect from it.

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 adds meaning by linking the address parameter to the voting wallet and explaining that rewards are tracked per veNFT (matching tokenIds). It also clarifies the computational scope (gauges, fee contracts, bribe contracts, reward tokens), which helps an agent understand how the parameters influence the result.

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 specifies a concrete function: compute exact claimable amounts per veNFT across fee and bribe contracts for every gauge a wallet votes for, then return calldata shapes. It also explicitly distinguishes itself from execution tools by stating it 'builds and signs nothing itself', which separates it from siblings like prepare_claim and submit_claim.

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

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

The description clearly states the context: use when you need to know claimable rewards and obtain calldata shapes for building a transaction, not for executing claims. It implies the boundary with 'builds and signs nothing itself', but it does not explicitly name alternative tools or give a precise when-not-to-use condition, 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 declare readOnlyHint, idempotent, and destructiveHint false. The description adds meaningful behavioral context: it reads live via ownerOf at call time, never assumes ownership, is free/keyless, and explicitly cannot sign or move anything. It also clarifies the deliberate separation of oHYDX and veHYDX, which goes beyond the annotation surface.

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

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

The description is a single, information-dense paragraph that front-loads the core purpose ('Everything about a veHYDX... read live') and packs details efficiently. Every sentence adds useful information without redundancy, though it could be slightly more structured for scanning.

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

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

Given the presence of an output schema, the description doesn't need to explain return values. It covers the tool's scope (veHYDX and oHYDX), ownership resolution, unlockability, and usage scenarios, making it complete enough for an agent to decide when to call it and what to expect.

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

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

Schema coverage is 100% with both parameters documented. The description adds value by explaining the address parameter is optional and that omitting it reads the server's own position, which clarifies the default behavior. It does not elaborate on tokenIds, but since the schema already describes it, a 4 is justified (baseline 3 plus a slight boost).

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

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

The description clearly states the tool reads a veHYDX position with specific attributes (owner, voting power, locked HYDX, unlockability) and also handles oHYDX separately. It uses specific verbs and resources, and explicitly distinguishes oHYDX from veHYDX, making its purpose unambiguous even among many siblings.

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

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

The description provides clear usage context: pass an address or omit it to read the server's own position, with owner resolved live. It does not name alternative tools like hydrex_votes or hydrex_claimable, but the guidance on how to invoke and what to expect is clear, which meets the 'clear context, no exclusions' bar.

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 and idempotentHint, so safety is covered. The description adds behavioral context: it computes live from the venue's per-gauge data, uses a specific measurement ratio, and compares advertised vs actual. This goes beyond the annotations and helps an agent anticipate the tool's computational nature. No contradiction with 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 packs a lot of information into two sentences with no filler. The purpose is front-loaded ('Call this before repeating...'), followed by a detailed explanation of the computation. The structure is efficient, though the long second sentence could be slightly more readable, but it earns its length.

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

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

For a tool with no parameters and an output schema present, the description adequately explains what it does and why. It contextualizes the output (comparison, structural ceiling explanation) without needing to describe the return format, which is left to the output schema. The only minor gap is that it doesn't explicitly state the output is a report, but that is inferable.

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

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

The tool has zero parameters, so the schema is trivially 100% covered. The description explains what data the tool uses internally (venue's per-gauge data, fees, bribes, vote fraction) without needing to document input parameters. This is appropriate for a no-arg 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?

Description clearly states the tool's function: comparing Hydrex's advertised weekly projection against actual collected income, and explaining the structural ceiling via per-gauge data. It uses a specific verb ('Call'), resource ('Hydrex'), and includes a distinguishing detail ('measured at 0.089% of the projection'). This sets it apart from sibling tools like hydrex_position or hydrex_vault that likely report raw position data.

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

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

Explicitly instructs when to use: 'Call this before repeating any Hydrex APR or yield projection.' This is a direct usage condition. It also highlights that it is free, keyless, and read-only, which encourages adoption and clarifies no setup is needed. Does not need to mention alternatives since it is clearly the go-to for verification.

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, openWorld, etc.), the description adds crucial behavioral context: that advertised APRs are display-only and not guaranteed earnings, and that depositing and staking are separate steps. This gives the agent a realistic expectation of what the tool returns and its limitations.

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 well-structured and front-loaded with the most important aspect (staking status). Each sentence adds distinct information (position contents, staking significance, APR labeling, default, and access). It is slightly verbose but not wasteful; a minor trimming could improve conciseness without losing 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?

With an output schema present, the return format is already defined. The description covers inputs (optional vault and address), the key output dimensions (shares, share, composition, staking), and an important caveat about APR display. It also notes keyless read-only access. Nothing essential for a read-only inspection tool is missing.

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

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

The input schema already fully documents both optional parameters with defaults and descriptions (100% coverage). The description repeats the default vault name but adds no new parameter-level detail, such as format constraints or usage notes, so it adds minimal semantic 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?

The description clearly states the tool's purpose: to report an ICHI single-sided vault position on Hydrex, including shares held, share of the vault, token composition, and crucially whether shares are staked. It distinguishes itself from sibling tools like hydrex_position by highlighting the staking status as the key output, which is likely unique to this tool.

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

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

It implies when to use the tool (when you need to know if shares are actually earning, i.e., staked) by emphasizing that unstaked shares earn no APR. It also mentions the default vault. However, it does not explicitly name alternatives or state when NOT to use it, such as pointing to hydrex_position for non-staking vault details.

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

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

The description goes well beyond the readOnly/idempotent annotations by exposing two non-obvious failure modes: mid-epoch partial system weight inflating share percentages, and a live gauge weight of zero despite a full vote on chain. It also states that percentages use the last completed epoch, which is critical for correct interpretation.

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 front-loads the core return value, then packs the caveats into a dense but purposeful warning, and ends with a concise access note. Every sentence contributes either to scope or to safe interpretation, with no filler or repetition beyond what annotations already provide.

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

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

For a one-parameter, read-only tool with no output schema, the description explains what is returned (allocation, epoch standing, emission rate), the denominator used, and the two traps that could mislead an agent. It does not enumerate concrete output field names, but the semantic contract is sufficient for invocation and interpretation.

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 only parameter, address, is already well documented in the input schema, including the default behavior when omitted. The description adds no extra parameter-level detail beyond identifying the wallet as the subject, so the high schema coverage carries the burden.

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

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

The description clearly states the tool's subject and action: reading a wallet's current gauge-vote allocation from VoterV5 on chain, plus epoch standing and live emission rate. The title's 'honest denominator' framing and the traps it names distinguish this tool from vote-submission, claim, or position tools without requiring schema inspection.

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

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

The description gives clear context for when the tool is appropriate: when you need a wallet's current gauge-vote allocation with an honest share denominator and epoch context. It does not explicitly name alternatives or say when not to use it, but the read-only, wallet-specific scope is clear enough for an agent to route correctly.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the added value comes from the description's detail. It discloses the derivation methodology (ILOSTAT earnings weighted by employee count), provenance behavior (publisher, URL, date returned), null handling ('nothing is ever guessed'), and REGEN payout constraints from governance proposal 77. This is rich behavioral transparency beyond the structured annotations, with no contradiction.

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

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

The description is front-loaded with the core concept and each subsequent sentence adds useful context: derivation, provenance, use cases, REGEN conversion, null behavior, and safety. It is somewhat long for a zero-parameter lookup tool, but the density is justified because labor_unit is a central pricing concept and the extra detail prevents misinterpretation.

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 zero parameters, a rich output schema, and strong annotations, the description is complete. It explains the return value's meaning, how it is derived, where the data comes from, how missing values behave, how REGEN conversion works, and when to use the tool. There are no significant gaps an agent would need to guess about.

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

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

The tool has zero parameters, so there is no parameter semantics for the description to clarify. The rubric baseline for zero-parameter tools is 4, and the description appropriately focuses on output semantics and units instead. It adds meaningful context about what the returned number represents and how it is computed.

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: one number representing the dollar-per-hour value of ordinary human work, and explains that it is the pricing yardstick for the board. It clearly distinguishes itself from sibling transaction/quote tools by framing labor_unit as a reference value for judging fairness and pricing work, not moving money.

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

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

The description explicitly tells the agent when to use it: 'Use it to judge whether a packet's pay is fair before claiming it, or to price work you are about to post.' It also clarifies a key boundary—dollars are the measure, REGEN is only the settlement asset—so the agent will not misuse the value as a REGEN price quote. This is strong usage guidance even without naming an alternative sibling.

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 mark this read-only, open-world, idempotent, and non-destructive, but the description adds meaningfully beyond that: it is a board-side statement, not a chain balance; every figure comes from this board's settlement records; the reply itself says so; and credits outside settlement doors, retired credits, or credits spent elsewhere will not appear. This is exactly the kind of limitation context that annotations do not 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 description is front-loaded with the core noun phrase and then delivers the enumeration before the caveats. It is longer than minimal, but each clause earns its place by clarifying scope, exclusions, or usage, and the structured sequence makes it easy to process.

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 single parameter, full schema coverage, existing output schema, and rich annotations, the description covers all essential context: what the statement contains, that it is board-side rather than chain-side, what is excluded, the alternative for real balances, and the exact user questions it answers. Nothing needed for correct invocation is missing.

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

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

The schema already fully documents workerWallet as a 0x address and warns 'Address only, never a private key.' The description adds complementary semantic value—'Free, keyless, no wallet connection needed, just the address'—which clarifies that no authentication or wallet session is required beyond the address itself.

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

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

The description opens with a precise resource—'The time-bank statement for one wallet'—and enumerates its exact contents: hours claimed, accepted, settled, VSH credit received and spent, and the board's recorded holding. It also distinguishes itself from a chain balance by explicitly saying 'IT IS A BOARD-SIDE STATEMENT, NOT A CHAIN BALANCE,' which separates it from balance-related tools.

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

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

The description gives explicit when-to-use guidance: 'Use this whenever the person asks how they are doing, what they have earned, or what they can spend.' It also names the alternative for real balances ('Read Regen Ledger for the real balance') and clarifies what will not appear, so an agent can avoid misusing it for chain-level balance checks.

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 assure read-only/idempotent behavior; the description goes further by stating it is a free keyless read, that no chain is read, that credits are not money, that the board prices no token, and that there is no cash-out. This prevents an agent from presenting board figures as spendable balance or chain truth.

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 overview list is front-loaded and the usage rule appears last, so an agent can quickly get the gist. It is wordy with repeated warnings ('never money', 'not spendable', 'nothing can be bought', 'no cash-out') that overlap, but for a financial overview these cautions are defensible.

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?

Combined with the output schema and annotations, the description is complete: it says what data is included, what it is not, what will never be returned (cash-out rails, chain truth, dollar values), and when to call it. Nothing important for correct selection or expectation-setting is missing.

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

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

The schema already documents both parameters completely (100% coverage), so the baseline is 3. The description adds no operation-level meaning for `lang` or `workerWallet` beyond the generic 'one wallet' phrasing; it neither clarifies nor obstructs the schema.

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

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

The description names the concrete resource ('a person's whole money picture' / 'everything one wallet...') and a specific verb ('read'), then enumerates the exact data groups it returns. The 'BOARD-SIDE RECORD, NOT A CHAIN BALANCE' clause distinguishes it from chain-looking tools even though no sibling tool name is cited.

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

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

It gives an explicit trigger: 'Use this whenever the person asks what they have, what they are owed, or what to do next with it.' It also sets a negative boundary by saying it is not a chain balance and that cash-out rails are never named. It does not name alternative sibling tools for those non-chain cases, so it falls just 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?

The description goes well beyond the annotations by explaining that voting and pledging 'move no money,' that a pledge is only a signed intent, that nothing is held until payment settles, and that the tool is 'free, keyless, read-only' and 'records nothing about the caller.' This is rich, non-obvious behavioral context consistent with the readOnlyHint and idempotentHint annotations.

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

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

The description is front-loaded with the core purpose and each sentence adds meaningful information: scope, use cases, the pledge-vs-funding distinction, and safety/read-only transparency. It is somewhat longer than average but every sentence earns its place given the subtle semantics around pledges.

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 simple single-parameter input, strong annotations, and presence of an output schema, the description fully covers what the tool does, when to use it, the meaning of pledge, and the fact that it is read-only and records nothing. No important context appears 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 the wallet parameter is already well described as 'The 0x… address that voted or pledged. The ADDRESS only, never a private key.' The description reinforces the wallet-centric scope but does not add additional parameter-level meaning beyond the schema, 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 uses specific, concrete language: 'One wallet's whole demand history' and 'every packet it voted for or against, and every packet it pledged to back.' This clearly identifies the resource (a wallet's voting/backing history), the action (viewing), and the scope, distinguishing it from voting/backing submission tools like submit_vote and submit_backing.

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

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

The description explicitly states when to use the tool: 'Use this when someone asks what they voted for, whether their vote is still active, or what they have pledged.' It also clarifies that a pledge is not funded and points to prepare_funding as the separate path for actual payments, providing clear 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?

Beyond the annotations (readOnly, idempotent, non-destructive), it discloses that Vealth sends no email or notifications, that the tool is free and keyless, that it records nothing about the person, and that `since` must be passed because no prior state is stored. This adds meaningful behavioral context the annotations do not express, and there is no contradiction.

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

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

The description is front-loaded with the overall scope and then gives trigger phrases and important context about privacy and statelessness. Each sentence serves a purpose, though the rhetorical framing 'One question, the whole picture' is slightly wordy and could be tightened.

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

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

With an output schema present and full schema parameter coverage, the description supplies the remaining essentials: what the tool covers, when to use it, how it behaves without stored state, and why `since` is needed. Nothing critical appears missing 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 every parameter already has a description. The description adds value by explaining why `since` matters—'it cannot know when they last looked, so pass `since` if you know'—and by reinforcing that wallet is an address only. This is above baseline but not extensively loaded with new semantics.

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

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

The description clearly identifies a specific verb, resource, and scope: 'One question, the whole picture for ONE wallet' and enumerates what it returns. It distinguishes itself by emphasizing the wallet-specific, all-in-one nature, but it does not explicitly name or contrast sibling tools like work_status or get_work_packet, so differentiation relies on context.

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

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

It gives explicit trigger scenarios: 'Use this whenever someone asks how their work is going, whether they got paid, whether anyone reviewed their proof, or what to pick up next.' This is clear when-to-use guidance, but it does not state exclusions or alternatives for related tools, leaving some routing judgment to the agent.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, but the description adds meaningful behavioral context beyond those: the tool is keyless, requires no custody of the user's supply, and discloses the market thinness and absence of profit promise. This honesty block is valuable qualitative info not conveyed by annotations. Not contradicting 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 single, dense sentence that packs a lot of meaningful details. It could be slightly unwieldy, but it is well-structured with a clear flow: what it does, what it returns, and a prominent honesty note. All sentences earn their place, though a line break or two 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?

For a zero-parameter, read-only tool with a rich output schema and strong annotations, the description covers everything an agent needs to decide and call correctly: what it does, who it's for, pricing, payment method, custody details, and risk caveats. No missing critical context is apparent.

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

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

The input schema has zero parameters, so the description doesn't need to compensate for parameter documentation. The description instead explains what the output covers (tiers, doors, sales status, payment method, honesty block), which is arguably more useful for an agent deciding to call it than a parameter list would be.

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

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

The title and description clearly state the resource ('Sovereign net worth as a service — your user's own token program') and the actionable verb 'returns' with specifics: tiers, doors, sales open status, payment method, and the honesty block. It distinguishes itself from siblings like net_subscription_status and funding_quote by focusing on a user-specific token program quote.

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

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

The description explains the offering, payment method (standard x402 from their own wallet), and explicitly notes it is free, keyless, and read-only. While it doesn't name alternatives explicitly, the context signals and sibling list make the tool's niche clear; a straightforward quote/read tool versus actionable funding or preparation tools. It lacks an explicit 'when not to use' statement but provides enough context.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond those annotations: it is free, keyless, and independently checkable on Base, which informs cost, authentication, and verifiability expectations. No contradiction with annotations 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 description is compact and front-loaded, starting with what the tool returns before adding verifiability and access qualifiers. Every sentence earns its place—'Free, keyless, read-only' is high-value decision information, and the Base verifiability sentence adds trust context without bloating the text.

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

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

For a simple single-parameter read-only tool with a rich output schema and strong annotations, the description is nearly complete. It conveys the input precondition, the kind of data returned, and the trust/cost profile; the only notable gap is not routing agents away from sibling tools like net_subscription_quote.

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

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

There is only one parameter and schema description coverage is 100%, so the schema already explains that wallet is the subscriber wallet (0x…) that paid. The tool description repeats this notion but adds no genuinely new detail about the parameter format or edge cases.

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 ('returns') and names concrete resources: paid months, program budget, asset naming, and fulfillment state. It clearly identifies the tool as a subscription-status lookup, though it does not explicitly distinguish it from the similarly named net_subscription_quote.

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

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

The phrase 'Given a subscriber wallet' establishes a clear precondition and usage context, and the enumerated return values make it obvious when this tool is appropriate. It does not name alternatives such as net_subscription_quote or specify when not to use it, so it misses the top score.

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

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

Beyond the annotations, the description discloses that the tool is free, keyless, read-only, and makes no chain reads. It also reveals the CI enforcement relationship, adding valuable behavioral context that is not present 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?

Three sentences: the first defines the tool's content, the second gives actionable usage guidance, and the third summarizes cost, access, and read-only behavior. No wasted words, and the most important scoping information is front-loaded.

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

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

The description provides the conceptual model, the when-to-use scenario, the enforcement mechanism, and the cost/access profile. With an output schema present and annotations covering safety, this is complete for an agent to decide whether and how to invoke the tool.

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

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

Schema coverage is 100%, and the single optional id parameter already includes a description with an example. The tool description does not add parameter-specific detail, but the schema carries the burden, so a 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 clearly states what the tool provides: a ledger of standing operator decisions, including the decision content, the operator's words, and machine-checkable enforcement. It distinguishes itself from sibling tools by focusing on governance decisions and their role in stopped lanes.

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

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

Explicitly instructs when to use: 'Ask this BEFORE reviving, patching, or questioning any stopped lane.' It also explains why (a rail may be stopped by decision) and notes the CI enforcement consequence, giving clear context for choosing 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 mark readOnly/openWorld/idempotent, but the description adds genuinely useful behavior: prices are read live from the door manifest rather than a stale table, the door's own 402 challenge is the final price truth, and each call is paid from the caller's own wallet at call time. This goes well beyond the structured hints.

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

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

Four sentences, all substantive, with the main purpose front-loaded. It is slightly longer than strictly necessary—'Free, keyless, read-only' partially repeats annotations—but every sentence earns its place by clarifying cost semantics, freshness, or workflow.

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 exists, one optional parameter, and read-only annotations, the description is complete enough for an agent to decide when to call it and what to expect: full price list, sorted cheapest first, live source, no wallet balance interaction, and final authority delegated to the door's 402 response.

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

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

Schema description coverage is 100%, so the single optional maxUsd parameter is already documented. The description adds useful context like 'cheapest first' but does not discuss the ceiling filter; the schema carries that weight, 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 clearly identifies the resource: 'the whole price list for this server's paid doors, in dollars, cheapest first.' It is phrased as a noun phrase rather than an explicit imperative verb, and it does not call out a sibling by name, but the function is unmistakable and the 'budget BEFORE committing' framing distinguishes it from payment execution tools.

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

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

Explicitly instructs when to use it: 'Use it to budget BEFORE committing to a call.' It also names the alternative behavior—without it, the only way to learn a price is to call a door and read the 402—and clarifies that there is no balance to top up, so agents know not to treat this as a wallet or prepayment 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds beyond annotations: it specifies that the check 'holds nothing, and charges nothing' and, critically, that an unreadable balance returns UNKNOWN rather than no, preventing false negatives from RPC issues. This is substantial behavioral context not present in 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 two sentences, front-loaded with the tool's purpose and result, then the usage guidance and a critical edge-case. Zero filler; every clause earns its place. The UNKNOWN behavior and no-charge note are wrapped into the final sentence 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 that the tool has an output schema (so return format is covered elsewhere), three parameters (fully described in schema), and annotations providing the safety profile, the description covers the essential context: what it does, when to use it, the alternative mode, and a critical failure behavior that could otherwise cause wrong agent decisions. No missing information prevents correct 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 coverage is 100%, so all three parameters (wallet, endpoint, amountUsd) are documented in the schema itself. The description adds only marginal semantic value: it clarifies that endpoint is a 'door name' and amountUsd is an alternative ('instead of'), but the schema already states 'A door name from payment_options' and 'Check against a plain dollar amount'. The description does not introduce new details about parameter formats or interactions beyond the schema, so the baseline 3 is appropriate.

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

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

The description opens with a precise verb-resource pair: 'Reads a wallet's live USDC balance on Base' and states the core answer it provides (covers a door/amount, exact shortfall, count of calls). It clearly distinguishes itself from payment_submit or prepare tools by being a pre-flight check, and the sibling list contains no other similar preflight tool.

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

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

It explicitly instructs to use it 'before a paid call so an agent never burns a turn discovering it is short', giving a strong when-to-use instruction. It does not name specific alternative tools or explicitly say when not to use it, but the 'before a paid call' framing implies the workflow position. The mention of 'or a given amount' also clarifies a second usage mode.

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, openWorld, idempotent, and non-destructive behavior. The description adds substantial behavioral context beyond these: the reading is 'recomputed this moment from settled packets with accepted proof', it 'LAPSES when the work stops', and 'Unread is an honest beginning, not a failure'. It also notes the tool is 'free, keyless, read-only', adding access details. No contradiction with annotations 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 description is compact: four sentences that define the tool, state when to use it, clarify acceptable semantics of 'Unread', and provide access details. Every sentence contributes meaningful information, and the core definition is front-loaded. There is no redundancy or filler.

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

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

With one parameter, rich annotations, and an output schema, the description covers the tool's core behavior, use case, and access model. The only notable gap is that domain terms like 'settled packets' and 'per condition' are not expanded, which could leave an agent uncertain about the exact computation semantics. Still, it gives enough context for a confident call.

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

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

Schema coverage is 100% for the single 'place' parameter, and the schema already explains it as 'a city, address fragment, or venue name'. The description's mention of 'one place' and the public URL '?place=…' adds only marginal context and no new semantics or examples beyond what the schema provides. Therefore, 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 action ('live reading') and resource ('one place'), with a clear scope of output: 'Standing (Unread or Read today)'. The title reinforces the purpose, and the focus on a single place differentiates it from broader tools like work_status or board_stats. However, it relies heavily on domain-specific jargon ('settled packets with accepted proof') and does not explicitly name any sibling tool it should not be confused with.

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

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

The description gives a concrete usage context: 'the reading to re-check after funding or completing work at a place', and explains that Standing 'LAPSES when the work stops'. This helps an agent decide when to call it. It does not explicitly state when not to use it or mention alternative tools, so it lacks the exclusionary guidance of the highest-scoring examples.

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, the description discloses key behavioral details: no email is sent, no wallet is needed, a pending place has no packet, and a posted place names a workId that is claimable. This meaningfully explains what happens and what does not happen during the call.

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, then gives query modes, state meanings, and the no-email justification. Every sentence earns its place and there is no filler or repetition of obvious schema information.

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

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

For a simple two-optional-parameter read tool with rich annotations and an output schema, this description is complete. It explains both query modes, the possible statuses, the meaning of pending versus posted, and why this endpoint exists, so an agent can confidently select and invoke it.

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 covers both parameters at 100%, so the baseline is 3. The description adds value by clarifying the wallet parameter means listing every place that wallet handed over, and by explaining how the returned workId relates to the posted status. This goes slightly beyond the schema without being redundant.

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

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

The description clearly states a specific verb and resource: 'Read an intake you handed over: pending, posted, or rejected with the reason.' It conveys exactly what the tool returns and covers both lookup modes. However, it does not explicitly distinguish itself from the similarly named sibling place_standing, so it lacks direct sibling differentiation.

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

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

The description gives clear usage context: pass intakeId for one intake, or wallet to list every place that wallet handed over. It also explains when the results are meaningful, such as pending meaning nothing to claim yet and posted naming the claimable workId. It does not explicitly name alternatives or exclusions, but the intended use is well implied.

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

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

Discloses a rich set of behavioral facts beyond the annotations: no fee/gas, no wage release, no settlement, no minting, and the refusal of house/worker wallets. The phrase 'writes onto the record' describes the overall acceptance outcome rather than this prepare step, so it does not contradict the readOnlyHint. A small ambiguity remains, but the disclosure is strong.

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

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

The description is dense and front-loads the core purpose, then uses capitalized emphasis for critical constraints. All sentences add useful information, though it is long and could be tightened; minor redundancy exists between 'no fee, no gas' and 'releases no wage... mints nothing.'

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?

Contains everything an agent needs to invoke the tool correctly: prerequisites, role restrictions, parameter conditions, signature requirements, expiry, return values, and the exact next step. The output schema also exists, but the description compensates for any missing schema detail and leaves no major 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?

Though schema coverage is 100%, the description meaningfully extends parameter meaning: hoursAccepted is 'the hours you actually stand behind... not the hours claimed unless you agree,' and allowAboveClaim is explicitly conditioned on crediting more than the worker asked for. It also ties acceptor to the specifically named wallet, adding real decision value.

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

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

States a clear action ('accept the hours somebody worked') as step 1 of a 2-step flow, explicitly names the follow-up sibling submit_accept_hours, and explains who is eligible ('named on a work packet'). This distinguishes it from other prepare_* and submit_* siblings without ambiguity.

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 context: use it only if the packet named you as acceptor, and not if you are the house wallet or the worker. It also tells the agent what to do first ('Read the proof first with get_work_packet') and what to do next ('sign with that wallet's personal_sign, then call submit_accept_hours within 5 minutes').

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