xrpl-referee

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

Annotations indicate it is not read-only, idempotent, or destructive. The description adds behavioral details: requires payment, fee_hash is single-use for anti-replay protection, and the return fields. It does not disclose behavior for invalid fee hashes or edge cases, but overall it provides sufficient transparency beyond 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 concise (3 sentences) and front-loaded with the main purpose. It includes necessary details without redundancy. 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?

Given the tool has 5 parameters, full schema description coverage, and an output schema, the description covers all key aspects: purpose, payment requirement, return values, and parameter explanations. No gaps are 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning by listing return values, explaining the single-use nature of fee_hash, clarifying task_category options, and noting when require_consensus is recommended. This adds value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Verify whether completed work meets a task specification using AI.' This is a specific verb ('verify') and resource ('completed work meets a task specification'), and it distinguishes from siblings like 'evaluate_escrow_work' which may handle escrow-specific audits.

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 usage context by requiring a pre-payment of 0.1 XRP and explaining the single-use fee_hash. It notes that 'require_consensus' is recommended for high-stakes tasks. However, it does not explicitly state when to use this tool versus alternatives 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?

The description adds significant behavioral context beyond annotations: it returns worker address and agreed price, automatically rejects other bids, and clarifies that no funds are held by the referee. This fully discloses side effects and data returned.

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

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

The description is well-structured with a purpose statement, workflow hint, and returns section. It is slightly longer than necessary but every sentence adds value. The inclusion of the returns block is helpful.

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 (3 parameters, simple action) and the presence of an output schema, the description fully covers the workflow, side effects, and next steps. No gaps 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?

Although schema coverage is 100% with clear descriptions, the tool description adds context by referencing source functions (e.g., 'from view_job() bids list' for bid_id, 'from post_job()' for job_id), which helps the agent understand how to obtain these parameters.

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

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

The description clearly states it accepts a bid and awards the job to a worker agent, with a specific verb and resource. It distinguishes itself from sibling tools like 'direct_hire' and 'submit_bid' by focusing on accepting bids.

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 (to accept a bid) and provides a clear next step (create_escrow_vault). It mentions that other bids are automatically rejected, but does not explicitly list conditions when not to use it or compare with 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable transparency: data is cached for 24 hours, the tool always returns a result and never raises on list unavailability, and it describes consequences for sanctioned wallets. 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 concise, well-structured, and front-loaded with the main action. It uses bullet points for return fields, making it easy to parse. Every sentence adds value without repetition.

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

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

Given the existence of an output schema detailing return fields, the description covers behavioral completeness: it explains sourcing, caching, fallback behavior, and operational impact. 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 input schema provides a clear description for the single parameter (wallet_address). Schema coverage is 100%, so the description does not need to add extra meaning. The baseline score of 3 is appropriate as the schema already carries the semantic load.

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

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

The description clearly states the tool screens an XRPL wallet against the OFAC SDN sanctions list. The verb 'screen' is specific and distinguishes it from sibling tools, none of which perform sanctions checks.

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

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

The description implies usage context by noting that sanctioned wallets cannot participate in AgentTrust escrows and receive a trust score of 0. However, it does not explicitly state when to use or when not to use this tool relative to alternatives, though no direct siblings exist.

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 that it registers the hash and automatically caches the escrow sequence number, and mentions the return value with 'status' and 'sequence'. Annotations confirm idempotency and non-destructiveness, and the description aligns. 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 concise: three sentences covering purpose, usage instruction, and return value. No extraneous text. Information is front-loaded.

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

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

Given the tool's simplicity (2 params, annotations present, output schema exists), the description is complete enough. It covers when to use, what it does, and what is returned. Could mention error handling but not essential.

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

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

Schema coverage is 100%, with both parameters fully described. The description does not add meaningful information beyond the schema (e.g., escrow_id is already described as 'receipt code returned by create_escrow_vault'). 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 the action ('Register the on-chain EscrowCreate transaction hash with the referee') and the resource (transaction hash with referee). It distinguishes from sibling tools like create_escrow_vault or evaluate_escrow_work by specifying this is the confirmation step after creation.

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 'Call this after submitting the EscrowCreate transaction on XRPL', providing clear usage context. It does not mention when not to use or list alternatives, but the instruction is direct and sufficient for an agent.

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

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

Annotations indicate non-read-only and non-destructive, but the description adds behavioral context: it stores a WalletVerification record and adds +8 points. This goes beyond annotations, though it doesn't discuss idempotency or potential duplicate side effects.

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?

Description is concise: four sentences front-loading purpose, followed by process details and return values. No extraneous content.

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

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

Given the tool's complexity, full schema coverage, and presence of output schema, the description adequately covers behavior, return values, and context. It is complete enough for an agent to use 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 covers 100% of parameters with descriptions. The tool description adds context by explaining tx_hash as 'the XRPL transaction hash of the AccountSet tx you submitted with the challenge in a Memo' and wallet_address as 'The XRPL wallet address (r...) you are verifying.' This enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose: complete wallet ownership verification using an XRPL AccountSet transaction. It specifies the on-chain lookup, confirmation of source, Memo verification, record storage, and point award. This is distinct from sibling tools like check_wallet_sanctions and get_wallet_verification_challenge.

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

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

The description implies usage after broadcasting an AccountSet transaction but does not explicitly state when not to use or mention alternatives. It lacks guidance on prerequisites or exclusions.

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

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

Annotations indicate destructive=True and idempotent=False. The description adds context: funds release automatically upon AI approval, and the tool returns condition details for an XRPL EscrowCreate transaction, going beyond 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?

Description is efficiently structured with a numbered flow and returns section. It is front-loaded with purpose and contains no fluff, though slightly longer than minimal.

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 (13 params, part of a multi-step process), the description covers the workflow, prereqs, returns, and parameter usage. It references sibling tools and explains the overall context thoroughly.

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 has 100% parameter description coverage, so the baseline is 3. The description adds some extra context (e.g., referencing worker_address from award_job, amount minimums) but does not significantly enhance meaning.

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 creates an AI-gated XRPL escrow vault, specifying verb and resource. It distinguishes from siblings like award_job and confirm_escrow_transaction by detailing its role in the workflow.

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?

Description provides a clear 5-step typical flow showing when to use this tool (after award_job, before confirm_escrow_transaction), including prerequisites like paying the protocol fee.

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 indicate readOnlyHint=false, openWorldHint=true, etc. The description adds key behavioral details: listing duration (30 days), fee requirement, visibility to humans and agents, and return fields. It does not mention side effects like non-refundability but is sufficient 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 concise, with three focused paragraphs: purpose, prerequisite, and returns. No unnecessary sentences, and front-loaded with the primary action.

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 10 parameters and no output schema provided (only described in text), the description covers the fee process, visibility, and return fields. It lacks error scenarios or rate limits but is largely complete for 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%, so baseline is 3. The description mentions fee_hash in context but does not add significant meaning beyond the schema's parameter descriptions. It meets the minimum but does not elevate.

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 'List' and the resource 'a skill on the AgentTrust marketplace', with a specific duration of 30 days. This distinguishes it from sibling tools like list_marketplace_skills (read) and post_job (different resource).

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 prerequisites ('pay the 0.1 XRP/month listing fee' with address) and explains the visibility of the listing. It does not directly compare to siblings, but the context is clear when to use this tool versus reading listings.

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, idempotentHint=true, destructiveHint=false. The description adds that no funds move and that the return includes escrow creation instructions, which aligns with the safe, read-only nature. 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 concise: first sentence states purpose, followed by usage guidance, workflow steps, and return values. Every sentence adds value with no repetition or filler.

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

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

Given the simple input (1 param), clear annotations, and existence of an output schema (returns listed), the description is complete. It explains the tool's role in the workflow and what the agent can expect.

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

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

The single parameter skill_id is described in both schema and tool description. Tool description adds context: 'skill listing ID from list_marketplace_skills()' with example 'SKILL-PY-001', which goes beyond the schema's description. Schema coverage is 100%, but the description adds meaningful usage context.

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

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

The description opens with a clear verb+resource: 'Get the wallet address and hiring details for a skill listing — skipping the job board entirely.' It distinguishes itself from sibling tools like award_job and submit_bid by stating it's for direct hiring without the bid/award process.

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: 'when you've found a skill provider via list_marketplace_skills() and want to hire them directly without going through the bid/award process.' Provides a typical flow with steps and clarifies what not to do: 'No funds move — you still create the escrow yourself via create_escrow_vault().'

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 destructiveHint true, but description adds details: auto-finish on approval, ledger verification, and returns on pass/fail including attempts_remaining. 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?

Description is relatively short, front-loads purpose, and efficiently conveys behavior and returns. Minor bullet list of returns is clear.

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 5 parameters (2 required) and presence of output schema, the description covers purpose, behavior, and key parameter details. Could mention additional parameters, but schema handles those.

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. Description adds value for the 'work' parameter (XRPL tx hash details) but does not elaborate on other parameters like require_consensus or evidence_links.

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 the exact action: 'Submit proof of completed work against an existing escrow vault.' It clearly distinguishes from siblings like create_escrow_vault and get_escrow_info.

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 context: payment releases automatically on approval, no EscrowFinish needed, and XRPL tx hashes are auto-verified. It does not explicitly list when not to use, but implies use cases (e.g., proof of NFT transfers).

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. The description adds that the fulfillment key is never returned, which is critical information beyond what annotations provide. It also lists the returned fields, adding transparency.

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 with two sentences and a list of return fields. It front-loads the key information. The list may be slightly redundant given the output schema exists, but it does not significantly waste space.

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

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

With an output schema present, the description does not need to detail return values. It covers the main purpose and a critical behavioral constraint (no fulfillment key). For a simple read tool, this is complete enough for effective 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?

Input schema coverage for escrow_id is 100% with a clear example ('e.g. AT-7X9K-2MQ4'). The description adds no additional parameter semantics; with full schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states 'Retrieve metadata about an existing escrow vault', specifying the verb and resource. It also explicitly notes what is not returned (fulfillment key), distinguishing itself from sibling tools like create_escrow_vault.

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

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

The description implies usage for retrieving metadata without the fulfillment key, but does not explicitly state when to use this tool over alternatives or mention any exclusions. The guidance is adequate but not 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?

Annotations already indicate read-only, idempotent, non-destructive. The description adds return fields (estimated_rlusd, trust_line_ok, etc.), providing valuable behavioral context beyond annotations. No contradiction.

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

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

Highly concise with three sentences plus bullet list of returns. Front-loaded purpose and usage. No unnecessary words.

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

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

For a simple read-only quote tool with output schema, the description covers purpose, usage, and return values completely. No 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?

Input schema coverage is 100% with clear descriptions. Description does not add extra meaning to parameters beyond the schema. 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?

Clearly states 'Get a live XRP to RLUSD conversion quote via the XRPL DEX', specifying the action, source, and currencies. Distinguishes from sibling 'get_xrp_price' which is about XRP price, not conversion.

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 context: 'Use before creating an RLUSD-denominated escrow or before claiming an escrow if you want to understand the current USD value.' This guides when to use, though no explicit alternatives or exclusions are given.

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

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

Annotations declare readOnlyHint=true, and description confirms it's a read-only request. Discloses expiration time (30 min) and that no private key is transmitted. 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?

Two concise paragraphs: first states purpose, second gives detailed usage instructions and return fields. No redundancy or filler.

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

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

Complete for a verification step. Includes security context, expiration, follow-up function, and return fields. Output schema exists, so return details are 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?

Only one parameter (wallet_address) with 100% schema coverage. Description adds minimal extra context (r... format), but schema already adequately describes it.

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

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

Clearly states the tool's purpose: requesting a one-time verification challenge to prove XRPL wallet ownership. Distinguishes from sibling tool confirm_wallet_ownership, which is the follow-up 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 explicit step-by-step instructions: after getting challenge, submit AccountSet transaction with memo hex, then call confirm_wallet_ownership(). Mentions expiration and security note (no private key sent). Clear context and 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds that the price may be cached if source is briefly unavailable, giving useful edge-case transparency. 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?

Two sentences plus a bullet list of return values. Every word is purposeful, and the key purpose is front-loaded.

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

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

With zero parameters and an output schema present, the description covers all necessary context: what the tool does, when to use it, and what it returns (usd, gbp, cached flag). 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?

There are zero parameters, so the description need not add parameter meaning. Baseline 4 is appropriate as the schema coverage is 100%.

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 'Get the current live XRP price in USD and GBP.' This is a specific verb-resource pair with clear scope. The sibling tools include get_rlusd_quote, so this tool is well-distinguished.

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 includes 'Use this to convert XRP bounty amounts to fiat before deciding whether a job is worth taking.' This provides clear context for use, though it does not explicitly list when not to use or 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral traits: bounties are backed by XRPL escrow and pay automatically upon AI approval, and it explains job statuses (OPEN vs LOCKED) and the effect of claiming. 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 well-structured with sections for statuses, workflow, and returns. Each sentence serves a purpose. While slightly lengthy, it is front-loaded with the core purpose and avoids 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?

Given the tool's simplicity (3 optional params, output schema present, comprehensive annotations), the description covers statuses, workflow, and return structure. It lacks explicit differentiation from sibling list_open_jobs but is otherwise complete for an agent to use effectively.

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 clear descriptions for all 3 parameters. The description does not add new information about parameters beyond what the schema provides (e.g., category enum values). It focuses on workflow and returns, meeting the baseline but not exceeding.

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

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

The description opens with 'Browse open bounties on the AgentTrust marketplace,' clearly stating the verb 'browse' and resource 'open bounties.' It distinguishes itself from siblings like list_open_jobs by emphasizing marketplace jobs backed by escrow and including a detailed workflow for claiming jobs.

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 usage context: it is the primary tool for discovering open bounties and includes a step-by-step workflow for claiming an OPEN job. It warns against claiming LOCKED jobs but does not explicitly compare with sibling list_open_jobs or specify when not to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds context about return structure, wallet addresses, and how listings work, complementing the annotations 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?

The description is concise and well-structured: a brief intro, explanatory context, a numbered workflow, and return fields. Every sentence serves a purpose without wordiness.

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

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

Given the presence of annotations, full parameter schemas, and a listing of return fields, the description is complete. It explains the tool's role in a larger workflow and provides sufficient context for an AI agent.

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

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

The input schema already provides full descriptions with defaults and enums (100% coverage). The description hints at filtering by category/rate in the workflow, but this does not add substantial new meaning beyond the schema.

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

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

The first sentence clearly states the tool browses marketplace skills, distinguishing it from sibling tools like list_marketplace_jobs. It also explains the purpose of listings and how they facilitate direct hires.

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 outlines a three-step workflow starting with list_marketplace_skills, tells when to use it (to find a provider), and distinguishes it from direct_hire and create_escrow_vault.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and no destructive action. The description adds valuable behavioral context: no escrow exists yet, workflow steps, and return structure. 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 well-structured with a clear purpose, workflow, and return structure. It is slightly verbose but not wasteful. The main purpose is front-loaded.

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

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

Given the comprehensive annotations and schema descriptions, the description adds complete workflow context and return details. The tool is adequately documented for an agent to use 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 baseline is 3. The description does not add any additional parameter-level meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'Browse' and resource 'jobs' on the AgentTrust job board, and distinguishes from siblings like list_marketplace_jobs and view_job by specifying 'open for bidding' and the workflow 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 provides explicit usage context within a multi-step workflow, showing when to use this tool (step 1) and mentioning next steps (submit_bid). However, it doesn't explicitly state when not to use it or mention alternative listing 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?

Discloses that the tool is free and non-destructive, and specifies the return fields (status, job_id, expires_at, next_step). Annotations already indicate openWorldHint=true and readOnlyHint=false; the description adds workflow context beyond these.

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?

Description is front-loaded with the main action and returns, but includes workflow details that could be separated. Still concise 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 8 parameters (4 required), 100% schema coverage, annotations, and an output schema, the description provides a useful workflow and return values, making it fairly complete for an agent to use.

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 description does not explain individual parameters, but it adds context for budget_xrp as 'Indicative maximum budget'. Baseline at 3 is appropriate since schema already documents all parameters.

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

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

Clearly states 'Post a job to the AgentTrust job board' and distinguishes from siblings (award_job, submit_bid) by outlining the workflow.

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 context ('No fee, no funds held') and a step-by-step workflow (list_open_jobs → submit_bid → award_job → create_escrow_vault), guiding the agent on when this tool is appropriate.

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 indicate this is a non-read-only, non-destructive action. The description adds context about email notifications for humans and polling for agents, which is not in annotations. It could mention if bids can be updated, but overall good.

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: purpose, process, human/AI guidance, return values. No fluff, front-loaded key 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?

Given the parameter count and output schema, the description covers the essential workflow. It could be more explicit about bid finality but is 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?

With 100% schema coverage, the baseline is 3. The description adds value by clarifying when worker_email is needed (humans vs agents) and that poll view_job replaces email for agents.

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 'Submit a bid on an open job posting,' clearly stating the action and target. It distinguishes itself from sibling tools like award_job and view_job by referencing them.

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 explains the buyer's review and award process via award_job(), and provides separate guidance for human workers (use email) vs AI agents (poll view_job). This tells when to use each tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds valuable detail about the return structure (job details + bids list with specific fields) and status interpretation, exceeding annotation coverage.

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, front-loaded with core purpose, efficient with no wasted words. 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?

Given the presence of an output schema and only one parameter, the description adequately covers the tool's behavior, including return structure and status specifics.

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

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

Schema coverage is 100% for the single parameter 'job_id', which has a clear description. The description adds no extra parameter details, 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 clearly states 'View a job posting and all current bids' with a specific verb and resource. It is distinguished from siblings like list_open_jobs and post_job.

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 'Use this to check the status of a job you posted or bid on' and explains interpretation of awarded status. While not exhaustive, it provides clear use context.

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