xrpl-referee

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds meaningful behavioral context: it aggregates multiple checks in one call, returns a structured report with a 'proceed' bool and 'do_not_proceed_if' blockers, and gates fund locking. No contradiction exists between the description and annotations.

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

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

The description is compact and front-loaded: first sentence states the core purpose, the second lists scope, the third gives invocation timing, and the final sentences define output and safety behavior. Every sentence earns its place 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?

Given the full input schema, rich annotations, and presence of an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers what the tool does, when to run it, the output's top-level structure, and the critical action rule on proceed=false.

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

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

Input schema coverage is 100%, with each parameter already documented. The description reinforces how job_type and amount_xrp feed into recommendations and KYC checks, but it does not add substantial meaning beyond the schema descriptions, 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 'Single pre-flight check before locking funds in escrow' and enumerates the aggregated data sources: trust score, sanctions, KYC, NFT issuer registry, domain status, release conditions, escrow cap, and go/no-go rules. This clearly distinguishes it from individual sibling tools like check_wallet_kyc or check_wallet_sanctions by positioning it as a consolidated assessment.

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 'Run this before create_escrow_vault or hire_and_pay' and provides a concrete rule: 'If proceed is False, do not lock funds.' It gives clear invocation context, though it does not explicitly name alternative tools for when a user only needs one specific check.

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 are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds critical behavioral details: fee_hash is single-use (anti-replay protection), require_consensus triggers two-model agreement, and the response shape with criteria_failed for actionable feedback. This exceeds the annotation coverage and gives the agent essential context for safe invocation.

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: a purpose sentence, a prerequisite call, a response schema in a code block, and post-conditions. It is longer than average but every sentence adds value, and the core 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 tool with 5 parameters and an output schema, the description provides the necessary workflow, response interpretation, and the single-use caveat. It covers the consensus option and fee prerequisite, making it complete for an agent to call correctly.

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

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

Schema description coverage is 100%, so all five parameters are already documented. The description adds context like fee_hash formats (XRP vs. USDC) and reiterates the single-use nature, but most semantics are covered by the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

States a specific verb (verify) and resource (completed work against task specification). The purpose is unambiguous, but it does not explicitly distinguish itself from siblings like evaluate_escrow_work or assess_counterparty_and_job, which could overlap in function.

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 a clear workflow: call get_fees() first, then use audit_task, and interpret PASS/FAIL outcomes. However, it does not explicitly state when to use this tool instead of sibling tools, leaving some ambiguity about alternative selection.

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

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

It discloses important side effects beyond annotations: 'All other bids are automatically rejected' and 'No funds are held by the referee at any point.' It also explains the auth requirement via award_token and buyer_address, which is essential behavioral context for an agent deciding to call it. The annotations are consistent with these statements.

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 organized and front-loaded: main action first, immediate next step second, side effects next, and a brief return summary last. Every sentence adds useful operational information, and the Returns block is compact.

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 4-parameter action with an output schema, the description fully covers what it does, what side effects occur, what the agent should have on hand (award_token), and what to do next. Nothing essential is missing, and the return value is described even though an output schema exists.

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 adds workflow-level meaning: it identifies award_token as the value returned by post_job(), says to store it securely, and frames create_escrow_vault() as the consumer of the returned worker_address and agreed_xrp. This goes beyond the schema's field-level descriptions.

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

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

The description opens with a specific action and resource: 'Accept a bid and award the job to a worker agent.' It clearly distinguishes the tool as the bid-acceptance path, especially by naming the follow-up create_escrow_vault() step and stating that all other bids are rejected. This is unambiguous even alongside siblings like direct_hire or hire_and_pay.

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

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

The description gives clear workflow context: use this after posting a job and reviewing bids, then immediately create the bilateral escrow via create_escrow_vault(). It does not explicitly list exclusions or say when not to use it, but the intended placement in the job-award flow is clear enough.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds meaningful behavioral context beyond these: parallel scoring, results ranked by score descending, a rank field, a required $0.10 fee, and a return structure. It also signals the fee prerequisite via get_fees(), which is valuable execution 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 front-loaded with the core purpose and includes a useful Returns line. The use-case bullets are helpful but somewhat promotional, and the phrase 'open reputation layer for XRPL agents' adds little actionable information. Still, the overall structure is efficient and scannable.

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 paid batch tool, the description covers all critical context: fee and fee_hash acquisition via get_fees(), parallel execution, ranking, result shape, and maximum batch size. The annotations handle safety profile, and the output schema covers return values. Nothing essential for calling this tool correctly is missing.

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

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

The schema covers both parameters with 100% description coverage. The description echoes the maximum of 50 and the fee amount, but doesn't add new semantic meaning beyond what the schema already provides. The baseline of 3 applies here because the schema carries the load.

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

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

The description uses a specific verb ('Score') with a specific resource ('XRPL wallets') and clearly scopes the operation to batches of up to 50. It also names the ranking behavior, which distinguishes it from the singular get_wallet_trust_score sibling. The purpose is unmistakable.

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 lists clear use cases (rank candidates, screen shortlists, build directories, due diligence) and implies the batch context through 'up to 50 in a single call'. However, it does not explicitly contrast this with the single-wallet sibling tool or state when to prefer one over the other, so it stops 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 signal idempotent, non-destructive behavior. The description adds the Didit source and return fields, but does not explain potential side effects even though readOnlyHint is false, nor does it mention staleness, errors, or external API calls. There is no explicit contradiction with the annotations.

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

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

The description is compact, front-loaded, and every sentence adds value: the status check, the KYC implication, the false-branch instruction, and the return fields. It avoids unnecessary detail.

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 status check with an output schema, the description covers the return fields, the meaning of the result, the business consequence, and the exact next step if verification is missing. No important usage gap remains.

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 wallet_address is fully documented in the schema at 100% coverage with a clear XRPL address format. The description does not add much parameter-level meaning, 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: 'Check identity verification status for a wallet operator.' It clearly distinguishes this from sibling checks like check_wallet_sanctions by focusing on Didit KYC verification and the kyc_verified boolean.

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

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

The description explicitly instructs the agent on the follow-up action when kyc_verified is false: direct the operator to start_wallet_kyc(). It also provides context for when the result matters by explaining the escrow cap difference between verified and unverified wallets.

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 provided, the description carries the full behavioral burden and succeeds: it discloses plaintext seed exposure, transcript/log persistence, ledger-inactive status, inability to sign/submit transactions, EscrowCreate destination failure, trust score showing 0, and funding requirements. This is far beyond what the empty schema provides.

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 its length is largely justified by critical security warnings and activation constraints that would otherwise be absent. It is front-loaded with the core purpose and warning, uses bullets for scanability, and while some warning redundancy exists, it does not significantly hinder clarity.

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

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

For a zero-input tool with an output schema, the description is exceptionally complete: it covers production alternatives, safe use cases, funding options, ledger activation constraints, and downstream limitations. An agent has enough context to call it correctly and to explain the risks to a user.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter semantic gap to fill. The description still adds useful meaning about what is returned (the seed) and the security consequences, matching the zero-param 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 opens with a specific verb+resource: 'generate a new XRPL keypair and return the seed.' It also clarifies what the tool does NOT do (it does not create an active ledger wallet), which distinguishes it from related wallet tools and removes 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?

It explicitly says when NOT to use the tool (production), names the exact alternative (get_wallet_setup_guide), and scopes appropriate use to throwaway wallets, local development, or demos. It also gives concrete post-call guidance on funding the wallet, including a named sibling tool, fund_xrpl_wallet_via_coinbase.

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

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

Annotations indicate it's not read-only and is destructive (side-effectful), but the description adds extensive behavioral context: release modes, proof gates, fee structure, state transitions (e.g., PASS_AWAITING_NFT), webhook payload details, and max_submissions pricing. It goes well beyond the basic 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 long but well-structured with clear sections (Two release modes, White-label integration, Typical flow, Returns). It uses bullet points and steps effectively. Given the complexity of 24 parameters and multiple modes, the length is justified and not wasteful.

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 thorough: it covers purpose, both release modes, proof-gate configuration, fees, callback behavior, metadata echo, typical workflow, and return values. It also references sibling tools and provides enough detail for an agent to invoke the tool correctly without 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining interactions between parameters (e.g., nft_dvp mutually exclusive with require_nft_proof), fee implications of max_submissions, and providing examples for metadata. It also clarifies when certain params are required based on mode.

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 XRPL escrow vault' with explicit details about how funds release. It distinguishes itself from siblings like confirm_escrow_transaction and prepare_escrow by focusing on the creation step and referencing a specific workflow.

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

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

Provides a detailed typical flow (steps 1-5) and explains when to use the tool (after award_job). It also describes two release modes and proof-gate options, guiding the agent on parameter selection. However, it doesn't explicitly contrast with similar creation tools like prepare_escrow, but the workflow clarity compensates.

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?

The description discloses key behaviors beyond annotations: the auto-finish on PASS, the attempt limit mechanism with submission_limit_reached error, automatic ledger verification of tx hashes, the evaluate_token requirement, and the rate_counterparty instructions. It also includes complete response shapes for both PASS and FAIL. This adds significant context beyond the annotations (readOnlyHint=false, destructiveHint=true, etc.) and does not contradict 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 long but well-structured with clear sections and code blocks for response shapes. The first sentence is a concise purpose statement, and the information is logically organized. While it could be trimmed slightly (e.g., redundant mentions of the work field verification), the length is justified by the tool's complexity.

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

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

Given the tool's complexity (6 parameters, output schema, attempt limits, rate_counterparty instructions, resubmission flow), the description is remarkably complete. It covers the full evaluation lifecycle, error cases, follow-up actions, and related tools (purchase_extra_attempt, rate_wallet). An agent can call this tool correctly with the information provided.

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 descriptions for all 6 parameters (100% coverage). The description adds valuable context on the evaluate_token (buyer must share it) and clarifies the work field's auto-verification, though the schema already mentions that. It also explains the attempts logic tied to the tool's behavior, but not directly to parameters. This is above the baseline 3 because of the added context on evaluate_token.

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.' It explains the PASS/FAIL outcomes, the auto-release of payment, and the ledger verification of tx hashes. This distinguishes it from sibling tools like confirm_escrow_transaction or submit_escrow_transaction, which have different purposes.

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: it tells the agent when to call this tool (to submit work for evaluation) and what to do on PASS (payment releases, rate counterparty) and on FAIL (read criteria_failed, resubmit). It also mentions the alternative purchase_extra_attempt for when attempts are exhausted. However, it does not explicitly state conditions when NOT to use it, though the context strongly implies 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates the tool is a read-only informational resource ('Returns the AgentTrust trust model'), which is a meaningful behavioral trait. It also discloses the kind of content returned (guarantees, trust gaps, proof gates vs AI audit). It does not describe output format, but an output schema exists, so that burden is partially shifted.

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 and every word earns its place. It front-loads the core purpose, then adds the usage directive. No fluff, no repetition of the title.

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 informational tool with an output schema, the description is nearly complete. It explains what the tool returns and when to use it. It could arguably name the sibling alternative (e.g., recommend_release_conditions) for contrast, but the explicit 'read this before designing an escrow flow' guidance is sufficient context for an agent to select and invoke 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?

The tool has zero parameters, so there is no parameter semantics burden. The description adds value by explaining what the returned model contains, which is more useful than a bare 'Returns the trust model' statement. Baseline 4 is appropriate for a zero-parameter tool.

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

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

The description clearly states the tool returns the AgentTrust trust model and enumerates its content: guarantees, remaining trust gaps, and guidance on proof gates vs AI audit. It also includes a direct instruction to read it before designing an escrow flow, which distinguishes it from the many escrow-related 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 explicitly tells the agent when to use this tool: 'Read this before designing an escrow flow.' This is a clear usage directive that helps the agent select it over siblings like prepare_escrow, create_escrow_vault, or recommend_release_conditions. It also implies it is a prerequisite/read-only reference rather than an action tool.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses the HMAC-authenticated Coinbase v2 API usage, free-account compatibility, the credential-missing fallback behavior (returns a setup guide dict instead of throwing), the fact that Coinbase is no longer involved after the call, and the one-time human setup requirement. This is exceptionally transparent about side effects and prerequisites.

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 section headers, bullet lists, and numbered setup steps. It is front-loaded with the core purpose and each subsequent block earns its place by covering credentials, setup, and failure behavior without unnecessary repetition.

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

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

Given that an output schema exists, the description does not need to document return values. It covers prerequisites, environment variables, credential ownership, setup steps, failure behavior, and post-call state, making it fully sufficient for an agent to decide when and how to invoke the tool correctly.

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

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

Schema coverage is already 100%, but the description adds meaningful semantics beyond the schema: usd_amount's default is explained as covering 1 XRP reserve plus Coinbase fees and price variance, and the credential parameters are framed with ownership warnings. It also documents the required Coinbase API scopes, which is valuable context not present in the schema.

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

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

The description states a specific verb and resource: 'Buy XRP on Coinbase and withdraw it to an XRPL address in one call.' It further distinguishes itself as an 'ONRAMP tool only' and clarifies that escrow creation and settlement happen on XRPL, not Coinbase, so it is unambiguous against the many 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 context for when to use the tool: a USDC-native or fiat-funded agent bootstrapping an XRPL wallet without manual exchange steps. It also draws a boundary by saying Coinbase is used only to acquire XRP and nothing more, but it does not explicitly name alternative tools or spell out when not to use it beyond that boundary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the quote is 'live,' the worker_address is used for trustline checking, and the response includes slippage_warning and trust_line_instructions. This helps the agent anticipate conditional behavior without contradicting annotations.

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

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

The description is three compact sentences with no filler: the main purpose, a usage context sentence, and a concise return-field list. The most important information is 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?

For a simple read-only quote tool with two well-documented parameters, rich annotations, and an output schema, the description is complete. It tells the agent when to use it, what it returns, and how trustline status factors in. 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%, so the schema fully documents both parameters. The description does not add new parameter-level meaning, but it does clarify the purpose of worker_address indirectly through the trustline-related return fields. This meets the baseline for fully covered schemas.

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: 'Get a live XRP to RLUSD conversion quote via the XRPL DEX.' This clearly states the operation and distinguishes it from sibling tools like get_xrp_price and get_rlusd_quote by specifying the DEX route and the exact asset pair.

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 the tool: 'before creating an RLUSD-denominated escrow or before claiming an escrow if you want to understand the current USD value.' It does not name explicit exclusions or alternatives, but the context is clear enough for an agent to decide when this tool is appropriate.

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

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

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond the annotations: fees and escrow limits may change, the tool is the single source of truth, and it returns structured categories needed before paid calls. It does not go as far as disclosing rate limits or failure modes, but those are less critical for a zero-parameter read-only endpoint.

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 efficiently structured: a one-sentence summary, a clear usage warning, and a bulleted breakdown of return categories. Every line adds decision-relevant information, and the most important guidance—call before paid endpoints and do not hard-code values—is front-loaded.

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

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

For a read-only, zero-parameter tool with a strong output schema and descriptive annotations, the description is fully complete. It covers when to call, why it is authoritative, and what each returned section means, leaving no gap an agent would need to resolve before invoking the tool.

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

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

The tool has zero parameters, and the schema is empty, so there are no parameter semantics to clarify. Per the baseline for zero-parameter tools, a 4 is appropriate because the description instead clarifies the meaning of the returned fields, which is the only semantic ambiguity that matters here.

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: 'Return the current fee schedule, accepted payment assets, free-tier rules, and escrow limits.' It clearly enumerates the tool's full scope and distinguishes it from fee-related siblings like get_xrp_price by covering the broader fee/escrow/payment policy rather than just a price tick.

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 usage directive: 'Call this before calling any paid endpoint.' It also establishes this tool as the authoritative source and warns against hard-coding fee amounts or escrow caps, which tells an agent when it must consult this tool and how to treat its results.

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?

With no annotations, the description carries the full burden. It discloses that the seed stays in the agent's environment, that AgentTrust only sees public address and signed transactions, and that create_agent_wallet has the insecure behavior of returning a seed in plaintext. It does not explicitly state 'this tool has no side effects' but 'returns a guide' strongly implies an informational, read-only operation.

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

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

The description is a compact three-part structure: what it returns, when to use it, and why it's safer than the alternative. Every sentence earns its place even though the second and third paragraphs restate partially overlapping information.

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

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

For a no-parameter informational tool with an output schema, the description provides the key context: purpose, usage, and security trade-off versus the sibling. It could mention what the output guide contains, but that is fairly covered by the output schema and the description's overall scope is sufficient.

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

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

The tool has zero parameters with 100% schema coverage, so the description needs to explain no parameters. Nothing about parameter semantics is missing; a 4 is appropriate for a parameter-less functional tool.

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

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

The description names a specific verb and resource — 'returns the recommended production wallet setup' — and explicitly contrasts itself with create_agent_wallet(), so an agent can distinguish it from siblings without guessing.

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

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

It gives a direct instruction with a condition: 'Call this instead of create_agent_wallet() when building a production agent,' and explains the security rationale that justifies the choice. This is explicit, actionable 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 a safe, read-only, idempotent operation, and the description adds substantial behavioral context: rate limit of 20 calls/hour/IP, free querying, score bands, KYC implications, and the return of a full breakdown. This goes well beyond the structured annotations.

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

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

The description is structured with clear line breaks, front-loads the core purpose, and every sentence adds actionable information: signals, pricing, rate limits, alternatives, score interpretation, and return format. It is long but dense and well-organized.

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

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

With an output schema present and annotations covering safety, the description supplies all necessary operational context: cost, rate limits, alternative tool routing, score meaning, and KYC consequences. Nothing critical 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?

Schema coverage is 100% and the single parameter wallet_address is already described as 'The XRPL wallet address (r...) to score.' The description reinforces that any wallet can be scored but does not add significant parameter-level detail beyond the schema.

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

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

The description clearly states the tool 'returns a 0–100 trust score for any wallet' on the XRPL, with a specific verb and resource. It also distinguishes itself from sibling batch_wallet_trust_scores by naming that alternative directly.

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 strong usage context: it is free, rate-limited, and explicitly directs users to batch_wallet_trust_scores for multiple wallets. It does not explicitly contrast with related single-signal tools like check_wallet_kyc or check_wallet_sanctions, but the overall guidance 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?

The description explains the compound behavior: it registers a vault and returns a ready-to-sign transaction, requiring the agent to sign, submit, and confirm before the vault activates. It also discloses proof-gating behavior, webhook/callback behavior, and the return payload, which go well beyond the annotations.

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

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

The description is well organized with a lead summary, proof-gate context, white-label bullet points, a numbered typical flow, and an explicit return list. It is long but every section earns its place for a 17-parameter orchestration 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 an output schema and a fully described input schema, the description adds the missing procedural context: signing the transaction, confirming it, and later evaluating work. It is complete enough for an agent to invoke and follow through the 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?

Schema coverage is 100%, so the schema already documents every parameter. The description adds high-level grouping of proof-gate parameters and notes white-label use of callback_url and metadata, but this mostly restates schema descriptions rather than adding new meaning.

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

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

The description opens with a specific verb and resource: 'register an escrow vault AND get the ready-to-sign transaction,' and explicitly names the two sibling operations it combines (create_escrow_vault + prepare_escrow). This makes the tool's role unmistakable and distinct from those 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 clearly positions the tool as a one-call shortcut that combines create_escrow_vault() and prepare_escrow(), and gives a typical flow with downstream confirm_escrow_transaction() and evaluate_escrow_work(). It does not explicitly state when to avoid it or when to use the individual calls instead, so it stops short of a full when-to-use/when-not-to-use guide.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe to call. The description adds valuable context beyond annotations by explaining verification methods (domain records and on-chain AccountSet) and the meaning of each status value. It also clarifies the open-world nature by warning that missing results should not be treated as approval. This goes beyond what annotations already provide, meriting a 4.

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 in the first sentence. It uses bullet points for statuses, which improves scannability, and every sentence adds value—from usage guidance to result interpretation to status definitions. No redundant fluff; it is appropriately sized for the complexity of 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?

For a read-only lookup tool with a single parameter and a rich output schema (not shown but referenced as including fields like verified_at, verified_by, toml_url, accountset_tx_hash), the description is comprehensive. It covers purpose, usage, result interpretation, status meanings, and safety caveats. An agent has everything it needs to decide when to use it and how to interpret the results, making it complete for its complexity.

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

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

The schema already describes the single parameter 'query' as a company name or XRPL wallet address with an example. The description reinforces this by clarifying it can be either a company name or wallet address and mentions the registry maps real-world names to wallets. It adds a bit more context about the parameter's role in the broader verification process, but the schema coverage is already high (100%), so the description's added value is modest but real.

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

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

The description clearly states the tool's purpose: to look up an organisation in the AgentTrust XRPL NFT Issuer Registry, mapping company names to verified wallet addresses. It distinguishes itself from the sibling get_nft_issuer_by_wallet by specifying it can query by name or wallet address, whereas the sibling is wallet-specific. This precision helps an agent select the correct tool.

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

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

The description explicitly states when to use this tool: to verify if an NFT was issued by a legitimate organisation before accepting it as proof of ownership or as a delivery condition in an escrow. It also provides critical guidance on how to interpret results, including not treating missing results as implicit approval and being cautious with statuses like 'public' and 'disputed'. This is stronger than typical usage guidance.

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

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

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?

With annotations already covering read-only and destructive hints, the description adds valuable behavioral context: the exact fee, payment method and address, and the return value (updated attempts_remaining count). It does not mention idempotency or failure modes, but the annotation idempotentHint=false and the description's 'one additional attempt' phrasing cover the key 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?

Approximately 90 words, well-structured with a clear opening statement, background context, usage trigger, and fee details. Every sentence contributes and the most critical information (purpose and when to use) 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 paid mutation tool with two well-documented parameters, an existing output schema, and annotations covering safety, the description provides all necessary context: the trigger condition, payment details, and a preview of the return value. No critical information is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100% and the parameter descriptions already explain the fee hash and escrow_id thoroughly. The description adds no new parameter-level meaning beyond restating the same information in prose, so it meets the baseline of 3 without exceeding it.

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

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

The description opens with a specific verb and resource: 'Purchase one additional submission attempt for a vault that has hit its limit.' It clearly distinguishes this tool from siblings like evaluate_escrow_work and create_escrow_vault by naming the exact trigger condition and the complementary workflow.

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

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

Explicitly states when to use: 'When evaluate_escrow_work returns error "submission_limit_reached", call this tool...' It also provides context about default attempt limits and the next step (resubmit with evaluate_escrow_work), leaving no ambiguity about the intended flow.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns recommendations rather than executing an action, which implies no side effects, but it never explicitly states that no escrow or transaction is created, and it does not mention permissions or failure 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?

The description is front-loaded with the core outcome, followed by a compact example list that earns its place. There is no filler or redundant repetition of the title or schema.

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 input semantics and the high-level contents of the recommendation. It is complete enough to invoke correctly, though it leaves minor gaps around unknown job types and explicit side-effect confirmation.

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 0%, but the description compensates by defining job_type as 'job or deliverable type' and providing nine concrete examples such as 'software development', 'NFT art', and 'invoice payment'. It does not specify accepted value format or fallback behavior, but it gives an agent solid grounding.

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-resource pair: 'returns recommended escrow release conditions' and names exactly what the agent receives (proof gates, AI audit toggle, example parameters). It is clearly distinct from sibling tools that prepare, audit, 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 establishes clear context for use: when you have a job or deliverable type and need recommended release conditions. The example list helps an agent recognize valid inputs, though it does not explicitly name alternatives or state when not to use this tool.

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

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.), it discloses the fee, payment assets, return value (verification_url), required external browser action with Didit, automatic notification, resulting kyc_verified status, and the $10,000 escrow unlock. This fully explains the consequences of calling 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 appropriately sized for a multi-step process. Each sentence serves a purpose: what it does, prerequisite steps, payment details, return behavior, outcome, and follow-up. Information is front-loaded with the core action.

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

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

For a tool with a multi-step external identity verification flow, the description is complete: it covers prerequisites, method of payment, output, what the user needs to do, automatic notifications, and post-call verification. No critical gap that would prevent an agent from invoking 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% and the schema already documents both parameters well. The description adds meaningful process context by clarifying that fee_hash is the tx hash of the $0.50 payment and that wallet_address is the XRPL address to verify, linking parameters to the workflow. This is a slight enhancement over the schema 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 states a specific verb and resource: 'Start a Didit identity verification session for a wallet operator' with the $0.50 fee context. It is clearly distinct from sibling tools like check_wallet_kyc (status check) and get_fees (fee lookup), so an agent can differentiate without opening 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?

Provides explicit sequencing: 'Call get_fees() first to get the current fee amount and accepted assets', then pay and pass the tx hash. It also names the follow-up tool: 'Safe to call check_wallet_kyc() afterwards to confirm status.' This gives clear when-to-use and alternative guidance.

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

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

The description 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.