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?

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 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 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?

The description states that a pledge is 'recorded on the packet's public backer ledger,' which is a persistent state change, yet the annotations set readOnlyHint=true. This directly contradicts the annotation's implication that no state is mutated. The description even says 'NO money moves' and 'none of it is ever held by Vealth,' which might be read as no financial state change, but the public ledger entry is still a write. Per the rule, any contradiction with annotations results in a score of 1, regardless of the otherwise rich behavioral detail.

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

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

The description is a single dense paragraph, but every sentence serves a purpose: definition, non-custodial nature, balance-check behavior, distinction from payment, when to use, constraint, return values, signing method, and expiration. The most critical distinction (not a payment) is front-loaded. There is no filler or redundancy; the length is justified by the 2-step ceremony and signing requirements.

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 in a large family of prepare_* and submit_* siblings, this description is exceptionally complete. It explains the return values (MESSAGE_TO_SIGN and BODY_JSON), the exact signing method (personal_sign, not a transaction – no gas), the 5-minute window, and the follow-up tool (submit_backing). The output schema covers the raw structure, so the description need not repeat that. The only missing piece might be what BODY_JSON contains, but that is presumably in the output schema. This is a model of contextual completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds extra meaning beyond the schema: it clarifies that amountUsd 'cannot exceed the packet's posted wage,' that backerWallet 'must hold at least amountUsd for it to verify,' and that the backer wallet signs with personal_sign (a plain message, not a transaction). It also mentions the optional reason is shown on the public ledger. This added context compensates beyond the schema, earning a 4.

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

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

The description states a specific verb ('Pledge to back a packet') and resource, then goes further to differentiate itself from prepare_funding by explaining that a pledge is NOT a payment and never marks the packet funded. It clearly separates the two-step flow (prepare_backing → submit_backing) and names sibling prepare_funding as the alternative for real payments. This gives an agent a precise understanding of what this tool does and what it does not do.

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 identifies when to use this tool: 'Use this when you want to signal real backing without paying yet, or when you want the demand recorded even though you cannot pay onchain right now.' It also contrasts with prepare_funding ('only a real settled payment through prepare_funding does that') and provides the next step (submit_backing within 5 minutes). This is textbook usage guidance with clear alternatives and conditions.

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 carry readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description still adds meaningful context: the pledge row becomes WITHDRAWN rather than erased, the pledged total decreases, no money is refunded, the operation is free, and the same signature-gated authentication as pledging applies. It also clarifies the two-step flow with a time limit, which readOnlyHint alone wouldn't convey.

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

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

Three dense sentences cover the action, ledger effect, availability, cost, refund semantics, authentication, return payload, signer requirement, and next step. The most important information is front-loaded, and every clause adds value with 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 a two-parameter prepare tool with a rich description and an existing output schema, nothing critical is missing. The agent knows which parameters to provide, what response to expect, how to sign it, which wallet to use, what to call next, and the time limit for completion.

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 schema already documents workId as 'The packet id' and backerWallet as the same 0x address that pledged. The description reinforces the same-wallet requirement but does not add new parameter-specific constraints, formats, or discovery guidance 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 specific verb ('Take back a pledge') and resource ('pledge'), and the title adds 'step 1 of 2'. It clearly distinguishes itself from the submit step by saying it returns MESSAGE_TO_SIGN and BODY_JSON, which the agent must then sign and pass to submit_backing_withdraw.

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

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

It provides clear usage context: always allowed on every packet, regardless of lifecycle, and only valid if the caller actually pledged. It names the follow-up tool submit_backing_withdraw and the 5-minute signing window, but it never explicitly contrasts with the pledging tool prepare_backing or states 'when not to use' beyond implicit prerequisites.

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

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

With strong annotations already present, the description adds meaningful context beyond them: no fee/no gas, one open bid per wallet per packet with replacement semantics, acceptance mints the claim at the bidder's price through the standard admission checks, and closed-lane behavior. Nothing here contradicts the readOnlyHint or idempotentHint because the tool only prepares a signed offer; execution happens in submit_bid.

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 in the description carries essential information: purpose, cost, bid replacement semantics, downstream consequences, edge case, and immediate next steps. It is front-loaded with the core purpose and remains dense without 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?

For a two-step prepare/submit tool, the description covers purpose, cost, nonce/replacement semantics, acceptance path, closed-lane caveat, return format, signing requirement, and the 5-minute validity window. With an output schema available, no critical detail needed to call this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the role of bidderWallet in signing and the bidder's price concept, but it does not add substantial parameter-level detail beyond the schema, which already documents workId, amountUsd, bidderWallet, and bidderKind.

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: 'Name your price instead of claiming at the posted pay' on a work packet, and the title clarifies this is 'step 1 of 2'. It clearly differentiates from claiming at posted pay and from the sibling submit_bid, which executes the signed offer.

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 workflow guidance: sign the returned MESSAGE_TO_SIGN with the bidder wallet's personal_sign, then call submit_bid within 5 minutes. It also tells the agent when not to expect a bid to be accepted (closed claim lane) and where to verify that ('actions.bid.note'), plus contrasts with claiming at posted pay.

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 idempotentHint=true, but the description enriches this substantially: it states the tool returns a live quote and the exact unsigned transaction, that relayers handle every subsequent hop after broadcast, that no confirm step is required, that nothing is held by this server, and that fees are free. It also discloses failure-mode behavior by encoding refusals, which goes well beyond the bare annotation flags.

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 but front-loads the core purpose in the first sentence, then packs route limitations, fee structure, and failure-mode behavior into subsequent sentences. It is longer than typical, but every clause carries operational information an agent needs; the structure is logical and not padded.

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

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

For a complex multi-chain bridge preparation with an output schema present, the description covers all necessary contextual pieces: supported routes, the Osmosis exclusion and prerequisite, the non-custodial signing model, the lack of a confirm step, cost/fee expectations, and the minimum recommended amount. Nothing an agent needs to decide whether and how to invoke this 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?

Schema coverage is 100%, so the baseline is 3; the description adds meaning on top by explaining the practical implications of amount (flat toll ~333 REGEN, so send at least ~2,500 REGEN and batch), by reinforcing that sender and destination must be the caller's own addresses, and by noting the 6-decimal unit is consistent across chains. This is genuinely useful beyond the schema property descriptions.

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

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

The description opens with a specific verb-resource pair—'Prepare a REGEN bridge transaction'—and immediately distinguishes it from a raw transfer: it is non-custodial, caller-signed, and returns an unsigned transaction. It further narrows scope by listing exact supported routes (regen→arbitrum, regen→base, base→regen), making it unambiguous among the many sibling 'prepare_*' 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 clearly indicates when to use the tool: to bridge REGEN between the three named chains in a single self-signed transaction, and it explicitly excludes Osmosis-originating REGEN unless first IBC-transferred back. It also gives actionable guidance on minimum amount and batching due to the flat toll. However, it does not explicitly contrast with other preparation tools, relying instead on the resource-specific subject to differentiate.

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 non-destructive behavior, so the bar for added value is high. The description goes beyond this by disclosing that claiming is free and costs no gas, that the signature is proof of wallet ownership and not a payment, that the signed result expires in 5 minutes, and that no private key should ever be shared. This is rich behavioral context that an agent needs to handle the tool safely.

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: it states the purpose first, then the exact outputs, then the free/no-gas clarification, then the required signing and submission steps. Every sentence adds necessary operational or safety information, with 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?

Given that an output schema exists, the annotations cover safety traits, and the tool is part of a clear two-step workflow, the description covers everything an agent needs: how to obtain the work ID, what the return values are, that no payment is involved, that the signature expires, and exactly which sibling tool to call next.

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 each parameter already has a detailed description: workId comes from find_work, targetUrl is for self-verifying TEMPLATE packets, and workerWallet is the signing/owning address. The description does not add much parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific action ('Start claiming a packet for a wallet you control') and explicitly identifies this as step 1 of 2, naming the follow-up tool submit_claim. It clearly differentiates prepare_claim from its related sibling submit_claim, and even references find_work as the source of workId.

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 workflow guidance: it is the first step in claiming, requires a wallet you control, and explicitly tells the agent to sign the returned MESSAGE_TO_SIGN and then call submit_claim within 5 minutes. It does not explicitly state when not to use this tool, but the 'step 1 of 2' framing and explicit submit_claim handoff make the intended use unmistakable.

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

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

Beyond the annotations, the description discloses the return payload (MESSAGE_TO_SIGN and BODY_JSON), the signing requirement, the time limit, content-type restrictions, and the exact paths the surface serves. The reserve/submit split is consistent with readOnlyHint and idempotentHint.

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

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

The description is dense and front-loaded, with the core purpose in the first line and the flow laid out compactly. Minor flourishes like 'The door for an agent with NOTHING but a wallet' and the repeated 'free' cost a little, but the overall structure is efficient.

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

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

Given the output schema exists, return-value details are already covered, yet the description still names the key outputs and signing step. It also provides the surrounding flow, constraints, and sibling-step routing, so an agent has enough context to use this tool correctly without extra lookups.

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

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

The input schema already documents both parameters at 100% coverage. The description adds operational value by linking workId to find_work and tying workerWallet to the wallet that must personal_sign the returned message, which helps the agent call it correctly.

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 state a specific action — reserve a board-hosted evidence surface — and explain what the agent gets (a targetUrl). The description also names the exact lifecycle steps and distinguishes this from prepare_claim, prepare_evidence_write, and submit_evidence_surface.

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 when this tool is needed: funded remote template packets need a worker-controlled https origin, and this reserves that origin. It gives a precise flow — reserve → prepare_claim → publish with prepare_evidence_write → prepare_proof — and adds the 5-minute submission window.

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?

Annotation Contradiction: annotations declare readOnlyHint=true, but the description describes publishing files, a 'write gate', atomic replacement of the visible set, and a follow-up submit_evidence_write call. This is a serious inconsistency that could cause an agent to treat a write operation as read-only.

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: it opens with the precondition and core action, then covers constraints, atomicity, and the follow-up step. Every sentence earns its place 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?

The description covers the full workflow context: prerequisite, exact resource constraints, atomic visibility, returned values, wallet requirement, and 5-minute expiry. It would be complete if not for the contradictory readOnlyHint annotation, which undermines the overall guidance an agent receives.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful detail beyond the schema: resources must contain exactly paths the packet checks, contentType must be application/json, body is the authored JSON text, and signing must use the same wallet that claimed. This raises the score above baseline.

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

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

The description names a specific action ('publish the JSON files ... to your evidence surface') against a specific resource, and frames it as step 1 of a 2-step flow ending in submit_evidence_write. This clearly distinguishes it from prepare_evidence_surface and submit_evidence_write despite the large sibling 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 an explicit precondition ('After your claim binds the surface'), describes exactly what to pass, and specifies the immediate next action ('call submit_evidence_write within 5 minutes'). It does not explicitly discuss when not to use this tool or compare alternatives, but the step sequencing is clear enough.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false), the description reveals critical behavior: it never calculates a charge itself, holds no funds or keys, takes no payment, and marks nothing funded. This fully discloses side effects and safety boundaries, going well beyond what annotations convey.

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