vealth

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the description's job is lighter. The description adds valuable context about data provenance: 'each line settled from the caller's own wallet on a public chain, every hash is independently verifiable without trusting this server', and states 'stores nothing about anyone'. This exceeds what annotations tell the agent. One point deducted because it does not mention pagination behavior for the limit parameter, which could be relevant for large histories.

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 paragraph of 3 sentences, all front-loaded with the core purpose. Every sentence adds distinct value (purpose, usage scenarios, trust/privacy guarantees). One point deducted for slightly run-on first sentence that lists items; a short bullet structure or break could improve scannability, but it remains concise overall.

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 only 2 parameters, full schema coverage, comprehensive annotations, and an output schema, the description is complete. It explains what the tool does, when to use it, data provenance, and privacy/trust characteristics. No gaps remain for an agent to make an informed selection or invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description goes far beyond the schema: it adds that wallet is 'The 0x… address that paid. The ADDRESS only, never a private key' (security context), and that limit is an 'Optional cap on payments returned (newest first)' (ordering and filtering semantics). This is exceptional additive value.

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

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

The description uses specific verbs and resources: 'payment history', 'every settled call', 'what it cost, which door it bought, and the on-chain hash', plus 'totals and a per-door breakdown'. This clearly distinguishes it from sibling tools like funding_quote, payment_options, or payment_preflight, which handle future or pending payments, not completed history.

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 this tool: 'when someone asks what they have spent here, whether a call was charged twice, or for an expense record'. It also implies when not to use it (for future payments or quotes) by contrasting with sibling tools. This is the highest standard of usage 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?

Discloses critical traits beyond annotations: only hash is sent, never the file (privacy), batch timing ('next weekly Base batch and Ethereum root'), and cost ('free to submit, free to verify, no account, no wallet, no payment'). Annotations indicate openWorldHint=true and non-destructive, but the description adds rich behavioral context that fully prepares 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 paragraph of ~100 words, front-loaded with the core action. Each sentence earns its place: purpose, use cases, mechanics, privacy, timing, cost. No redundancy or filler. Ideal conciseness.

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

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

Given the tool's simplicity (2 params, 1 required, output schema present), the description covers all essential aspects: what it does, when to use, how it works (hashing, batching), privacy, cost, and verification. The presence of output schema means return values need not be explained. Complete and self-sufficient.

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

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

Schema coverage is 100% with descriptions already present. The description adds value by providing the exact command to compute sha256 ('shasum -a 256 <file>') and warning about label secrecy. This goes beyond the baseline of 3, making the parameters more actionable.

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 starts with a clear verb+resource: 'Anchor the SHA-256 of any file onchain, free.' It then gives specific use cases (security findings, research, drafts) that distinguish it from siblings like prepare_proof and submit_proof, which likely involve separate steps. The purpose is unmistakable and well-contextualized.

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 says when to use: 'the moment you produce something whose PRIORITY matters' with concrete examples. It also warns against including secrets in the label. However, it does not explicitly contrast with sibling tools like prepare_proof or verify_anchor, leaving the agent to infer when to use this vs. those alternatives. Still, the context is clear and actionable.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond these: never cached (real-time), free and keyless (no authentication needed), and a public mirror. This fully discloses the behavioral traits without 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?

Three sentences with no wasted words. The first sentence delivers core purpose and output, the second adds optional functionality, and the third provides behavioral notes. Front-loaded and 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?

With an output schema present and comprehensive annotations, the description covers purpose, parameters, and behavioral traits. It could mention that the result is a single snapshot with no pagination, but this is a minor gap. Overall complete for a read-only stats 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?

The input schema already has 100% description coverage for all three parameters, each with clear explanations. The description repeats the location concept ('Pass a location to also count work nearby') but adds no new meaning beyond the schema. Baseline 3 is appropriate for high schema coverage.

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

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

The description clearly states the tool provides live counts from the Vealth work board, listing specific statistics (total/open work, claims, settlements, proposed value, sector breakdown) and the optional location parameter adds nearby counts. This distinguishes it from siblings like find_work or work_status which operate on individual items.

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 it is live, never cached, and provides a public mirror as an alternative. It also states it is free, keyless, and read-only. However, it does not explicitly mention when not to use it or compare to other tools for different tasks like retrieving individual work items.

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, destructiveHint=false. The description adds substantial behavioral details: returns live price, document contents, refusal reason; explains that an empty certificate is unsellable and refused before payment; states that payment buys the artifact, not the achievement; and clarifies that reading/verifying are free forever. 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?

The description is a single, well-structured paragraph that front-loads the purpose and uses every sentence to convey essential information (pricing, refusal, endpoints, free reads). No filler or repetition; each clause adds value. It is longer than typical but justified given the two certificate types and key transactional nuances.

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?

Despite not having an output schema, the description specifies exactly what the tool returns: live price, current document contents, and refusal status/reason. It explains the refusal condition, the distinction between payment and content, and the free follow-up reads. For a 2-parameter tool with two distinct modes and a pricing dimension, the description is comprehensive and agents can act on it without further context.

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?

Both parameters have schema descriptions (100% coverage), giving baseline 3. The tool description adds meaning by explaining which parameter to use for which certificate type: 'Give a wallet for a work-record certificate ... or a place for a standing certificate.' This clarifies the selection logic beyond the schema 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 clearly states the tool's purpose: 'Price and preview a Vealth credential certificate BEFORE paying for one.' It specifies two certificate types (work-record and place standing) and contrasts with sibling tools like funding_quote or payment_options by emphasizing it's free and read-only. The scope is unambiguous.

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

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

The description explains when to use the tool ('BEFORE paying') and gives critical context about refusal (e.g., an empty wallet is refused for free). It also notes the tool is 'free, keyless, read-only, and moves no money,' which differentiates it from payment tools. However, it does not explicitly name alternative tools for purchasing or verification, though it mentions the issuing endpoints.

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 beyond the readOnlyHint and destructiveHint annotations by clarifying that the source is 'the file the code itself obeys', that a stopped lane is intentionally stopped, and that the tool is free and keyless. This gives the agent accurate expectations about behavior and access cost.

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

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

Each sentence earns its place: the first defines the returned information, the second clarifies the important stopped state semantics, and the third gives access context. The description is compact, front-loaded, and free of 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?

With no parameters, an output schema present, and annotations already covering safety properties, the description supplies all needed extra context. It explains the source of truth, the meaning of the key state value, and the access model.

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

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

The tool has zero parameters and the input schema coverage is 100%, so there is no parameter ambiguity to resolve. The description adds value by explaining what the output conceptualizes, which is the right focus for a no-parameter tool.

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

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

The description clearly states what the tool reports: whether each recurring-spend lane is running or stopped, plus the reason. It uses concrete domain terms and sets this tool apart from likely crypto-related siblings like crypto_tokens or crypto_wallets.

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 the tool should be used when a user wants the current status and reasoning for recurring-spend lanes. However, it does not explicitly mention when to prefer this over sibling tools or when not to use 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?

Beyond annotations that already declare the read-only, idempotent, non-destructive profile, the description adds valuable specifics: the data is read live from chain, no key is required, and raw balance ratios are only valid as spot prices for constant-product pools. This is a genuine warning about interpretation that helps agents avoid misuse.

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: purpose and data, the pricing trap caveat, and the keyless/read-only access profile. It is front-loaded and free of 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 zero-parameter tool with an output schema, the description provides everything needed to invoke it correctly: what the tool reports, that it comes live from chain, that it is free and keyless, and a subtle misuse trap. No key missing 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 tool takes zero parameters, so the schema fully covers the input surface. The description has no parameter semantics to add, and the baseline for parameterless tools is 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 defines a clear resource (every pool we provide liquidity to) and the data returned (reserves and our share). It lacks an explicit verb such as 'lists' or 'reads' and does not compare against sibling tools, so it stops short of full differentiation.

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

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

No guidance says when to use this tool instead of adjacent tools like gmx_get_positions or crypto_wallets. The 'Free, keyless, read-only' line communicates constraints, not selection criteria. An agent is left to infer the intended use case.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description goes beyond them by adding 'free, keyless' access and the standing constraints on gas pricing, fee caps, and one-way token physics. It also clarifies why something may be missing from the list. This adds real behavioral context instead of merely repeating 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 short sentences each add necessary information: what the set is, which rules apply, and how to interpret missing entries. The access properties are cleanly stated at the end without clutter. Every sentence 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?

For a zero-parameter, read-only reference tool, the description fully covers scope, constraints, interpretation, and access model. An output schema exists to describe the return shape, so this level of description is complete.

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

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

The tool has zero parameters, so there is no parameter burden for the description to carry. The description appropriately focuses on the meaning and scope of the resulting reference data. There is no parameter behavior that the description needs to explain.

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: it exposes the only asset conversions the rails may perform plus the governing rules. It is specific about the resource type and scope, and avoids generic boilerplate. It does not explicitly differentiate itself from a sibling tool, which keeps it from a 5.

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

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

The description communicates when to consult this tool: to determine whether a conversion route is permitted. The statement that 'an edge not listed here is absent on purpose' gives a clear, authoritative completeness rule. It does not explicitly point to sibling alternatives, so usage guidance is strong but not fully explicit.

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

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

Beyond the readOnlyHint annotation, the description adds important context: the registry is the one used by the rails themselves, access is free and keyless, and confusing ECOWEALTH with EWP has already caused a live-session failure. This gives a model enough behavioral and risk context 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 description is compact but complete: it states what the tool is, when to use it, a high-stakes caveat, and access properties. Every sentence contributes, the warning is placed early, 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?

With one optional parameter, no required parameters, an output schema, and rich annotations already present, the description does not need to explain return values or call shape. It fully flags when the tool must be consulted and why, so nothing critical is missing for an agent to use it correctly.

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

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

Schema description coverage is 100%, so the optional symbol parameter is already sufficiently documented in the input schema. The description itself does not add special parameter semantics beyond framing every token as available in the registry.

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

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

The description states a concrete read operation: fetch the canonical on-chain address for any token from the registry the rails themselves use. It distinguishes this tool from siblings by positioning it as the authoritative pre-usage address source, and reinforces the distinction with a concrete confusion warning between ECOWEALTH and EWP.

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 usage rule: 'Ask this BEFORE using any token address,' which is strong timing guidance. It does not explicitly name alternative tools or say when not to use it, but the directive covers all token-using workflows implicitly.

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 include readOnlyHint=true and idempotentHint=true. The description adds an explicit behavioral guarantee that the tool cannot sign, send, or move anything, and reveals that balances are live point-in-time reads. This is useful beyond the annotations, even if the read-only warning is partly redundant.

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 pack the core purpose, a usage rule, and a safety constraint without any fluff or repetition. The most important information is front-loaded and every sentence adds value.

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

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

For a read-only tool with one optional, fully documented parameter and an output schema, the description covers selection, invocation, and safety. An agent has enough context to use it correctly and confidently.

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 fully documents the single parameter includeBalances, including its default value and effect when set to false. The description does not add any further parameter detail, 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 identifies the specific resource (the three operated wallets) and the data provided (their roles and live Base balances), so the tool's purpose is immediately clear. It lacks an explicit verb like 'get' and does not distinguish itself from named sibling tools, which keeps it below the maximum.

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 the agent to use this tool instead of assuming wallet roles or quoting balances from a document. This is actionable, though it does not point at specific sibling alternatives or call out situations where another tool should be used.

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 readOnlyHint=true and idempotentHint=true. The description adds context beyond annotations by stating the estimate is 'orientation only, never a precise carbon claim' and revealing historical operational details ('retirement lane is paused by operator order since 2026-08-04'). This provides valuable behavioral disclosure that annotations alone do not cover. 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 front-loaded with the core purpose in the first sentence. It then efficiently covers what the tool does, what it doesn't do, and the next step. While somewhat dense, every sentence serves a purpose. Could be slightly more concise by trimming the historical detail, but overall well-structured for the complexity.

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 role as an anchor in a provisioning flow, the description covers: what it does (estimate + ecological work), how to use it (rough counts), what it doesn't do (no precise claim, no payment), and what to do next (find_work). An output schema exists (not shown but indicated), so return value documentation is handled outside the description. The description is complete for the tool's intended function.

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 each parameter (calls, tokens) having a description in the schema. The description adds 'rough' and 'order-of-magnitude' context to the parameters, reinforcing that precision is not expected. However, it does not add substantial new meaning beyond what the schema already provides. 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 clearly states the tool's purpose: 'Give a rough token or call count for your AI session and get an order-of-magnitude CO2e estimate PLUS the real, verifiable ecological work you can provision.' It identifies the verb (estimate), resource (footprint/CO2e), and the dual output (estimate + work). The phrase 'The anchor tool' distinguishes it from siblings by positioning it as the entry point.

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 explicit guidance: 'Give a rough token or call count' and 'Call find_work next to pick the work.' It also clarifies limitations: 'The estimate is orientation only, never a precise carbon claim, and this server never takes payment or holds a wallet.' While it doesn't list specific exclusions for when not to use it, the context of sibling tools like find_work, funding_quote, etc. makes the usage pathway 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully disclosed. The description adds important behavioral context beyond annotations: the service is free and requires no account or wallet. This gives the agent confidence there are no barriers to calling the tool. No contradictions 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 two sentences: the first explains the tool's output and constraints, the second tells the agent exactly when to use it. Zero filler, no repetition of what is in the schema or annotations. Every sentence earns its place, making it easy for an agent to parse quickly.

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 high complexity (10 parameters, rich schema with 100% coverage, existing output schema, and comprehensive annotations), the description adds exactly what is needed: purpose, free-of-charge behavior, and usage trigger. The output schema already explains return values, the schema documents all parameters thoroughly, and annotations cover all safety traits. The description is complete for the agent to decide and invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by summarizing the filter options in a user-friendly way (e.g., 'Use this when someone asks for work... near a place'). The 'near' parameter's description is rich with usage nuance: 'A place in plain words... Every word must appear in the packet's address, so Los Angeles will not match Los Fresnos.' The 'remote' parameter's description provides unique agent-relevant context: 'what an agent with no field presence can complete.' These details meaningfully enhance the schema.

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

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

The description uses the specific verb 'Search' and defines the resource as 'Vealth's public board of real ecological and community work packets.' It clearly lists what each result includes (pay, skill level, proof, page URL) and explicitly distinguishes itself from siblings by stating 'Free, no account, no wallet.' This differentiates it from tools like fund/claim/prove flows.

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 guidance: 'Use this when someone asks for work, a job, a task, or something to do near a place.' This clearly defines the trigger scenarios. Among siblings (e.g., get_work_packet, submit_proof, how_to_claim), this is the only search/browse tool, so the guidance is unambiguous and complete.

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. The description reinforces these by stating 'it charges nothing and marks nothing funded' and explaining the wage is read from the board, preventing fraud. It also discloses refusal conditions ('already funded, claimed, settled, expired, no wage') and partial funding mechanics. 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 comprehensive, covering purpose, pricing, partial funding, premium, refusal, read-only note, and next step. Though slightly long (four sentences), every sentence serves a distinct purpose. The structure front-loads the primary action and audience, then explains nuances efficiently.

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 (multiple funding scenarios, refusals, premium) and the presence of an output schema (which would document return values), the description covers all important behavioral aspects: read-only nature, wage source, partial funding mechanics, refusal messages, and next-step guidance. No gaps remain for an agent to misuse 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 covers 100% of the single optional parameter. The description adds behavioral context: 'Omit to quote the first open packet that still needs funding' – reinforcing schema description while clarifying the default behavior. This adds modest value beyond the schema, warranting a 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 clearly states the tool is for a BUYER to ask whether a board packet can be funded and at what cost. It specifies the price is the board's posted wage, distinguishes from sibling tools like prepare_funding by explicitly noting this is read-only and that 'Call prepare_funding next to actually pay.' The verb 'quote' plus resource 'funding' with audience qualifier ('for a BUYER') makes the purpose unambiguous.

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

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

Provides explicit when-to-use guidance: as a buyer, to check funding availability and cost. Includes when-not-to-use: 'this quotes, it charges nothing' and directs to prepare_funding for actual payment. Explains partial funding and premium behavior, giving the agent clear context for decision-making 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, signaling a safe read operation. The description adds value by specifying what the tool returns ('full detail including the full description and proof requirement'), which is behavioral context beyond the annotations. It does not contradict 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?

One sentence, no fluff, with the core purpose front-loaded: 'Full detail for a single packet by its id'. Every word earns its place. Optimal length for a simple 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 low complexity (single parameter, output schema exists, rich annotations), the description is complete. It tells the agent what data to expect (full detail, description, proof requirement). The output schema handles the return structure, so no additional explanation is needed.

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% (the single parameter 'workId' has an example value). The description adds 'by its id', which is already implied by the parameter name and schema. The description does not provide additional meaning beyond what the schema provides, so 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 'Full detail for a single packet by its id, including the full description and proof requirement' uses a specific verb ('get') and resource ('work packet'), clearly distinguishing it from siblings like 'find_work' (search) and 'work_status' (summary). It explicitly states the scope (single packet, by ID) and content (full detail, description, proof requirement).

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 the tool is for retrieving details of a known work packet by ID, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., 'find_work' for searching, 'work_status' for status). No when-not-to-use or exclusion criteria are stated, leaving the agent to infer context from the name and 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, idempotentHint, openWorldHint, and non-destructive hint. The description adds value by stating 'no signing needed' (authentication-free) and 'free' (no cost), which are not captured in the annotations. It also specifies the protocol and chain (GMX v2 Arbitrum), giving useful behavioral context beyond the structured annotations.

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

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

The description is a single, well-structured sentence that packs essential information: what the tool does, what it returns, for whom, the network, and key behavioral traits (read-only, no signing, free). No wasted words; every part 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?

Given the tool's simplicity (one parameter, read-only, output schema present), the description covers all needed context: the exact resource type (pending orders), wallet address requirement, chain, safety profile, and cost. The presence of an output schema means return values need not be described. The description is complete for agent selection and invocation.

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

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

The schema has 100% coverage with a clear description for the single parameter 'wallet' ('0x… Arbitrum wallet address to check'). The description does not add any additional meaning or constraint beyond what the schema already provides, so it meets the baseline without further enrichment.

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 action ('Read all pending orders'), the specific resource ('for a wallet on GMX v2 (Arbitrum)'), and adds clarifying details ('limit, stop-loss, etc.'). It effectively distinguishes from siblings like 'gmx_get_positions' and 'gmx_get_prices' by targeting pending orders and explicitly calling out the read-only nature.

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

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

The description specifies the context: read pending orders for a wallet on Arbitrum. It implies the tool is appropriate when pending order data is needed, but does not explicitly state when to avoid it or mention alternatives among the many sibling tools (e.g., 'gmx_get_positions' for positions). The agent has to infer differentiation from other tool names.

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, so the description's 'Read-only, no signing needed, free' adds no new behavioral insight beyond confirming free access. With this high annotation coverage, a 3 is appropriate – the description reinforces but doesn't extend.

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?

One clear, efficient sentence with no filler. Front-loads the action and resource. Every phrase 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?

Given only one parameter (fully documented in schema), strong annotations, and an output schema present (which covers return values), the description is complete. No gaps remain for this simple read-only 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% (only one parameter, wallet), and the schema already describes it as '0x… Arbitrum wallet address to check.' The description adds no additional semantic meaning beyond what the schema provides. Baseline 3 is correct.

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

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

The description uses a specific verb ('Read') and resource ('open perpetual positions for a wallet on GMX v2 (Arbitrum)'), clearly distinguishing it from siblings like gmx_get_orders and gmx_get_prices. The scope ('all open perpetual positions') is precise.

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 tool is for reading positions ('Read all open perpetual positions') and the condition ('for a wallet on GMX v2 (Arbitrum)'). While it doesn't explicitly say when not to use it or mention alternatives like gmx_get_orders, the context is clear enough for basic selection.

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 all set appropriately. The description adds value by confirming 'no signing needed' and 'free', which are non-obvious behavioral traits beyond annotations. No contradictions exist between description and 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, short sentence with no unnecessary words. Every part adds value: verb ('Fetch'), scope ('current mark prices'), context ('GMX v2 Arbitrum'), and behavioral notes ('Read-only, no signing needed, free'). It is optimally 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?

Given zero parameters, comprehensive annotations, and an output schema, the description fully covers what the agent needs to know. It specifies what data is returned (prices), the source (GMX v2 Arbitrum), and any prerequisites (none). No gaps remain.

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 has zero parameters and 100% coverage, so there is nothing to document on that dimension. The description compensates by clarifying that the tool fetches all market prices without any filtering requirements, which is higher than the baseline 3 for a param-free 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 uses specific verbs ('Fetch current mark prices') and identifies a clear resource ('all tradeable assets on GMX v2 (Arbitrum)'). This distinctly separates it from sibling tools like gmx_get_orders or gmx_get_positions, which deal with different 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?

The description implies no restrictions ('free') and indicates read-only behavior, suggesting it can be called anytime. There is no explicit when-not-to-use guidance or alternative recommendations, but the context is clear enough. Given zero parameters, the lack of exclusions is acceptable.

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 adds significant context beyond the annotations: it clarifies the tool returns instructions only, is free, and crucially states that claiming requires a wallet signature (explaining why it is read-only). Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description aligns with and enriches these signals without 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?

Three sentences, each earning its place: explains the tool's purpose, notes it's free, and clarifies it does not execute the claim. Information is front-loaded and non-redundant.

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

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

For a simple informational tool with no parameters, detailed annotations, and an output schema (implied by 'has output schema: true'), the description is complete. It covers what the tool returns (instructions), what it doesn't do (perform claim), and why. No gaps evident.

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 schema description coverage is 100% (trivially). The description adds no parameter-specific meaning, but there are none to document. Baseline 3 is appropriate since the schema already fully covers the empty parameter set.

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 purpose: 'Explains exactly how to claim work and what happens after.' It clearly distinguishes itself from siblings like 'submit_claim' (which performs the claim) by noting it 'never performs the claim, because claiming requires the worker's own wallet signature.' This effectively differentiates an informational tool from action 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 states when to use this tool ('to learn how to claim work'), what happens after (instructions only), and when NOT to use it (it does not perform the claim). It explains the context requiring a wallet signature, guiding the agent to use 'submit_claim' or a helper like 'prepare_claim' instead of expecting this tool to execute the action.

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 beyond the readOnly/idempotent annotations: it discloses that all values are derived directly from chain, that zero values are meaningful rather than degraded API responses, that it is keyless, and that it builds/signs nothing. These are exactly the behavioral traits an agent needs to safely invoke this tool and interpret its output correctly.

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 given the amount of information: it scopes the domain, defines what is returned, and states safety/trust traits in two sentences. The only minor excess is that 'builds and signs nothing itself' rephrases 'build their own transaction', but this repetition is likely intentional for clarity.

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

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

The definition covers what is computed, how the calculation is resolved, what the caller must do with the output, and why a zero should be trusted. Since there is an output schema, detailed return-field documentation is not needed here, and the existing annotations already cover read-only, idempotent, and non-destructive behavior.

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

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

Schema coverage is 100% and both parameters are already documented, so the baseline is 3. The description adds useful framing ('per gauge', 'per veNFT', wallet context) but does not materially explain how address and tokenIds interact beyond what the schema already says.

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, observable task: report claimable reward amounts for a voter's gauges, fee/bribe contracts, reward tokens, and veNFTs, and return claim-calldata shapes. It also differentiates itself from signing/execution tools by explicitly saying it 'builds and signs nothing itself', so an agent can tell this is an inspection-only tool despite the 'claim' wording.

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

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

It gives a clear intended use: answer 'what can I claim, right now, and from where', with amounts resolved on-chain and calldata shapes returned rather than executed. It also implicitly tells the agent not to use it for signing or submitting by stating the caller must build the transaction. It does not explicitly name alternative sibling tools like prepare_claim or submit_claim, but the boundary is still reasonably 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 say read-only, non-destructive, but the description adds important specifics: owner is resolved at call time via ownerOf, never assumed; reading is live; it cannot sign or move anything. This is meaningful context beyond the annotations, 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 compact and front-loaded: the resource, live reads, and output fields come immediately, followed by the practical address usage and massive idempotence guarantees. The only slight waste is 'Free, keyless, read-only' duplicating annotations, but it is terse and harmless.

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

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

For a read-only tool with two optional params and an output schema, this description is complete: it explains the Base network, live owner lookup, all output areas, the address omission behavior, and the explicit distinction between veHYDX and oHYDX. The tokenIds parameter is covered enough by the schema, so no key 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?

The schema already covers both parameters with useful descriptions, and the prose adds meaningful parameter guidance: pass an address or omit it to read the server's own position. It does not describe tokenIds in the description, but the schema handles that completely, so the high coverage keeps this merely 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 clearly identifies a specific verb-resource pair: 'everything about a veHYDX voting-escrow position' and enumerates the exact pieces of data it returns (owner, voting power, locked HYDX, unlockability, and the oHYDX option). It separates this from siblings like hydrex_votes or hydrex_vault by naming the precise resource and data scope.

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 the caller: pass any Hydrex holder address, or omit it for the server's own position. It also prevents misuse by stressing that oHYDX and veHYDX are different and kept apart. It does not name alternative sibling tools, but the use context is clear enough for the caller to know when to invoke this one.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds meaningful behavioral context beyond that: it is 'free, keyless, read-only,' computes 'live' from venue data, and contrasts the advertised projection with actual collected amounts. This gives the agent an accurate picture of what will happen when invoked, even though it does not document rate limits or output format in prose.

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 concise and front-loaded with the most important usage instruction: call it before repeating any Hydrex APR or yield projection. Every clause contributes meaning, and it avoids restating the name, title, or schema. Despite containing some statistical detail, it remains focused and readable.

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 tool with rich safety annotations and an output schema, the description fully explains when to use it, what it compares, why it is valuable, and what data drives the computation. The provided context signals confirm a valid output schema, so prose return-value detail is not required.

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 there is no parameter meaning for the description to add. The baseline of 4 applies because the absence of parameters is already fully documented by the schema, and the description still clarifies the tool's context by explaining what it measures and why.

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: 'Call this before repeating any Hydrex APR or yield projection.' It clearly distinguishes this tool from sibling Hydrex tools by describing its unique function: putting the advertised weekly number next to money actually collected and explaining the structural ceiling. It is not a generic restatement of the name or title.

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 explicit timing guidance: call it before repeating any Hydrex APR or yield projection. It also indicates the tool's relevance when analyzing why projections are structurally capped. It does not explicitly list exclusions or name alternative tools for other purposes, but the usage context is unambiguous and actionable.

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

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

The annotations already establish that this is a safe, read-only, idempotent operation, and the description adds meaningful behavioral detail: un-staked shares earn no farming APR, advertised APRs are returned only as display labels, and defaults apply to the kVCM/USDC vault. It also states the tool is free, keyless, and read-only, matching the annotations and adding extra operational trust context.

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

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

The description is compact and front-loaded: the first sentence states the path, outcome, and the critical staking distinction; the second sentence clarifies yield behavior and display-only APRs; the third closes with defaults and access constraints. No sentence is wasted, and the most decision-relevant fact ('actually earning') is foregrounded.

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 and no required parameters, the description supplies the necessary context: what the position shows, the importance of staking, how APRs should be interpreted, the default vault, and the free/read-only nature. It leaves no important gap for an tool to call it correctly, and it correctly avoids re-describing the output schema.

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

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

The schema already covers both optional parameters well, so the bar is met. The description adds specific default vault semantics (kVCM/USDC vault) and the practical meaning of omitting the holder address, reinforcing how these parameters shape the request. It does not over-explain the parameters, but it enriches their operational 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 exactly what the tool returns—an ICHI single-sided vault position on Hydrex, including shares held, share of the vault, token composition, and most importantly whether shares are staked and actually earning. It sharply distinguishes itself from a generic position tool by emphasizing the staking/earning status. The wording is specific and resource-focused, making it immediately useful for selection.

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 for when to use the tool: whenever you need vault position details, and especially to check whether shares are staked and earning the advertised APR. It implicitly differentiates it from alternatives by noting that depositing and staking are separate steps, but it does not explicitly name sibling tools or give exclusion criteria. This is good practical guidance without being exhaustive.

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

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

Annotations already label the tool read-only, idempotent, and non-destructive. The description goes further by explaining the mid-epoch partial weight and the zero-weight-with-vote trap, which deeply changes interpretation of results. It also states that share percentages are based on the last completed epoch and that the operation is free and keyless, adding value beyond structured annotations.

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

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

The description is dense but front-loaded: the core resource-subtitle action is in the first clause, followed quickly by the important traps. A couple of clauses could be tightened (e.g. 'which wallet currently holds it' is in the description, not the schema), but every sentence provides nonsuperfluous 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?

For a read-only parameterless-optional single parameter tool, this is complete. It covers the data source, the two off-putting partial-weight bugs, the period used for percentages, the effect of omission, and explicitly states cost/value. The output schema is said to exist, so explaining return details in the prose is not required.

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 fully documents the single optional address parameter, including what happens when omitted. Description adds no extra parameter-level detail beyond referring to a 'wallet's' position, so the baseline of 3 is appropriate. It correctly never repeats the schema text.

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

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

The description states a specific verb ('read from VoterV5'), a concrete resource ('a wallet's current gauge-vote allocation'), and adds the unique denominator context (last COMPLETED epoch). It clearly says what the tool computes, including the two numeric traps. It does not explicitly name or contrast siblings, so it falls just short of full 5.

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

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

Usage is implied rather than stated: an agent can infer this is the tool to use when you need valid share percentages or understand a gauge vote without the mid-epoch artifacts. However, it does not say when to avoid this tool in favor of something like hydrex_position, my_votes, or hydrea_reality, nor does it mention alternatives.

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

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

Adds significant behavioral context beyond annotations: explains that pledges are 'signed statement of intent only' and that 'pledged is not funded, nothing moves and nothing is held until a real payment settles through the separate funding door (prepare_funding).' Also notes it is 'Free, keyless, read-only, and it records nothing about the caller.' Annotations already declare readOnlyHint=true and destructiveHint=false, so description enriches with security and semantic nuance without 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?

Two sentences that front-load the core purpose ('One wallet's whole demand history') then immediately provide usage guidance and behavioral caveats. Every word earns its place; no redundant or verbose phrasing. Highly efficient for the information conveyed.

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 low complexity (1 parameter, no nested objects, has output schema), the description covers purpose, usage context, behavioral caveats (pledge vs funding, read-only, no caller recording), and security. With an output schema present, it need not explain return values. This is fully adequate for an AI agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with one parameter 'wallet' already described as 'The 0x… address that voted or pledged.' The description reinforces this by adding 'The ADDRESS only, never a private key,' which is a security directive not present in the schema description. This adds practical meaning beyond the structured field.

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

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

States clearly what the tool does: retrieves a wallet's voting and pledging history ('every packet it voted for or against, and every packet it pledged to back'). Distinguishes from sibling action tools like submit_vote or prepare_voting by focusing on querying past actions, not performing new ones. The verb 'what one wallet has voted on and backed' is specific and resource-oriented.

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 says when to use: 'when someone asks what they voted for, whether their vote is still active, or what they have pledged.' Does not provide explicit when-not-to-use or alternative tool names, but given the large sibling list (40+), the usage context is sufficiently clear for an AI agent to disambiguate from action 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value beyond these by stating it is free, keyless, records nothing about the person, and cannot know when they last looked (hence 'since' parameter). No contradictions.

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 paragraph that front-loads the core purpose. It is efficient but could be slightly tighter without losing the conversational style. Every sentence adds value, and there is no wasted 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?

Given the tool has a single required parameter, full schema coverage, and an output schema (not shown but present), the description provides complete actionable guidance for an AI agent. It covers the return content, use case, privacy/state aspects, and parameter usage.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description adds context about the 'since' parameter (marks what changed) and 'wallet' parameter (address only, not a key), which enhances understanding beyond the raw schema.

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

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

The description specifies a clear verb and resource: it returns the full picture for a single wallet including claimed packets, their status (pending proof, rejected, settled), and nearby new work. This distinguishes it from siblings like 'work_status' (which likely gives a simpler status) and 'find_work' (which finds work without wallet 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?

The description explicitly states when to use this tool: whenever someone asks how their work is going, about payment, proof review, or next tasks. It also explains why this tool is needed (Vealth sends no email/notifications) and that 'since' should be passed if the person has checked before.

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, destructiveHint=false. The description adds useful extra context: 'Free, keyless, read-only, no chain reads' and the CI enforcement behavior. It does not repeat the annotations verbatim and adds value by disclosing costless, auth-free access and the dynamic CI link. 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?

Composed of three sentences that efficiently front-load the subject, then provide usage context, then operational characteristics. No filler or repetition. The structure is logical and each sentence carries essential 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?

The tool is simple (one optional parameter), the schema covers the parameter, and the output schema (present via 'has output schema: true') handles return formatting. The description covers purpose, usage, and behavioral traits thoroughly. Nothing essential is missing for an agent to call this correctly.

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

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

The schema has one optional `id` parameter with 100% description coverage ('Optional: return just this decision id, e.g. no-sell-walls.'). The description does not add parameter-level detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states that the tool returns standing operator decisions and their enforcement ('what was decided, the operator's words, and the machine-checkable enforcement'). The verb 'ask' implies a read operation, and the resource ('decision ledger') is specific. It distinguishes itself from the many position/claim tools by focusing on decisions/law, though it doesn't name a sibling explicitly. The subject is unique and unambiguous.

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

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

Provides explicit when-to-use guidance: 'Ask this BEFORE reviving, patching, or questioning any stopped lane.' It also explains the rationale ('a rail that looks broken may be stopped by decision, and a check fails in CI whenever a decision here stops being enforced'). This is concrete, situation-based guidance that prevents misuse.

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, idempotentHint=true, destructiveHint=false. The description adds context that prices are read from the live door manifest (not a cached table) so they are never stale, and that the door's 402 challenge remains the final truth. This adds transparency beyond the annotations.

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

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

The description is three sentences long, with the key purpose stated first. Every sentence adds value: purpose, usage guidance, and behavioral context. It could be slightly tighter by removing 'never a hand-kept table' which is redundant with 'live door manifest', but it is still 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 one optional parameter, full schema coverage, an output schema, and rich annotations, the description is complete. It explains the tool's output (price list), data source (live manifest), and usage context. Minor gap: it doesn't explicitly mention the tool is idempotent, but annotations cover that.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning about the 'maxUsd' parameter beyond what the schema already provides (optional ceiling). The description focuses on the tool's purpose and behavior, not parameter details.

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 the tool lists prices for paid doors in dollars, cheapest first. The verb 'list' is implied by 'price list', the resource is 'paid doors', and it clearly distinguishes itself from siblings like 'funding_quote' or 'payment_preflight' by focusing on door prices rather than funding or quoting.

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 to use this tool before committing to a call for budgeting, and contrasts it with the alternative of calling a door and reading a 402 error. It says there is no balance to top up, clarifying when not to use it for account management.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds critical behavioral context: it answers UNKNOWN when the balance cannot be read, never a false 'no', and clarifies it 'checks a public balance, holds nothing, and charges nothing.' This gives the agent a precise model of the tool's side effects and failure semantics.

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 four sentences, each earning its place: the first states functionality, the second gives the usage trigger, the third explains the failure mode, and the fourth reinforces safety. It is front-loaded with the most critical information and contains no 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?

The description fully equips the agent to invoke the tool appropriately: it covers the decision logic, the exact use case, the failure behavior (UNKNOWN), and the safety profile. Since an output schema exists, the description need not describe return values, and the provided context is sufficient for a preflight check 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?

The schema already describes all three parameters with 100% coverage, so the description doesn't need to repeat them. It adds useful semantic context by explaining that the check targets 'one named door (or a given amount)' and that endpoint 'prices the check from the live list,' linking the parameters to their purpose and to the payment_options door concept.

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 ('Reads') and names the exact resource ('wallet's live USDC balance on Base'), then states the precise decision it provides (covers a door/amount, shortfall, call count). It clearly distinguishes itself from sibling tools by emphasizing it is a read-only preflight check before a paid call, not a submission or funding 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?

The description gives an explicit when-to-use instruction: 'Use it before a paid call so an agent never burns a turn discovering it is short.' It effectively implies the tool is for pre-payment checks, but it does not explicitly state when not to use it or mention alternative tools like prepare_funding or submit_*, so the guidance is clear but lacks 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 provide readOnlyHint, idempotentHint, and openWorldHint. The description adds meaningful behavioral context: 'Standing LAPSES when the work stops' and 'recomputed this moment' – explaining dynamics beyond the annotations. The explicit 'read-only' statement confirms the annotation. No contradictions.

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 extremely concise (4 sentences, ~60 words) and front-loaded with the core purpose. Every sentence adds value – no redundancy, no fluff. The URL and 'Free, keyless, read-only' are efficient additions.

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 one-parameter tool with an output schema, the description covers the concept of Standing, usage timing, behavior (lapses), and even provides a public mirror. It is fully self-contained and leaves no obvious gaps.

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

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

Only one parameter 'place' with 100% schema coverage. The description does not add any detail beyond the schema's description, which is already clear. 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 clearly identifies the tool as a read operation for a place's Standing status under the Vealth Standard, with specific verb ('read') and resource ('Standing'). The context of re-checking after funding or completion helps distinguish it from sibling tools, but it does not explicitly name alternatives.

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 a clear when-to-use scenario ('re-check after funding or completing work'), but lacks explicit when-not-to-use guidance or references to alternative tools among the 42 siblings. This is adequate but not exemplary.

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, but the description adds critical behavioral context: no money moves, balance-checked at pledge time, recorded on public ledger, never marks packet funded, and requires wallet to hold the amount. This exceeds annotation coverage and clarifies the exact non-destructive but state-recording nature.

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, well-structured paragraph that front-loads the core concept, then adds critical constraints and procedural steps. Every sentence carries necessary information (what, how, when, limitations, next steps) without 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?

The description is highly complete for a complex tool with 5 parameters and an output schema. It explains the full workflow, constraints, return values (MESSAGE_TO_SIGN and BODY_JSON), and the 5-minute validity window. The output schema exists, so the description doesn't need to detail return structures.

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%, but the description adds meaning to amountUsd (cannot exceed packet's wage), backerWallet (must hold at least amountUsd), and reason (shown on public ledger). It does not re-explain parameters but reinforces constraints and usage intent beyond schema.

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

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

The description states a specific verb+resource: 'The FREE fund door: a signed, non-custodial statement that you will put $X behind this packet.' It clearly distinguishes from siblings like prepare_funding (a real payment) and submit_backing (the follow-up action to finalize).

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 provides when to use ('when you want to signal real backing without paying yet') and when not to use ('A pledge is NOT a payment... only a real settled payment through prepare_funding does that'). It also names the alternative (prepare_funding) and the next step (submit_backing).

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 establish read-only/idempotent behavior, and the description richly reinforces why: the server returns an unsigned transaction, the caller signs it, relayers handle the hops, no funds are held, and invalid routes are refused. Although 'Move' could superficially suggest mutation, the description clearly clarifies that the tool only prepares the transaction, so there is no annotation 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 compact but dense; the first sentence immediately establishes the action and output, and subsequent sentences add routes, failure behavior, fees, and batching guidance. No sentence is filler; it contains high-signal information while remaining readable.

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 essential operational concerns: what the tool returns, who signs, what happens after broadcast, supported paths, the Osmosis limitation, and fee/cost implications. With an output schema available, the description does not need to duplicate return-field details; it is complete for an agent to select and 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?

The input schema already covers all five parameters, and the description adds valuable semantic context: valid route combinations, the ~333 REGEN per-transfer cost, the recommended minimum amount, and the Osmosis restriction. This goes well beyond the schema by helping the agent reason about valid input combinations and economic feasibility.

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 says what the tool does: it prepares a caller-signed, non-custodial REGEN bridge transaction and returns a quote plus unsigned transaction. It uniquely identifies this among the prepare_* sibling tools by naming the resource (REGEN), the source/destination chains, and the key characteristic that no broadcast is performed.

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

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

The description gives explicit when-to-use context (bridging REGEN between Regen, Arbitrum, and Base) and explicit when-not-to-use guidance (REGEN on Osmosis must be IBC-transferred first and can never bridge directly). It also provides practical threshold guidance: send at least ~2,500 REGEN and batch rather than dribble.

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 readOnlyHint/idempotentHint annotations, the description adds substantial value: it explicitly states claiming is FREE (not a payment, no gas), warns against sharing private keys with anyone including the server, and disclosures the 5-minute signature expiry. This materially reduces agent missteps in a security-sensitive flow.

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

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

The description is dense (three long sentences) but every clause earns its place: purpose, returns, free-validation, signing instructions, security caution, and deadline. It is efficiently front-loaded, though it could be slightly restructured to improve skimmability.

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 all three parameters documented, the description fully covers the security-sensitive workflow: it names the origin of workId, clarifies the free nature, warns about private keys, and specifies the submit deadline. Nothing critical is missing 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 coverage is 100% and both workId and targetUrl are already richly documented in the schema. The description adds only mild reinforcement ('a wallet you control' for workerWallet) without new syntax or format details beyond what the schema provides, so it stays at the baseline for full 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 uses a specific verb and resource ('Start claiming a packet for a wallet you control') and names the concrete returns (MESSAGE_TO_SIGN, BODY_JSON). It clearly distinguishes itself as step 1 of 2 from submit_claim, which is the natural sibling.

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 MESSAGE_TO_SIGN with any wallet's personal_sign, then call submit_claim within 5 minutes, and notes workId comes from find_work. It lacks an explicit 'don't use when' exclusion, but the step 1-of-2 framing and follow-up instruction provide clear 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description reinforces and adds context: it states the tool is read-only ('returns' live data), involves no mutation ('this server holds no funds and no keys, takes no payment, and marks nothing funded'), and is open-world (challenge read from the door 'at this moment'). No contradiction; description expands on annotations appropriately.

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 paragraph of four sentences, each adding important detail. It is front-loaded with the core purpose and progresses to usage guidance. It is slightly verbose in the middle sentence about payment details but earns its space. Could be more concise by splitting into bullet points, but not excessively long.

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 a rich output schema (not detailed here) and annotations covering safety and idempotency, the description completes the picture by explaining the return value (live x402 challenge, hosted checkout URL), the optional parameter contributeUsd, and the funding lifecycle (a packet becomes funded only when payment settles). It also addresses what the tool does not do (hold funds, mark funded). No gaps remain for effective invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of funderWallet ('The 0x… address that will pay onchain. Needed for the onchain door's live challenge; the card path does not use it.') and workId ('The packet id, from find_work.'), which provides context beyond the schema's field names. However, the description does not elaborate on the output schema, which is available but not described; a minor gap.

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

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

The description clearly states the tool's purpose: it returns live payment requirements for funding a packet, specifying the onchain door's x402 challenge and optional hosted checkout URL. The verb 'returns' and resource 'payment requirements for funding a packet' are specific, and the description distinguishes this from the sibling 'prepare_backing', which involves a free pledge without payment.

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

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

The description explicitly tells when to use this tool (Step 2 for a buyer, when ready to pay) and when not to (use prepare_backing instead if not ready to pay or want a free sibling). It also provides usage guidance on optional parameter contributeUsd for partial payment and omitting it for full payment. The sibling tool is named and clearly differentiated.

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 declare readOnlyHint=true, but the description describes building a transaction that will mutate on-chain state when signed and submitted, which is a contradiction. The description does disclose that the transaction is unsigned and requires prior approval, but the annotation contradiction undermines trust and violates the scoring rule for 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?

Three sentences with no wasted words: first sentence states purpose, second clarifies transaction type, third notes prerequisite. Information is front-loaded and 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?

The description covers the tool's purpose, the type of output, and a key prerequisite. It mentions the network (Arbitrum) and that it returns unsigned transaction fields. However, it does not reference the output schema or explain error cases (e.g., insufficient approval), and given the annotation contradiction, completeness is slightly diminished.

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 does not add any parameter-level detail beyond what the schema already provides; it mentions collateralUsd and leverage implicitly but without 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 states the verb ('Build'), the resource ('an unsigned on-chain transaction to open a new perpetual position on GMX v2 (Arbitrum)'), and distinguishes from siblings like submit_gmx_order by noting it is non-custodial and returns unsigned transaction fields.

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 'This is NOT a message to sign — it is a full Ethereum transaction' and 'Requires the caller to have approved the GMX Router for USDC collateral spending', providing clear context and prerequisites. However, it does not explicitly state when to use this tool versus alternatives such as submit_gmx_order, though sibling names imply the workflow.

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

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

Adds significant behavioral context beyond annotations: the $0.05 board-write cost via X-PAYMENT header, EWP key exemption, the proposed-vs-funded distinction, and the 5-minute expiry. Even though annotations declare readOnlyHint=true, the description frames the overall posting as a write while the prepare step itself appears read-only, which is consistent with the annotation and the subsequent submit step.

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

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

The description is dense and information-rich; each sentence contributes purpose, inputs, output, cost, payment semantics, or next step. It is longer than minimal but justified given the multi-step nature and important caveats. Slight redundancy with schema descriptions, but well-structured.

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

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

Covers the full interaction contract: required inputs, return values (MESSAGE_TO_SIGN, BODY_JSON), signing method, time limit, cost, payment header, and follow-up call. With an output schema present and strong annotations, no critical gaps remain for an 8-parameter prepare 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?

Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds some conceptual nuance (e.g., proposedPayUsd stays PROPOSED until funded), but it largely restates what the schema already says. No extra syntactic or format details beyond 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?

Description opens with a specific verb-resource combination: 'Put work YOU define on the public board', and the title clarifies it is step 1 of 2. It distinguishes from sibling submit_post_work by explicitly delegating the actual posting to that next step.

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

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

Provides clear workflow guidance: returns MESSAGE_TO_SIGN, user signs with the creator wallet, then calls submit_post_work within 5 minutes. Mentions payment_preflight for affordability checks and the EWP key exemption, giving contextual usage conditions. It does not explicitly name alternatives or exclusions, but the sequential dependency is evident.

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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant context beyond these: it explains that this is a preparation step (returns MESSAGE_TO_SIGN and BODY_JSON), that it triggers a time constraint (5 minutes), and that it is free. The description is fully consistent with the annotations and enriches the agent's understanding.

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 paragraph with no wasted words. It front-loads the purpose and inputs, explains the return value, and ends with a clear next step. Every sentence 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?

Given the complexity (5 parameters, nested objects, output schema) and the annotations, the description is remarkably complete. It explains the overall flow, input requirements, output, timing, and cost. The output schema exists, so the description need not detail the return. The sibling tools list confirms this is part of a proof submission pipeline, and the description integrates seamlessly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the purpose of claimId (from submit_claim), workerWallet (same address that claimed), and proofs (matching the packet's proof line). It also provides concrete examples for proof items. However, the 'gps' parameter is only mentioned in the schema, not in the description, which is a minor gap.

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

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

The description clearly states the tool's purpose as the first step in handing in proof of finished work. It specifies the action ('prepare signed proof'), the context (step 1 of 2), and the resource ('packet's workId'). The guidance on proof items matching the packet's proof line and the 5-minute window for submit_proof distinguish this tool from its siblings, particularly submit_proof.

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

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

The description explicitly tells when to use this tool ('You did the work — start handing in proof'), what inputs are needed (workId, claimId, wallet, proof items), and what to do next ('Sign, then call submit_proof within 5 minutes'). It also explains that submitting proof is free when signed, reassuring the agent about costs. No exclusions are needed, and the flow is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructiveness. The description adds substantial behavioral context: the vote is free, sybil-able, uses no money or contract, and only changes surfacing priority. It explains the two-step flow with a 5-minute timeout and specifies the signing method (personal_sign, no gas). No contradictions 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 single, well-structured paragraph with no wasted words. Every sentence adds value: it defines the action, explains the free nature, outlines constraints, describes the output, and gives step-by-step instructions. It is front-loaded with key information and efficiently covers all necessary guidance.

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

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

Given the tool has 5 parameters (3 required), full schema coverage, an output schema, and is part of a two-step process, the description is complete. It explains the purpose, behavioral rules, signing method, time limit, and follow-up tool. The output schema exists so return values are documented elsewhere. No gaps remain for correct agent invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not repeat parameter details but adds context like 'one wallet, one vote per packet' and implies that voterKind defaults to human. The reason parameter's character limit and public visibility are already in the schema. The description reinforces but does not significantly add new semantic meaning beyond what the schema provides.

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

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

The description clearly states this is step 1 of 2 for voting, returns a MESSAGE_TO_SIGN and BODY_JSON, and distinguishes from submit_vote (step 2). The title 'Vote for or against a work packet' combined with the detailed explanation of what the vote does (steers surfacing priority, no money/proof/contract) makes the purpose highly specific and distinct from sibling 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 provides clear guidance on when to use: for voting on any work packet, including settled or expired ones. It explains the one-vote-per-wallet rule, that it is sybil-able, and that casting again changes the vote. It also instructs to call submit_vote within 5 minutes with the signed message, and that signing is a personal_sign, not a transaction. However, it lacks explicit 'when not to use' guidance or comparison to other prepare_* siblings, but 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?

The description discloses the mutation (removing vote from tally) and the non-erasing history behavior, plus the signing and expiry constraints. However, the annotation readOnlyHint=true directly contradicts this, as withdrawal is a state change. Per rubric, a contradiction warrants a score of 1. Annotation Contradiction is flagged.

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 well-structured sentences: (1) explains the action and its irreversible-but-not-erasing nature, (2) notes cost and rule, (3) lists return values and required next step with a time limit. No filler—every sentence adds necessary 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?

Despite annotations and the tool being part of a two-step process, the description is self-contained. It covers what withdrawing does and doesn't do, cost, authentication, return values, and the mandatory follow-up with a deadline. With an output schema existing, the agent can rely on that for precise return structure. All essential behavioral and workflow details are present.

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

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

Schema coverage is 100%, but the description adds critical context beyond the schema: it emphasizes that voterWallet must be the same 0x… address that cast the vote and ties this to the signature rule. This helps the agent avoid using a wrong wallet and clarifies why the parameter is required.

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

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

The description clearly states the action is "Take back a vote you cast" and specifies the effect (position leaves active tally but stays in public history). It distinguishes itself from sibling tools like prepare_vote (casting) and submit_vote_withdraw (step 2), making the purpose unambiguous.

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

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

Explicitly instructs when to use: to withdraw a vote you already cast. Details the prerequisite (same wallet as casting), the follow-up action (call submit_vote_withdraw within 5 minutes), and notes it's free. Provides a clear protocol without needing to infer usage from other 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=true and openWorldHint=true, implying no data mutation. However, the description states it 'provisions' work, which creates a bounded packet record—this is a write operation. This contradiction undermines trust. The description does add 'never spends/never signs' but that does not resolve the mutation 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?

Four sentences with front-loaded purpose. Some redundancy (e.g., retirement lane detail is tangential for initial understanding) but overall efficient. Could tighten by separating the retired-lane caveat.

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?

Includes output schema (not shown), so return values don't need explanation. Covers purpose, constraints, and safety guarantees. Missing prerequisites (e.g., wallet funding) and error cases, but given the complexity of sibling tools, this is reasonably complete.

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

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

Schema covers all 5 params (100%) with individual descriptions. The description adds value by explaining the two alternative usage modes (place+problem versus board packet id), which gives functional context beyond the schema's field-level 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?

Clearly states the tool turns a place+problem or board packet ID into 'provisioned work' with specific components (scope, method, proof requirement, tCO2e estimate, funding path). Distinguishes from siblings like find_work (which finds packets) by focusing on the provisioning 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?

Implies usage after find_work by mentioning 'board packet id' but does not explicitly contrast when to use this versus alternatives like submit_work or prepare_funding. The 'never spends...' clause subtly clarifies what it does not do, but no direct when-not-to-use guidance is given.

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

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

The description goes well beyond the annotations (which already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint). It adds critical behavioral details: the data source is Regen's public LCD API with no Vealth caching or alteration, how missing figures are handled ('answers so honestly rather than defaulting to zero'), and that the total is withheld until every figure is known. This level of transparency for edge cases is exceptional and fully leverages the description field.

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 three sentences long and front-loads the core purpose. However, it is slightly verbose with parenthetical asides ('the same one Vealth's browser explorer hits; no Vealth backend caches or alters it') that, while informative, could be more concise without losing meaning. It earns its length overall, but a trim would improve conciseness.

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

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

Given the tool's low complexity (1 parameter, simple input schema, one required field) and the presence of a rich output schema (not shown but exists), the description is fully complete. It covers when to use, data source, edge-case behavior for unavailable figures, authentication needs (keyless), and cost (free). No gaps remain for an AI agent to safely invoke 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 coverage is 100% and the only parameter (address) is well-documented in the schema. The description adds extra meaning by reinforcing the bech32 format ('regen1…') and explicitly excluding 0x… addresses, which adds clarification beyond the schema's description. However, since the schema already does an excellent job, the description's incremental value is modest, warranting a 4 rather than a 5.

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 the specific verb 'Live balance, bonded stake, unclaimed staking rewards, and REGEN locked in open governance deposits for any regen1… address', clarifying it reads multiple specific on-chain balances. It clearly distinguishes itself from sibling tools like account_statement or regen_burn_tracker by specifying 'read directly from Regen's own public LCD API' and naming the exact data fields, making the purpose unique and unambiguous.

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

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

The description explicitly says when to use this tool: for live Regen staking and governance balances for a regen1… address. It implicitly guides against using it for Ethereum-style addresses ('not a 0x… Base address') and mentions it is 'Free, keyless, read-only', which helps an agent decide when this tool is appropriate versus alternatives that might require authentication or write operations.

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 as false, making the tool's safety profile clear. The description adds value by specifying the fee-free, keyless, read-only nature, but it doesn't go beyond what annotations imply; thus a moderate score is appropriate.

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 densely packed with relevant information in a single paragraph, but it could benefit from slight restructuring (e.g., using bullet points or clear separation of purpose versus details). It is concise but borders on overwhelming for a quick scan.

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

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

Given the simple parameter schema, rich annotations, and presence of an output schema, the description covers the tool's purpose, provenance, and usage context well. It omits explicit return type details, but the output schema likely fills that gap, so completeness is high.

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 one parameter ('limit'), described as 'Max recent burns to list, newest first. Default 10.' The description does not add additional meaning beyond the schema's definition, so a baseline score of 3 is suitable.

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