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

The description adds meaningful behavioral context beyond the annotations: the mandatory fee, two payment paths, single-use fee_hash anti-replay protection, and the return field list. However, Option 2's 'call with no fee first' is ambiguous because fee_hash is a required parameter, and consensus behavior is only implied by the schema.

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

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

The purpose is front-loaded, and the fee instructions and return list are structured and non-redundant. The description is somewhat long due to the payment details, but each sentence carries necessary operational 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 description covers the fee workflow and return shape, which is helpful, but the 'call with no fee first' instruction under Option 2 conflicts with the schema requiring fee_hash. It also does not explain when require_consensus is advisable or how to route to alternatives. Overall, it is adequate but has a notable ambiguity.

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

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

The input schema already describes all five parameters with full coverage, including fee_hash format and task_category options. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb-resource pair: 'Verify whether completed work meets a task specification using AI.' This clearly identifies the tool's core function and distinguishes it from escrow- or payment-specific siblings, though it does not explicitly name an alternative.

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 is given for when to choose audit_task over sibling tools such as evaluate_escrow_work. The only process guidance is the fee payment requirement, which is about how to call the tool, not when 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 discloses important behavior beyond annotations: all non-selected bids are automatically rejected, the referee never holds funds, and escrow is created directly between buyer and worker. This meaningfully supplements the annotations, which only indicate readOnly=false, openWorld=true, idempotent=false, and destructive=false.

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

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

The description is compact and front-loaded, with the core action in the first sentence and important side effects in the next. The Returns block is slightly redundant given an output schema exists, but it still communicates the next_step guidance usefully without bloating the description.

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

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

For a mutating award action, the description covers the main side effects, the safety property around funds, and the required follow-up action. It does not discuss error cases or irreversibility, but the annotations and output schema fill some of that gap, making it complete enough for a single-call 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 provides 100% parameter descriptions, including provenance from view_job() and post_job() and the buyer_address verification purpose. The description adds no additional parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Accept a bid and award the job to a worker agent.' It clearly distinguishes this from sibling tools like submit_bid, claim_job, and direct_hire because it is the action that finalizes a previously submitted bid for a specific 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?

The description communicates when to use it: after a bid has been selected, and it explains the expected next step by calling create_escrow_vault(). It doesn't explicitly name alternative tools to avoid, but the context plus 'All other bids are automatically rejected' makes the usage scenario unambiguous.

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

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

The description adds meaningful behavioral detail beyond annotations: it caches verified status, unlocks escrows up to $10,000 vs. the $3,000 default, registers results with AgentTrust, and returns cached results on repeated calls. This complements idempotentHint and aligns with readOnlyHint: false, so 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 structured into focused sentences: what it does, why it matters, when to call it, and what it returns. Each sentence earns its place, including the Xaman URL and the escrow cap distinction, without redundant filler.

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

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

For a single-parameter tool with an output schema, the description covers the trigger condition, side effects, idempotence, and return fields. It could slightly improve by clarifying any prerequisites (e.g., wallet ownership or prior KYC initiation), but nothing essential is missing for correct 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 single parameter is fully documented in the input schema with format and purpose ('The XRPL wallet address (r...)'), so schema coverage is 100%. The description adds some context by mentioning wallet operator and wallet holder, but it does not materially enrich the parameter 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 pairs a specific verb ('Check and register') with a clear resource ('Xaman KYC verification status') and a target ('wallet operator'). It also distinguishes itself from sibling tools like check_wallet_sanctions and confirm_wallet_ownership by naming the exact system queried (Xaman) and the action performed (identity verification registration).

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

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

The description explicitly says to call this after completing KYC in the Xaman app and notes it is safe to call multiple times. It gives clear contextual guidance, though it does not explicitly name alternatives or state when not to use it, which keeps it from a 5.

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

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds meaningful behavioral details beyond annotations: data is cached for 24 hours, the tool never raises on list unavailability and degrades gracefully, and it always returns a result with a defined structure. This is strong added 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 and well-structured: it opens with the core purpose, then adds relevant sourcing/caching context, business impact, graceful degradation behavior, and a clear return fields list. Every sentence contributes value 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?

For a single-parameter read-only tool with a defined return structure, the description is highly complete. It covers what the tool does, how data is sourced, what happens for sanctioned wallets, how failures are handled, and what the response contains. Nothing essential is missing.

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

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

Schema description coverage is 100%, and the input schema already clearly documents `wallet_address` as an XRPL wallet address (r...). The description does not add significant new meaning about the parameter beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the specific verb ('Screen') and resource ('an XRPL wallet address against the US OFAC SDN sanctions list'), making the tool's purpose unmistakable. It also differentiates this from sibling tools like check_wallet_kyc by focusing on sanctions screening.

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 usage context is implied through the purpose and the consequence statement ('Sanctioned wallets cannot create or participate in AgentTrust escrows'), but the description does not explicitly mention when to prefer this tool over alternatives or when not to use it. No sibling tool is named as an alternative.

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 it is a write operation (readOnlyHint=false) and not destructive. The description adds that the job is immediately awarded to the wallet without buyer approval, buyer is notified via webhook, and outlines the subsequent escrow steps. This provides useful behavioral context beyond the annotations, covering immediate consequences and follow-up actions.

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 moderately long but well-structured. It starts with the core action and condition, then explains the process in numbered steps, and ends with return fields. Every section adds value; it is not overly verbose for the complexity of the workflow.

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

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

The description covers the prerequisite (claimable=True), the immediate effect, the buyer notification, the subsequent escrow steps, and the return fields. Given that an output schema exists, it does not need to elaborate on return types. It is complete for an agent to understand the workflow and invoke the tool correctly, though it does not cover error cases or rollback 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 description coverage is 100%, so all parameters are already documented. The description does not add significant extra meaning beyond the schema; it mentions that job_id must come from list_marketplace_jobs and have claimable=True, which is already in 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?

The description clearly states the tool claims an open bounty job directly, bypassing the bid/award cycle. It specifies the resource (bounty job) and the action (claim), and distinguishes it from sibling tools like submit_bid and award_job by explicitly contrasting with the bid/award cycle.

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

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

It states when to use it: 'Directly claim an open bounty job' and the condition 'Only works on jobs where claimable=True.' It implies this is an alternative to the bid/award cycle, but does not explicitly name alternatives or say when not to use it. The condition is clear enough for an agent to decide, but could be more explicit about using submit_bid or award_job for non-claimable jobs.

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 main side effect: registering the transaction hash and having the referee cache the escrow sequence number. The annotations already cover idempotency and non-destructiveness, and the description adds the concrete state-changing behavior without contradicting those 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 compact and well-structured, with a clear call-to-action, a timing note, and a short returns section. Every sentence adds useful context without 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?

Given the tool has only two well-described parameters and annotations already convey read/write/destructive/idempotent traits, the description provides sufficient context for an agent to invoke it correctly. It explains the prerequisite (after submitting EscrowCreate), the side effect, and the return fields.

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

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

Both parameters are fully described in the input schema: tx_hash is identified as a 64-character hex XRPL transaction hash and escrow_id as the receipt code from create_escrow_vault. The description does not add extra parameter semantics beyond this, so the baseline score for high schema coverage 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 clearly states the specific verb and object: registering the on-chain EscrowCreate transaction hash with the referee. It also provides context by saying this is done after submitting the EscrowCreate transaction, which distinguishes it from the related submission and preparation 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 explicitly says to call this after submitting the EscrowCreate transaction on XRPL, giving clear timing guidance. It also explains the benefit (the referee caches the sequence number so the worker does not need to provide it), but it does not explicitly discuss alternatives or edge cases such as retries.

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 explicitly states side effects: 'a WalletVerification record is stored' and 'the wallet earns +8 points on its trust score.' This makes the non-read-only nature transparent. It does not describe failure scenarios, but that is not required and the main effects are covered.

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 but includes both the process and the outcome. The 'Returns' section adds useful context without excessive verbosity. It is well-structured and every sentence contributes to understanding the tool.

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

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

Given the tool's complexity (on-chain lookup, memo verification, record storage, trust score update), the description covers all essential aspects. The return values are listed, and the process steps are clear. Minor missing details like error handling or exact memo format do not detract significantly.

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?

All three parameters are described with meaningful context: wallet_address is the XRPL address to verify, tx_hash is the transaction hash of the AccountSet, and issuer_id clarifies its role for NFT issuer verification. The descriptions add real semantic value 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 clearly states the action (confirm wallet ownership), the method (using a previously broadcast XRPL AccountSet transaction), and the specific verification steps (look up tx, confirm sender, check memo). It leaves no ambiguity about the tool's purpose.

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

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

It explains the prerequisite (a transaction you broadcast) and what it does on-chain, effectively indicating when to use it (after broadcasting an AccountSet with a challenge memo). It does not explicitly contrast with sibling tools, but the context is clear enough for correct usage.

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

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

With no annotations, the descripcion carries the full burden and does an excellent job: it explicitly says the wallet is not funded, explains base and owner reserves, lists funding methods, and warns that anyone with the seed controls the wallet. This is strong behavioral disclosure for a key-generation tool.

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

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

The opening line states the core function immediately, followed by the critical unfunded status and security warning. The funding options are detailed but relevant and well-structured; every sentence adds useful context without padding.

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 wallet creation tool with an output schema, the descripcion is complete: it explains what is returned, the mainnet funding requirement, reserve implications, funding paths, and seed security. An agent has everything needed to invoke it and understand the result.

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 info for the descripcion to add; baseline 4 applies. The descripcion appropriately focuses on return value and usage context instead of nonexistent 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?

Descripcion states the specific verb and resource: generate a new XRPL keypair for an agent wallet. It clearly differentiates from sibling wallet tools by emphasizing creation, return of address and seed, and its unfunded status.

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?

Descripcion makes the use case clear — generate a new agent wallet keypair — and provides practical next steps for funding. It does not explicitly name sibling alternatves like fund_xrpl_wallet_via_coinbase, but the context is sufficient for an agent to know when this tool applies.

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 behavioral context beyond annotations: it explains the protocol fee prerequisite, the requirement to use the returned condition in a separate XRPL EscrowCreate transaction, and the AI-gated release mechanism. Annotations already indicate non-read-only, non-idempotent, and destructive side effects, so the description complements them 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 well-structured with a numbered flow and a returns list. It is front-loaded with the core purpose, and every sentence adds value—covering the fee, the sequence, and the expected outputs. No unnecessary fluff.

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

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

For a complex tool with 13 parameters and an output schema, the description is thorough. It explains the end-to-end flow, prerequisites, and what the caller must do with the returned values. The output schema covers return details, so the description need not repeat them. Nothing essential 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 coverage is 100% (all parameters have descriptions), so the baseline is 3. The description adds meaningful usage context for key parameters: worker_address should come from award_job(), task_description is evaluated by the AI referee, and fee_hash is implied by the fee payment step. This elevates it to 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 clearly states the tool's purpose: 'Create an AI-gated XRPL escrow vault' and explains how funds are released. It distinguishes from siblings like confirm_escrow_transaction and prepare_escrow by focusing on the creation step and outlining the full workflow. It uses a specific verb+resource and is not a tautology.

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 step-by-step 'Typical flow' that includes prerequisite steps (award_job, protocol fee) and subsequent actions (confirm_escrow_transaction). It explicitly tells the agent when to call this tool and what to do after, giving clear context for usage among siblings. While it doesn't list alternatives, the flow makes the intended usage unambiguous.

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

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

The description discloses the main side effects: a listing is created, a payment is required via fee_hash, and the listing becomes publicly visible. It does not mention potential duplicate or failure behavior, but annotations already cover idempotency and open-world expectations, so the added payment and visibility context is sufficient.

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 tightly structured with a clear purpose, a bulleted payment precondition, a visibility summary, and a concise return note. No redundant or filler sentences are present; every line 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?

Given the tool's complexity—10 parameters, required payment step, and open-world side effects—the description covers the core context: what to do before calling, what happens when listed, and what the caller receives. The return shape is stated, and annotations fill any remaining gaps around idempotency and read-only 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 each parameter already has a meaningful description. The description adds important contextual meaning for fee_hash (payment precondition) and clarifies the listing lifecycle, which goes beyond the schema alone.

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 ('List a skill on the AgentTrust marketplace for 30 days') and identifies the exact resource and scope. It also distinguishes the listing's audience by referencing the marketplace UI and list_marketplace_skills(), 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?

It provides the essential precondition (pay the $0.10/month fee and supply fee_hash) and explains the outcome (visibility to humans and agents). It does not explicitly contrast with sibling tools like post_job or direct_hire, but the seller-side intent is clear from the wording and parameter descriptions.

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?

Even though the annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior, the description adds important context by explicitly stating 'No funds move — you still create the escrow yourself via create_escrow_vault().' This prevents a serious misunderstanding about whether direct_hire actually transfers money or creates an escrow.

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 opening statement, explicit usage conditions, a numbered typical flow, and a concise return list. Every sentence contributes useful information, and the most important fact — no funds move — is prominently stated.

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

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

Given the single parameter, existing output schema, and the annotations, the description is complete. It explains what the tool returns, how it fits into the larger hiring workflow, and what side effects it does not have. An agent has enough context to call it correctly and interpret the result.

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 description for skill_id is already complete (100% coverage) with an example format, so the description does not need to add much. It mentions skill_id in the flow and example call, but does not add new parameter-level 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 a specific action and resource: getting the wallet address and hiring details for a skill listing. It explicitly distinguishes itself from the job board flow and names the related sibling tools, so an agent can immediately understand what direct_hire does and how it differs.

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: after finding a provider via list_marketplace_skills() and when wanting to hire without the bid/award process. It also provides a typical three-step flow with create_escrow_vault(), which is strong practical guidance beyond just a vague 'use this for direct hiring.'

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=false and destructiveHint=true, setting the expectation of a state-changing operation. The description adds valuable behavioral context: payment releases automatically on approval, hashes are auto-verified, and it details the exact return structures for PASS and FAIL. 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 a clear opening, a key behavioral note, and a concise breakdown of return values. It is slightly repetitive (hash verification appears both in the description and schema) but overall efficient and front-loaded with the core purpose.

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 complete for an agent to invoke it correctly: it explains the purpose, the automatic payment behavior, the verification process, and both possible return formats. The output schema is present, so return values are fully specified. All parameters are documented in the schema, and the description covers the essential behavioral nuances.

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 each parameter has a clear description. The description repeats the hash verification for the work field, which the schema already provides. It adds no additional parameter-specific meaning beyond the schema, so a baseline of 3 is appropriate.

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

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

The description opens with a clear verb+resource ('Submit proof of completed work against an existing escrow vault'), specifies the automatic payment release, and distinguishes it from sibling tools like create_escrow_vault and confirm_escrow_transaction by focusing on the evaluation action. It is unambiguous and 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 provides clear context for when to use this tool (to prove work against an escrow vault, useful for NFT transfers, token payments, etc.) and states that approval auto-finishes without EscrowFinish. It does not explicitly exclude alternatives, but the intended use case is well-defined and distinct from siblings that create or confirm escrows.

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?

No annotations are provided, so the description carries full burden. It discloses the Coinbase v2 API usage, HMAC authentication, and that no paid plan is required. It explicitly states that credentials are user-owned, the server holds none, and credentials can be passed via env vars or direct parameters. It also describes the one-time human setup and that after that it is fully autonomous. It doesn't mention transaction irreversibility or fee details beyond the default amount, but it covers the most critical aspects.

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

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

The description is long but well-structured with a clear lead sentence, followed by credential ownership emphasis, and a bulleted setup section. It is front-loaded with the core purpose. While it could be tightened, the length is justified given the external API setup and credential handling requirements. The use of headings and bullets aids scannability.

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

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

Given the tool's complexity (external API, credentials, setup), the description is thorough. It covers the full workflow, authentication, credential handling, one-time setup, and autonomy after setup. The presence of an output schema means return values need not be explained. An agent has all necessary information to call the tool correctly and understand prerequisites.

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 significant meaning: explains the usd_amount default rationale (covers 1 XRP reserve + fees + buffer), notes that xrpl_address comes from create_agent_wallet, and clarifies the fallback behavior for coinbase_api_key and coinbase_api_secret to environment variables. This goes beyond the schema's terse property descriptions.

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

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

The description states the specific verb ('Buy XRP on Coinbase and withdraw it to an XRPL address') and the resource (an XRPL wallet via Coinbase). It clearly differentiates from siblings like get_xrp_price or create_agent_wallet by describing the end-to-end bootstrap action. The opening line is precise and actionable.

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

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

It explains when to use the tool ('lets a USDC-native or fiat-funded agent bootstrap an XRPL wallet without manual exchange steps') and outlines the prerequisite human setup. It doesn't explicitly state when NOT to use it or name alternative tools, but the context is clear enough that an agent can decide correctly. It also specifies that it works with a free account, setting expectations.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds that the quote is live and lists return fields (from_amount, to_amount, rate, slippage estimate), which is context beyond the annotations. It does not disclose details such as whether the quote is indicative or includes fees, but for a read-only quote tool the added context is useful.

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 short and front-loaded: the lead sentence states exactly what it does, followed by two practical use cases and one line listing return fields. No filler or redundant restatement.

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 rich annotations (read-only, idempotent, not destructive), the fully described schema, and an output schema, the description covers purpose, use context, and result shape. Nothing essential for correctly choosing and invoking this tool is missing.

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

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

Schema coverage is 100%: each parameter has a description. The tool description mostly reinforces the currency pair ('between XRP and RLUSD') without adding new constraints or units. Baseline 3 is appropriate because the schema already does the heavy lifting.

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

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

The description opens with a specific verb-resource pair: 'Get a live DEX price quote for swapping between XRP and RLUSD on the XRPL DEX'. It names the exact pair and platform, so the resource is clear. It does not explicitly contrast itself with sibling tools like get_rlusd_quote or get_xrp_price, so it stops short of full sibling differentiation.

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

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

It gives concrete when-to-use contexts: pricing escrows in RLUSD while paying in XRP, or checking the current rate before a job budget. This tells an agent when the quote matters, but it does not name alternative tools or say when not to use this one, so it does not fully route around 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?

The description explicitly states that the fulfillment key is never returned and only returned on approval, which is a critical behavioral caveat. It also lists all return fields, giving a complete picture of what the caller can expect.

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, with a brief opening sentence, a critical caveat, and a clean bulleted list of return fields. Every sentence adds value and there is no redundancy.

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

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

Given the simplicity of the tool and the complete schema with an example value, the description provides all necessary context for a caller to understand what the tool does and what it returns. No additional information 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?

The description does not add any semantic detail about the escrow_id parameter beyond what the input schema already provides. Since schema coverage is 100% and the parameter is a simple identifier, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves metadata about an existing escrow vault, which distinguishes it from creation, confirmation, and other escrow operations. However, it does not explicitly contrast it with sibling read-only tools or specify when to choose this over alternatives, leaving slight ambiguity.

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

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

The description implies usage for fetching escrow metadata without side effects, and the explicit note about never returning the fulfillment key provides important guidance. It does not formally state when to use this tool versus other escrow-related tools, but the purpose is clear enough for typical read scenarios.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful context by listing the returned fields (issuer name, category, website, verification status, domain proof) and by clarifying the registry-backed nature of the lookup. This is helpful but not exceptionally rich; it does not explain behavior on missing or invalid addresses.

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 core action; the second gives a concrete use case; the third lists the return fields. No wasted words or redundant restatements of the name.

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

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

For a one-parameter, read-only lookup with an output schema, the description covers the essential elements: what it does, when to use it, and what it returns. It could be more complete by contrasting with the sibling lookup tool and explaining not-found behavior, but these are minor gaps for a simple lookup operation.

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

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

Schema description coverage is 100% and the parameter description already explains the wallet address format (r...) and purpose. The tool description does not add additional parameter-level details beyond what the schema provides, so it sits at the 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 a specific action ('Look up a registered NFT issuer by their XRPL wallet address') and resource (NFT issuer in the AgentTrust registry). It also describes the intended use case, but it does not explicitly differentiate itself from the similarly named sibling tool 'lookup_nft_issuer', so it misses the highest bar for sibling distinction.

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

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

The description gives clear context for when to use the tool ('verify the identity of an NFT's minting wallet' and check registry membership). It does not, however, state when not to use it or mention alternatives such as 'lookup_nft_issuer', so exclusion guidance is absent.

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, covering the safety profile. The description adds that it checks trustline status (via worker_address) and returns slippage warnings, which is useful but not extensive. It doesn't discuss potential errors or network behavior, but for a read-only operation, this is adequate.

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: a single sentence for purpose, a usage line, and a return-field list. No redundant information; 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 tool's simplicity (read-only quote, 2 parameters), the description covers the essential usage context and return fields. The presence of an output schema (as indicated) means the return values are already structured, so the description need not elaborate further. It is complete for an agent to decide when and how to call it.

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

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

Schema description coverage is 100%, with both parameters already well-documented. The description doesn't add new meaning beyond what the schema provides; it merely restates the purpose in prose. Baseline 3 is appropriate when the schema carries the parameter documentation.

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

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

The description clearly states the tool's function: 'Get a live XRP to RLUSD conversion quote via the XRPL DEX.' It specifies the resource (XRP to RLUSD conversion) and the method (via XRPL DEX), which distinguishes it from siblings like get_xrp_price (general price) and get_dex_quote (generic DEX quotes).

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

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

The description provides clear usage context: 'Use before creating an RLUSD-denominated escrow or before claiming an escrow if you want to understand the current USD value.' It implies when to use but does not explicitly mention alternatives or when not to use it. This is clear context but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds substantial behavioral context: it lists the 12 constituent signals, explains score thresholds, mentions KYC-verified wallets can create escrows up to $10,000, and states it returns a full breakdown. This goes well beyond the annotations, giving the agent confidence about what the tool does and what to expect.

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

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

The description is well-structured and front-loaded: it states the purpose first, then the signal list, usage guidance, thresholds, and return info. Every sentence adds value, and the length is justified given the complexity. No redundancy or fluff.

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

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

The description is comprehensive for an agent to decide when to use the tool and what to expect. It covers the purpose, usage context, interpretation of results, and return format (full breakdown). Since an output schema exists, not detailing the return structure is acceptable. Nothing critical is missing.

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

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

The input schema already fully documents the single parameter (wallet_address) with 100% coverage. The description does not add parameter-specific details beyond the schema, but the schema itself is sufficient. Per the baseline rule, 3 is appropriate since the description does not need to compensate.

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: obtaining a wallet trust score (0-100) for any XRPL wallet. It specifies the exact resource (wallet) and the operation (get score), and it distinguishes itself from siblings like check_wallet_sanctions and check_wallet_kyc by combining 12 signals into a comprehensive risk metric.

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 usage context: 'Use this before accepting a job or creating an escrow to assess counterparty risk.' It also gives thresholds for interpreting scores, but does not explicitly mention alternatives or when not to use this tool vs. more specific checks. Lacks an explicit exclusion clause, though the context 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?

The description adds valuable behavioral details beyond the annotations: the challenge is one-time, expires in 30 minutes, no private key is ever transmitted, and the proof mechanism relies on an on-chain AccountSet transaction. This meaningfully informs an agent about how the tool behaves and what actions follow.

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

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

The description is well-structured and front-loaded with the core purpose, followed by the verification flow, expiry, and return values. The Returns list is slightly redundant given that an output schema exists, but every sentence otherwise contributes necessary context.

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

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

For a single-parameter read-only challenge request, the description is complete: it explains the cryptographic proof model, the exact next step, expiry, and returned fields. An agent has everything needed to invoke the tool and understand the expected workflow.

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

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

The input schema already documents the single wallet_address parameter at 100% coverage, including the expected r... format. The description does not add additional parameter-level semantics beyond that, 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 uses a specific verb ('Request'), a clear resource ('one-time verification challenge'), and a precise purpose ('prove ownership of an XRPL wallet'). It distinguishes itself from the sibling confirm_wallet_ownership by positioning itself as the first step and naming the follow-up call.

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

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

The description clearly states when to use it: before verifying wallet ownership, and it directs the agent to call confirm_wallet_ownership after broadcasting the transaction. It lacks explicit exclusions or comparison against alternative verification tools, but the usage context is unambiguous.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds value by explaining the return fields and the cached flag semantics, revealing that the price may be recently cached if the source was briefly unavailable.

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 filler: the main action, the practical use case, and the return format. It is compact, front-loaded, and 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 zero parameters, existing output schema, and safety annotations, the description is sufficient for an agent to invoke the tool correctly. It explains what the tool returns and when to use it, though it does not elaborate on external dependencies or data freshness beyond the cached flag.

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 no parameters and schema coverage is 100%, so there is nothing to add for parameters. The description still helpfully documents the outputs (usd, gbp, cached), which supports correct interpretation of results.

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: get the current live XRP price in USD and GBP. The XRP-specific focus and the bounty-conversion use case make it easy to distinguish from sibling tools like get_rlusd_quote or get_dex_quote without opening their schemas.

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

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

The description clearly explains when to use the tool: 'Use this to convert XRP bounty amounts to fiat before deciding whether a job is worth taking.' It gives strong contextual guidance but does not explicitly mention alternatives or when-not-to-use cases.

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

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

Annotations already provide readOnly=false and idempotent=false. The description adds meaningful context: the tool creates an escrow vault, returns a transaction the agent must sign, and the vault is only activated after a later confirmation step. It also clarifies that no manual XRPL transaction construction is required, which is useful behavioral information 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 front-loaded with the core purpose and uses a compact typical-flow list and return summary. Each section earns its place, though there is slight redundancy between the opening 'One-call shortcut' sentence and the following 'This combines...' sentence.

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

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

Given the tool's complexity—combining vault creation and transaction preparation—the description is complete enough: it explains the workflow, required signing step, confirmation dependency, and next-step evaluation. An output schema exists, so the return list is a helpful supplement rather than a required replacement.

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 input schema already documents all 8 parameters thoroughly, including the fee_hash payment detail and default cancellation window. The description does not add much parameter-level meaning beyond referencing the returned escrow_id and transaction, which is consistent with the baseline score of 3.

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

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

The description states a specific verb and resource: it 'register[s] an escrow vault' and returns a 'ready-to-sign' EscrowCreate transaction. It explicitly distinguishes itself as a combined shortcut for create_escrow_vault() + prepare_escrow(), making its role clear against the 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 gives clear usage context: use this when you want to hire and pay in one call and then sign/submit the returned transaction. It names the combined underlying functions and outlines the exact follow-up flow with confirm_escrow_transaction() and evaluate_escrow_work(), though it does not explicitly state when NOT to use the standalone 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 mark the tool as read-only, idempotent, and non-destructive, and the description adds valuable context beyond that: all bounties are backed by XRPL escrow and pay automatically on AI approval, OPEN vs LOCKED semantics are explained, and claiming an OPEN job triggers the referee to create on-chain escrow. 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 purpose, then uses labeled statuses, a numbered workflow, and a return-fields list to stay scannable. There is some redundancy, such as escrow creation appearing in both the OPEN bullet and workflow step 3, and 'Do the work' is filler, but overall the structure earns its length.

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

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

Given the annotations, full parameter schema, and output-shape listing, the description provides everything an agent needs to invoke the tool correctly and decide next steps: purpose, status semantics, a claim workflow, and the return fields (jobs, total, marketplace_url). The minor sibling ambiguity is a usage-guidelines issue rather than a completeness gap.

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

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

All three parameters (limit, category, min_bounty_xrp) are fully described in the input schema, so the description does not need to repeat them. The only added parameter-adjacent guidance, 'find a job where claimable=True,' refers to an output field rather than the input parameters. Baseline 3 is appropriate given 100% 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 opening sentence uses a specific verb and resource ('Browse open bounties on the AgentTrust marketplace') and the workflow positions it as the discovery step for autonomous agents. It does not explicitly contrast with the sibling list_open_jobs, and 'open bounties' sits slightly uneasily with the LOCKED status mentioned in the return/status discussion, so it stops short of a 5.

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

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

The description explicitly calls this 'the primary way autonomous agents discover work available on the protocol' and embeds it in a five-step workflow: list, get_escrow_info, claim_job, do the work, evaluate_escrow_work. It also warns not to attempt claiming LOCKED jobs. It gives clear context but does not name alternatives or state explicit when-not conditions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: listings show the poster's XRPL wallet, no bidding is required, and results include real_skills and demo_skills to signal demo listings. This goes beyond the annotations without contradicting them.

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

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

The description is well-structured with purpose, workflow, and return fields clearly separated. It is slightly longer than strictly necessary because the return field list may duplicate an existing output schema, but every section earns its place by supporting selection and invocation.

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 role, the direct-hire workflow, filtering guidance, and return shape. With complete schema coverage and read-only annotations, an agent has enough context to select and call the tool correctly. It lacks only an explicit note about all parameters being optional, but that is already visible in the schema.

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

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

Schema description coverage is 100%, so the input schema fully documents all four parameters including defaults and meanings. The description only adds a high-level 'filter by category/rate' mention, which is helpful but not necessary given the complete schema coverage. 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 function: browsing agents and humans offering skills on the AgentTrust marketplace. It distinguishes this from other market tools by emphasizing skill listings, direct hiring, and the escrow workflow, and it is immediately clear this is the skill-listing counterpart to list_marketplace_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 gives an explicit workflow: find a provider with list_marketplace_skills, then direct_hire, then create_escrow_vault. This is clear when-to-use guidance for direct hiring. It does not explicitly contrast with list_marketplace_jobs or other alternatives, but the workflow provides strong contextual usage direction.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: these are buyer requests with no escrow yet, and the listing shows budget_xrp, bid_count, category, and expiration. This goes beyond the annotations without contradicting them.

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

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

The description is well-structured with the purpose front-loaded, followed by context, a workflow, and a return summary. It is readable and scannable. Some workflow steps describe later tools like submit_bid() and award_job(), which adds context but is slightly beyond what is strictly needed for calling list_open_jobs.

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 listing function, the schema covers all optional parameters, annotations cover the safety profile, and the description lists the returned job fields. The main gap is the lack of explicit differentiation from closely related sibling list tools, but an agent can still determine correctly how and when to use 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?

All three parameters (limit, category, min_budget) are fully documented in the input schema with defaults, constraints, and descriptions, so schema coverage is 100%. The description does not add much parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Browse jobs posted on the AgentTrust job board that are open for bidding.' It clearly identifies this as a listing operation for buyer-request jobs with no escrow yet, which helps distinguish it from other list-type tools. However, it does not explicitly contrast itself with sibling tools like list_marketplace_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 workflow section explicitly places this tool as the first step: 'list_open_jobs() — find a suitable job.' This gives clear contextual guidance for when to call it and what follow-up actions are expected. It does not explicitly state when not to use it or compare it to list_marketplace_jobs/view_job.

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

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

Annotations already cover readOnly, idempotent, and non-destructive hints, so the bar is lower. The description adds useful behavioral details: it lists the return fields (name, wallet, verified status, domain) and explicitly notes that a register_url is returned if not found, giving insight into the not-found behavior. This exceeds the minimal baseline.

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

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

The description is concise and well-structured: a clear main statement, a brief contextual explanation, a practical use case, and a summary of return fields. Each sentence adds necessary information without redundancy, and the structure is easy to scan.

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

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

Given the output schema is not provided in the context, the description compensates by explicitly listing the expected return fields and the not-found case. It covers the key operational details an agent would need to decide whether to call the tool and interpret its result, though it could be slightly more detailed about error scenarios or edge cases.

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 a clear parameter description, so the baseline is 3. The description adds value by providing an example ('Ripple') and clarifying that the query can be either a company name or a wallet address, which helps disambiguate the accepted input beyond 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 clearly states the tool's function: looking up an organization in the AgentTrust XRPL NFT Issuer Registry, mapping company names to verified wallet addresses. It also specifies the registry's verification method (domain records) and the practical use case, 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?

The description provides an explicit when-to-use scenario: checking whether an NFT is issued by a legitimate organization before accepting it as proof of ownership or in an escrow. However, it does not mention alternative tools (e.g., get_nft_issuer_by_wallet) or when not to use this tool, so it falls slightly short of full guidance.

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

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

Annotations already indicate readOnlyHint=false and openWorldHint=true, so the write nature is known. The description adds that no fee is charged and no funds are held, and it discloses the return structure (status, job_id, expires_at, next_step). It does not mention idempotency or failure modes, but the annotations cover safety and the description gives enough operational 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: two sentences of purpose, one workflow sentence, and a return bullet list. It is front-loaded with the core action, then provides sequential context, and ends with expected output. No redundant or filler sentences; every line 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 8-parameter tool with a required buyer_address and a clear post-then-escrow workflow, the description covers the purpose, next steps, and return shape. It does not mention prerequisites (e.g., wallet verification) or uniqueness constraints on job_id, but the schema and annotations give enough for an agent to call it correctly. The output schema exists (not shown) and the description lists key return fields, so completeness is strong but not exhaustive.

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 each parameter is already documented (title, job_id, category, budget_xrp, buyer_name, description, expires_hrs, buyer_address). The description adds no extra parameter-level meaning beyond the workflow context. It implicitly suggests budget_xrp is optional via 'No fee, no funds held' but that's minor. Baseline 3 is appropriate since the schema carries the burden.

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

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

The description opens with a specific verb and resource: 'Post a job to the AgentTrust job board.' It clarifies it does not handle fees or funds, distinguishing it from payment/escrow tools like create_escrow_vault. The workflow mention of list_open_jobs, submit_bid, and award_job positions it clearly as the entry point for creating a job listing.

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 maps the job lifecycle: post_job → list_open_jobs → submit_bid → award_job → create_escrow_vault. It tells agents when to call this tool (to post) and what comes next, effectively excluding alternatives (e.g., direct_hire, hire_and_pay) that handle payments differently. It also notes 'No fee, no funds held' to signal that payment steps are handled elsewhere.

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 meaningful behavioral detail beyond the annotations: the tool does not submit the transaction, the buyer must sign it, and the result is a pre-filled dict with ledger sequence, fee, and condition. This clarifies the non-submitting, preparation-only nature of the tool.

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

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

The description is well-structured with a clear opening, workflow steps, and a returns list. It is slightly redundant with 'no XRPL library required' and 'the agent never has to construct an XRPL transaction manually,' but overall every section earns its place.

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

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

The description fully covers the precondition, the tool's role in the larger flow, the output shape, and the next step. Given the annotations, 100% schema coverage, and output schema, nothing essential is missing 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?

Schema description coverage is 100%, and the schema already documents each parameter including defaults and address formats. The description does not need to repeat parameter details, but it also does not add much parameter-specific meaning beyond mentioning escrow_id as an input from create_escrow_vault().

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

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

The description opens with a specific verb and resource: 'Build a ready-to-sign XRPL EscrowCreate transaction.' It clearly differentiates from the sibling workflow by positioning itself between create_escrow_vault() and confirm_escrow_transaction(), so an agent immediately knows what this tool is and is not.

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 the required ordering: call create_escrow_vault() first, then this tool, then confirm_escrow_transaction() with the tx hash. It gives clear context and workflow sequencing, though it does not explicitly contrast itself with the sibling submit_escrow_transaction.

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

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

Beyond the annotations, the description adds meaningful behavioral context: ratings are permanent and public, one rating per escrow per rater, and ratings directly affect a trust score (up to 15 pts). This is exactly the kind of consequence disclosure an agent needs before invoking a state-changing tool.

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

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

The description is compact and front-loaded: the first sentence states the core action, the second explains consequences and constraints, and the third gives explicit usage timing. No sentence is wasted or 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 6-parameter tool with full schema coverage, the description covers the essential context: when to call it, what happens on the counterparty's trust score, the one-per-escrow constraint, and the permanence/public nature. Since an output schema exists, not detailing return values is acceptable.

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 100% of parameter descriptions, including rating bounds, roles, and wallet address formats. The description reinforces the domain context (e.g., 'counterparty', 'rater', 'per escrow') but does not add significant new parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ('leave... rating'), a specific resource ('counterparty after a completed escrow'), and a clear purpose. It also names the downstream effect (AgentTrust Wallet Trust Score), which makes the tool's unique function immediately distinguishable from siblings like get_wallet_trust_score or evaluate_escrow_work.

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

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

The description explicitly says 'Call this after an escrow completes — whether it passed or failed — to build an honest reputation record.' This gives a clear temporal trigger and intent. It does not explicitly list alternatives or exclusion cases, so it stops short of a perfect 5.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond those hints by stating the full scope of the result ('all messages'), the ordering ('chronologically'), and the intended use case. This is meaningful behavioral disclosure for a simple read tool.

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

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

The description is concise and well-structured: the core action is in the first sentence, followed by return details and a practical usage tip. Every sentence adds value 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?

For a tool with one well-documented parameter, clear annotations, and an output schema, the description fully covers what an agent needs: what it does, what it returns, ordering, and when to use it. Nothing critical is missing.

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

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

Schema description coverage is 100% and the single parameter job_id is adequately described in the schema. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Fetch') and a specific resource ('message thread for a job'), and further specifies that messages are from buyers and workers, ordered chronologically. This clearly distinguishes it from siblings like view_job or send_job_message.

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

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

The description provides clear usage context: use it to catch up on clarifications or instructions before starting work or submitting a bid. It does not explicitly name alternative tools or state when not to use it, but the guidance is sufficient for this simple read operation.

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 safety (readOnlyHint false, destructiveHint false). The description adds behavioral context by stating messages are visible to both buyer and awarded worker, and that it's for in-platform communication, which adds value 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 two sentences, front-loaded with purpose, and every sentence adds value. No fluff, no repetition. It's efficient and 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?

Given an output schema exists and the tool is a simple send operation, the description covers purpose, visibility, and use cases. Nothing essential for an agent to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details beyond what the schema provides, such as explaining the sender_role or bid_id semantics. It relies on the schema, which is acceptable.

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 sends a message on a job thread, with specific purposes (clarifying requirements, sharing progress, negotiating). It distinguishes itself from read_job_messages by implication but does not explicitly name it, so it's clear but not maximally differentiated.

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

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

It provides clear when-to-use context (communication about deliverables, deadlines, scope changes) and implies it's for interactive communication between buyer and worker. It doesn't explicitly state when not to use it or name alternatives, 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 usefully reveals post-submission behavior: buyer review, award via award_job(), email/escrow notifications for humans, and no email for AI agents. However, it promises automatic notifications when including worker_email, while no parameter named worker_email exists in the schema (additionalProperties false), so that behavioral claim is unreliable.

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 structure is tight and front-loaded: purpose, workflow, human/AI guidance, returns. It is concise, though repeating return fields in prose is redundant given an output schema exists and the stray worker_email reference adds noise.

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 workflow, notification paths, and status-polling guidance are good coverage for a submit action. However, the worker_name/worker_email mismatch leaves a real invocation detail unresolved, and nothing clarifies whether bids are editable or withdrawable, so the description is not fully reliable on its own.

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

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

Schema coverage is 100%, so the baseline is 3, but the description erodes trust by telling agents to include worker_email while the actual schema property is worker_name and its own description mixes the two. It adds no reliable meaning beyond the schema for the required fields and creates ambiguity about how to enable notifications.

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 concrete verb+resource: 'Submit a bid on an open job posting.' It also distinguishes the tool from the buyer-side award_job() and the status-checking view_job(), so an agent can tell it apart from closely related siblings.

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

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

It explains the workflow (buyer reviews and awards via award_job()) and gives role-based guidance: human workers should include worker_email, AI agents should poll view_job instead. It does not explicitly list when not to use the tool (e.g., closed jobs), but 'open job posting' and the named follow-up tools 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It states that the tool activates a vault and avoids a confirm call, but it does not disclose side effects, irreversibility, permission requirements, or failure modes. 'Submit' and 'activate' are vague about what happens on success or failure, leaving the agent underinformed for a mutation.

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 front-loads the primary action and the key advantage (one-step activation). Every word serves a purpose, and there is no redundant phrasing.

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

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

The description, combined with the schema and an existing output schema, covers the basic purpose and parameters. However, it lacks contextual guidance about when this tool is appropriate (e.g., after calling create_escrow_vault), what happens if the blob is invalid, or any prerequisites. Given the tool's mutation nature, this is a meaningful gap.

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

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

Schema description coverage is 100%, and the parameter descriptions already explain what each parameter is. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific action: submit a locally-signed EscrowCreate transaction blob and activate the vault. It also distinguishes from the sibling confirm_escrow_transaction by noting no separate confirm call is needed, so the tool's unique purpose 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 phrase 'no separate confirm call needed' implies this tool replaces confirm_escrow_transaction, but it does not explicitly state when to use this tool versus alternatives like create_escrow_vault or confirm_escrow_transaction. No exclusions or prerequisites are given beyond the mention of a locally-signed blob.

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 covered. The description adds escrow-related usage context and return-field information but no additional side effects or edge-case behavior.

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 concise sections each earn their place: what the tool does, when to use it, and what it returns. There is no filler or repeated information.

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

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

With a 100%-covered schema, rich annotations, an output schema, and clear escrow usage guidance, the description is complete enough for an agent to select and call 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 description coverage is 100% and all three parameters, including required_metadata, are already described in the input schema. The description adds contextual framing but no new parameter-level semantic detail.

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

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

The description names a specific verb and resource: 'Verify that a wallet holds an NFT from a specific issuer, optionally matching metadata.' This clearly distinguishes it from sibling wallet-verification and issuer-lookup 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?

It provides explicit usage context: 'Use as an escrow delivery condition: before releasing payment, confirm the seller has transferred the correct NFT to the buyer's wallet.' It also notes automatic invocation by the AgentTrust AI evaluator and manual calling. It does not explicitly list alternative tools or when-not-to-use conditions, so it stops short of a 5.

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

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

The description discloses a meaningful side effect: verification 'contributes 10 pts to the wallet's trust score,' which aligns with readOnlyHint=false. It also explains the external dependency on the domain publishing a well-known file. Annotations already cover idempotency and non-destructiveness, so the description adds useful behavioral context without redundancy.

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 one-sentence purpose, a short mechanism explanation, and a clear return-value list. Every sentence adds relevant information 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?

For a two-parameter verification tool with a rich output description and annotations covering idempotency and side effects, the description is largely complete. It explains prerequisites, the verification mechanism, the trust-score impact, and return values. It could mention failure modes or when the verification would return false, but that is a minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the meaning of both parameters by explaining that the domain must publish an xrp-ledger.toml listing the wallet, but it does not add substantial new semantic detail beyond the schema's own parameter 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 uses a specific verb ('Verify') with a clear resource ('XRPL wallet is owned by a specific domain') and names the exact standard (XRPL Foundation xrp-ledger.toml). It distinguishes itself from related verification tools like confirm_wallet_ownership by focusing on domain-based verification via a published toml file.

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

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

The description implies when to use the tool: when a domain claims ownership of a wallet and publishes the required xrp-ledger.toml file. However, it does not explicitly mention alternatives or state when not to use it, leaving the agent to infer the distinction from sibling 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, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful behavioral context by explaining how to interpret status and awarded_bid_id, plus the return contents.

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 core purpose, followed by a usage note and a compact return summary. Every sentence contributes useful information 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?

For a single-parameter read-only tool with an output schema and rich annotations, the description covers the purpose, usage context, response contents, and special status handling. Nothing essential is missing.

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

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

The input schema already fully documents job_id with provenance (from list_open_jobs() or post_job()). The description adds further meaning by noting the job could be one the agent posted or bid on, which helps clarify valid job_id values.

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

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

The description clearly states a specific action ('View') and resource ('a job posting and all current bids'), which distinguishes it from sibling tools like read_job_messages or list_open_jobs. 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 explicitly says 'Use this to check the status of a job you posted or bid on,' giving a clear use case. It does not mention exclusions or alternative tools, but the guidance is sufficient for this read-only lookup.

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