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 real behavioral context beyond that: it is an aggregator of eight external checks, it emits a top-level 'proceed' bool plus a 'do_not_proceed_if' blocker list, and it gates the downstream fund-locking decision. It stops short of disclosing latency, cost, or auth requirements for the underlying checks.

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?

Front-loaded with the purpose, then the aggregation scope, then the return contract and the gating rule. Four tight sentences with no filler; the enumeration of aggregated signals is long but each item is a distinct capability that justifies the tool's existence over its siblings.

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?

An output schema exists and the description still correctly summarizes the key return fields ('proceed' bool and 'do_not_proceed_if' list) plus the decision rule. Combined with annotations covering safety and a fully documented schema, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% and all four parameters (job_type, amount_xrp, worker_address, nft_issuer_query) are already well documented in the schema, including how each feeds the assessment. The description adds no parameter-level syntax or format detail, so the baseline of 3 is correct when 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?

States a specific verb and resource ('single pre-flight check before locking funds in escrow') and enumerates exactly what it aggregates: trust score, sanctions, KYC, NFT issuer registry, domain status, release conditions, escrow cap, go/no-go rules. This clearly distinguishes it from sibling point-checks like check_wallet_kyc, check_wallet_sanctions, and get_wallet_trust_score.

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?

Gives explicit ordering guidance ('Run this before create_escrow_vault or hire_and_pay') and an explicit conditional action ('If proceed is False, do not lock funds'). The agent knows both when to call it and what to do with the result, with no inference required.

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?

Goes well beyond the annotations (readOnly=false, idempotent=false, openWorld=true, destructive=false) by disclosing the fee-gating prerequisite, the anti-replay single-use nature of fee_hash (consistent with non-idempotent), and the semantic contract of the verdict/status/criteria_failed fields. This is exactly the behavioral context an agent needs before invoking a paid, non-idempotent 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?

Front-loads purpose and prerequisite before the response block, and the PASS/FAIL handling is actionable. The embedded JSON response shape is largely redundant with the existing output schema, which is the one inefficiency; the rest of the text 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 paid, AI-driven, non-idempotent verification tool with a rich output schema, the description supplies everything an agent needs: prerequisite call, anti-replay constraint, and how to interpret PASS vs FAIL. Return values are already covered by the output schema, so no further explanation is required.

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

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

Schema description coverage is 100%, so task, work, fee_hash, task_category, and require_consensus are all already documented in the schema. The description adds no further parameter meaning (it never mentions task_category rubrics or the require_consensus option), 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?

States a specific verb+resource: 'Verify whether completed work meets a task specification using AI.' An agent can tell this is an evaluation/verification tool, distinct from job-listing or payment tools. However, it does not differentiate itself from the closely related sibling evaluate_escrow_work, which appears to serve a similar verification role.

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?

Gives an explicit prerequisite ('Call get_fees() first to get the current fee amount and accepted assets') and conditions the workflow on outcomes ('On PASS: proceed to payment...', 'On FAIL: read criteria_failed...'). It stops short of naming when to use this tool versus alternatives such as evaluate_escrow_work, so it lacks true alternative routing.

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 indicate a mutating, open-world, non-idempotent operation. The description adds valuable behavioral details beyond the annotations: all non-awarded bids are rejected, no referee funds are held, the escrow is created directly between buyer and worker, and the award_token from post_job() must be stored securely.

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 and front-loaded with the core action. Each subsequent sentence adds concrete workflow or behavioral information 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's complexity and the presence of an output schema, the description provides the necessary context: next step after awarding, token provenance, fund-handling model, and automatic rejection of other bids. Nothing critical for correct invocation appears to be 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 already documents all four parameters. The description adds meaningful provenance and security context for award_token by explaining that it comes from post_job() and must be stored securely, which goes beyond the schema's bare description.

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: 'Accept a bid and award the job to a worker agent.' It is immediately clear what the tool does. However, it does not explicitly differentiate itself from other hiring-related siblings such as claim_job, 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: it should be used after bids exist and before creating the bilateral XRPL escrow via create_escrow_vault(). It also notes that all other bids are automatically rejected. It stops short of naming explicit alternatives or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the $0.10 fee (XRP or RLUSD) and the parallel, ranked-descending output behavior. It does not explain why the operation is non-idempotent despite being read-only, which is the one notable behavioral gap.

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?

Front-loaded with the core capability, batch limit and fee, then organized into scannable use-case bullets. The explicit 'Returns:' block is somewhat redundant since an output schema exists, which is the main wasted line.

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 annotations, a 100%-covered schema and an output schema present, the description supplies the fee prerequisite and ranking semantics an agent needs to call it correctly. Minor gaps remain: it doesn't say how partial failures or invalid addresses within the batch are handled.

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 both parameters are fully documented in the schema, including the 50-address cap and the fee_hash payment details, so baseline 3 applies. The description's mentions of 'up to 50' and the $0.10 fee simply restate what the schema already says rather than adding new semantics.

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

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

States a specific verb, resource and scope: 'Score up to 50 XRPL wallets in a single call', which immediately separates it from the single-wallet sibling get_wallet_trust_score. It also names the batch limit, parallel execution, and ranking behavior, so an agent knows exactly what the call produces.

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?

Four concrete use cases (rank candidates, screen bidders, build directories, pre-hire due diligence) give clear context for when this tool applies. However, it never states when NOT to use it, nor explicitly names the single-wallet alternative for one-off lookups.

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

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

The description goes well beyond the annotations by disclosing the consequence of the result ($10,000 escrow cap when verified vs. the default $3,000), the cost of the downstream KYC flow, and the returned fields. One tension is left unexplained: the annotations set readOnlyHint=false, while the text reads like a pure status read, and the description never clarifies whether the check itself writes or caches anything.

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

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

Three short, front-loaded paragraphs with no filler: purpose first, then the consequence, then the fallback action. The final 'Returns:' line is mildly redundant given an output schema exists, but it is brief and harmless.

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

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

For a one-parameter read-style tool with an output schema, the description covers purpose, outcome thresholds, and next steps, so an agent can call it correctly. It leaves the readOnlyHint=false annotation unexplained and does not position itself against the other wallet-status checks, which are the only real gaps.

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

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

There is a single parameter and schema description coverage is 100%, so the schema already documents wallet_address fully. The description adds no format or constraint detail beyond the schema (the 'r...' address convention lives in the schema), so 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 and resource: 'Check identity verification status for a wallet operator.' It is clearly distinguishable from the adjacent wallet-checking siblings (check_wallet_sanctions, get_wallet_trust_score) because it names KYC/Didit identity verification explicitly and defines the resulting state (kyc_verified).

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 concrete usage branch: if kyc_verified is false, route the operator to start_wallet_kyc() for the $0.50 verification flow. That is actionable routing, though it does not say when NOT to use this tool versus the other wallet-status siblings (sanctions, trust score), so the alternative-selection guidance is incomplete.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive traits, but the description adds genuinely useful context beyond them: data comes from US Treasury, is cached for 24 hours, and the call degrades gracefully rather than raising when the list is unavailable. It does not specify what the degraded response contains, which keeps it short of a 5.

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

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

Three short paragraphs, each front-loaded with its key fact (what it does, data freshness, failure behavior). No filler sentences; every line carries information an agent can act on.

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

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

With an output schema present, the description need not explain return values, and it covers the remaining essentials: data provenance, cache staleness, failure mode, and the downstream consequence of a hit. Nothing an agent needs before calling 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?

Only one parameter and schema description coverage is 100%, so the schema already documents the wallet address argument fully. The description adds no format detail beyond what the schema and the 'r...' hint provide, 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?

Specific verb ('Screen') plus precise resource ('an XRPL wallet address against the US OFAC SDN sanctions list'), with the data source named. It is clearly distinguishable from the sibling check_wallet_kyc, which covers a different compliance regime.

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

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

Usage is implied rather than stated: it explains that sanctioned wallets cannot create or participate in AgentTrust escrows and score 0, which hints at pre-escrow screening. However, it never explicitly says when to call this versus check_wallet_kyc or get_wallet_trust_score, nor does it state any ordering or prerequisite.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the bar is lower. The description goes further by disclosing the immediate-award effect, absence of buyer approval, webhook notification, and the required escrow follow-up — genuinely useful state-change 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?

Front-loaded with the core action and its precondition, then a compact numbered workflow (claim → prepare_escrow → sign → evaluate_escrow_work) that carries no wasted prose. Well sized for the amount of context an agent needs.

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

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

An output schema exists, so return values need not be described. The description instead supplies the missing piece an agent needs for a multi-step escrow flow: the ordered sequence of follow-up calls and who performs each one.

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 job_id, worker_address, worker_name and worker_email. The description adds only the claimable=True constraint, which is already stated in the job_id schema text, so this is the baseline 3.

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

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

States a specific verb and resource (claim an open bounty job) and immediately distinguishes it from the bid/award cycle, which is exactly how the sibling tools submit_bid and award_job operate. An agent can tell which route to take without opening any schema.

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 precondition is explicit ('Only works on jobs where claimable=True') and the opening clause contrasts this with the bid/award alternative. What is missing is a direct pointer naming the alternative tool for non-claimable jobs, so it falls just short of the 5 bar.

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

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

Annotations already cover readOnly=false, idempotent=true, openWorld=true, destructive=false. The description adds genuine behavioral context beyond them: the referee caches the escrow sequence number so the worker need not supply it when claiming payment. That caching side-effect is not derivable from annotations or schema.

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

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

Three short sentences, front-loaded with the action, then the timing precondition, then a useful side-effect note. No sentence is redundant and nothing is buried.

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?

An output schema exists, so return values need no explanation, and the description supplies the sequencing precondition plus the sequence-number caching behavior. It could be fuller on failure/idempotency edge cases (e.g., what happens on a duplicate hash), but it is complete enough 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 coverage is 100%, so tx_hash (64-char hex EscrowCreate hash) and escrow_id (receipt from create_escrow_vault) are already fully documented. The description only indirectly touches semantics via the sequence-number caching note; per the rule, a 100%-covered schema sets the baseline at 3.

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

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

States a specific verb and resource: 'Register the on-chain EscrowCreate transaction hash with the referee.' An agent understands this records a transaction hash, and the mention of EscrowCreate implies sequencing relative to submit_escrow_transaction. It does not explicitly name that sibling as the alternative, so it falls just short of full differentiation.

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

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

Gives a clear precondition: 'Call this after submitting the EscrowCreate transaction on XRPL.' This tells the agent the ordering dependency. It stops short of naming explicit alternatives or negative conditions (e.g., what to do if the transaction already failed).

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 mark this non-read-only, non-idempotent and non-destructive, but give no detail; the description fills that gap by disclosing the on-chain lookup, source check, memo validation, that a WalletVerification record is written, and the +8 trust-score reward. It stops short of describing failure modes (bad memo, reused tx) or why repeat calls are non-idempotent.

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

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

Two tight sentences: the first names the operation and its input, the second walks the verification pipeline and outcome. Every clause carries information and the outcome 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?

An output schema exists, so return-shape explanation is unnecessary, and the description covers the flow and persisted side effect well. The remaining gap is sequencing — the agent must infer that a challenge and broadcast precede this call — and unstated behavior on verification failure.

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 three parameters, including the optional issuer_id, are already documented in the schema. The description alludes to the tx and wallet but adds no format or constraint detail beyond what the schema states.

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 and resource ('Complete wallet ownership verification') and pins the mechanism ('XRPL AccountSet transaction'). It is clearly distinguishable from nearby siblings like verify_wallet_domain, verify_nft_ownership, and check_wallet_kyc because it names the AccountSet/memo challenge path.

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 'using the ... transaction you broadcast' implies the prerequisite that a challenge was already obtained and a tx submitted (presumably via get_wallet_verification_challenge), but the sibling is never named. There is no explicit when-not-to-use or statement of what to do if no tx has been broadcast yet.

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 delivers: the seed is returned in plaintext and will leak into transcripts/logs, the wallet is NOT active on the ledger, a 1 XRP base reserve is required, and it enumerates the concrete consequences of not funding (cannot sign/submit, cannot receive EscrowCreate, trust score shows 0).

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?

Front-loads the core action before the warnings, and each block (alternative, appropriate use, funding requirement) is purposeful. There is minor redundancy between the transcript warning and the 'NEVER paste the returned seed into a chat' line, and the bulleted pre-funding list is slightly verbose for a tool with no inputs.

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?

An output schema exists, so return-value documentation is unnecessary, and the description fully covers the safety profile, alternative tool, and post-creation state. An agent has everything required to decide and 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?

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline for a parameterless tool applies; no additional parameter meaning is needed or missing.

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 and resource: 'generate a new XRPL keypair and return the seed.' It also distinguishes itself from the sibling get_wallet_setup_guide() by labeling itself a convenience tool versus the secure production path.

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 gives when-to-use ('throwaway wallets, local development, or quick demos'), when-not ('NOT RECOMMENDED FOR PRODUCTION'), and names the alternative (get_wallet_setup_guide()) with the reason. Nothing is left to inference.

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

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

Annotations declare the safety profile (destructive, non-idempotent, open-world), and the description adds genuine operational context beyond them: the $0.10 protocol fee and free-tier eligibility, per-slot cost for max_submissions above 3, the PASS_AWAITING_NFT state transition and follow-up nft-offer call, webhook event set, and the nft_dvp / require_nft_proof mutual exclusion. It does not spell out the refund/expiry/dispute path beyond cancel_after_hrs, so a 5 is not warranted.

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?

Front-loaded with the one-line purpose, then scoped sections for proof gates, release modes, and white-label integration. For a 24-parameter tool the length is justified, and each bullet carries distinct information. Minor redundancy between the proof-gate paragraph and the per-parameter descriptions keeps it from being maximally tight.

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?

An output schema exists, so return values need no prose. Given 24 parameters, the description covers what the schema cannot: pricing and free-tier logic, mode selection, gating rules, webhook payload contents, and state-machine side effects. Nothing an agent needs to invoke this correctly appears to be missing.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description clearly earns above that by grouping the proof-gate params (require_nft_proof / required_nft_issuer / nft_dvp / required_domain / required_vc_issuer_did) and explaining how require_ai_audit interacts with them and with proof_policy. It adds conceptual meaning (which params form a gate set, which combinations are required) rather than restating field text.

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

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

The opening sentence gives a specific verb and resource ("Create an XRPL escrow vault") and immediately explains the core behavior: funds release to the worker on a passing submission. It also lays out the two release modes, which orients the agent well. It never names the nearby siblings it must be picked over (prepare_escrow, hire_and_pay, direct_hire), so sibling differentiation is left implicit.

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?

Strong conditional guidance: default AI-audit mode vs. require_ai_audit=False proof-gate-only mode, with an explicit precondition (at least one proof gate) and a use case (machine-verifiable deliverables). callback_url and metadata are each tied to a concrete scenario (white-label/headless integration, reference-ID round-tripping). No explicit "do not use this when…" or named alternative tool, which keeps it out of 5 territory.

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

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, so the write nature is known. The description adds genuinely non-obvious behavior: an out-of-band on-chain payment is required first, the listing lasts 30 days, and the result is visible both in the marketplace UI and to agents via list_marketplace_skills. It stops short of saying what happens on duplicate skill_id or listing expiry.

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

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

Three short blocks, front-loaded: purpose, then prerequisite, then downstream effects. Every sentence carries information an agent needs before invoking; nothing is filler.

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

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

For a 10-parameter creation tool with an output schema and full schema coverage, the description covers the two things structured data cannot: the mandatory pre-payment step and the visibility/duration of the created listing. Return values are handled by the output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description earns above baseline by tying the required fee_hash parameter to a concrete workflow step (the 64-char XRPL tx hash of the listing fee), which gives that field operational meaning the schema alone only partially conveys.

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 (list), resource (a skill on the AgentTrust marketplace), and scope (30 days) in the first sentence. It also implicitly distinguishes itself from the sibling list_marketplace_skills by naming that tool as a downstream consumer of what this creates.

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 concrete precondition sequence: pay $0.10/month to a named XRPL address and pass the transaction hash as fee_hash before calling. It does not, however, say when to prefer this over alternatives like post_job or direct_hire, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, which for a tool named 'direct_hire' is surprising, and the description resolves that tension: 'No funds move — you still create the escrow yourself via create_escrow_vault().' It names the follow-up tool, adding real context beyond the annotations. It stops short of noting any auth/rate concerns, so a 4 rather than 5.

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?

Front-loads the action, then the usage condition, then the return value, then the crucial caveat about funds. Every sentence earns its place and there is no filler.

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

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

Even though an output schema exists, the description helpfully summarizes the payload (wallet address + escrow instructions) and flags the no-funds-move behavior an agent could otherwise misread from the name. Nothing needed 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?

Single parameter with 100% schema coverage that already documents 'the skill listing ID from list_marketplace_skills() e.g. SKILL-PY-001.' The description adds no format or constraint detail 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?

States a specific verb+resource ('Get the wallet address and hiring details for a skill listing') and immediately differentiates from the job-board path ('skipping the job board entirely'). An agent can distinguish this from siblings like submit_bid/award_job/list_marketplace_skills without opening a schema.

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?

Gives an explicit trigger ('when you've found a skill provider via list_marketplace_skills()') and an explicit exclusion ('without going through the bid/award process'). The prerequisite tool is named, leaving nothing to inference.

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?

Goes well beyond annotations (destructive/non-idempotent/openWorld): describes attempt consumption (3 default, 1–10 via max_submissions), the exact vault-lock error 'submission_limit_reached', the PASS_AWAITING_NFT state transition, atomic two-leg settlement, and the rate_counterparty field. This is rich operational context an agent cannot infer from structured fields.

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?

Well front-loaded and organized with clear section headers, but it is very long (~450 words) and includes two full response-shape blocks even though has_output_schema=true, so return values are documented twice. Those blocks consume significant space without adding the value the schema already provides.

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 destructive, state-mutating escrow evaluation tool with NFT DvP edge cases, the description covers the success path, failure feedback loop, attempt exhaustion, unlocking, and the rating follow-up. Nothing needed to call it correctly in either the standard or DvP flow 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 already documents all six parameters, including work, escrow_id, task_category, evaluate_token, evidence_links and require_consensus. The description largely restates the work-field auto-verification already in the schema and discusses max_submissions (a parameter of other tools), adding little new per-parameter meaning. 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?

States a specific verb+resource ('Submit proof of completed work against an existing escrow vault') and immediately clarifies the downstream effect (auto payment release, no EscrowFinish needed). This clearly separates it from sibling submission/confirmation tools like submit_escrow_transaction and confirm_escrow_transaction.

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?

Explicit when-to-use and alternatives: identifies the EscrowFinish path as unnecessary on PASS, names purchase_extra_attempt for unlocking an attempt, and get_batch_dvp_payload for the NFT DvP flow. Also instructs how to resubmit on FAIL and when to call rate_wallet().

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?

No annotations are provided, so the description carries the full burden and largely meets it: atomicity ('both legs succeed or both revert — no settlement gap'), the required vault state, the seller-side prerequisite, and a 4-step buyer workflow that makes clear the tool only produces JSON to be signed. It omits auth/permission or rate-limit details, so not a 5.

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?

Front-loaded with the one-line definition, then organized into modes, prerequisites, and a numbered workflow that maps to the actual call sequence. The prose is a little dense in places, but sections are scannable and every block carries actionable content.

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

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

With an output schema present, the description needn't explain return values, and it instead supplies the surrounding context an agent needs: protocol semantics, mode selection, gating state, seller prerequisite, and post-call signing/submission steps. Nothing essential to correct invocation 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 is already documented as the escrow vault ID. The description reinforces the PASS_AWAITING_NFT constraint, but adds no syntax, format, or lookup detail beyond what the schema states. Baseline 3 applies when 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 and resource ('Returns a pre-built Batch transaction') and immediately names the exact protocol primitive (XLS-56 Atomic NFT DvP, TF_ALL_OR_NOTHING). The two modes are called out explicitly, so an agent understands this is the atomic-settlement payload builder rather than a generic escrow read. Distinguishable from siblings like submit_escrow_transaction or prepare_escrow, which do not return a one-signature Batch tx.

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

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

Explicitly says when to use each mode: AI audit + atomic settlement 'when the deliverable needs independent verification', and pure on-chain DvP 'for tickets, physical assets, collectibles'. It also states the prerequisite state (PASS_AWAITING_NFT) and the required seller registration step. It does not name a sibling tool as the alternative, so it falls short of full when-not routing.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the quote is 'live' and sourced from the XRPL DEX, which is useful context, but it says nothing about quote freshness/staleness or latency, and it repeats return fields already implied by the output schema.

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

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

Front-loads the core purpose, then usage context, then a return summary in three compact sections with no filler. Slightly wasteful in re-listing return fields that the output schema already carries, but overall tight and well-ordered.

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 quote tool with a full output schema and complete parameter coverage, the description is nearly complete: it explains purpose, timing, and rough output. The one meaningful gap is that it never distinguishes itself from the confusingly similar get_rlusd_quote sibling, which an agent must resolve to select correctly.

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

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

Schema description coverage is 100%, so the schema fully documents xrp_amount and worker_address, including the note that worker_address is used to check trustline status. The description adds no parameter-level detail beyond the schema, making the baseline 3 correct when 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, resource, and mechanism: 'Get a live XRP to RLUSD conversion quote via the XRPL DEX.' This is concrete and actionable. However, it does not differentiate itself from the nearly identical sibling get_rlusd_quote (nor from get_xrp_price), so an agent cannot disambiguate the two quote tools from the text alone.

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?

Gives clear when-to-use context: 'before creating an RLUSD-denominated escrow or before claiming an escrow if you want to understand the current USD value.' That is solid situational guidance. It stops short of naming alternatives (e.g., get_rlusd_quote) or stating when this tool is NOT the right choice.

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 safety profile is covered. The description adds a genuinely non-obvious behavioral constraint — that the fulfillment key is never returned, only on approval — which prevents an agent from mistakenly expecting it. It does not add auth or rate-limit context, so not a 5.

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

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

Two short sentences, front-loaded with the core action and followed immediately by the one caveat that matters. No filler, repetition, or restated 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?

With an output schema present, return values need not be enumerated, and the annotations carry the safety profile. The one thing an agent most needs to know that structured fields don't convey — the fulfillment key is withheld — is stated explicitly. Minor gap: no indication of error behavior for an unknown escrow_id.

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 itself supplies the meaning and an example format ('AT-7X9K-2MQ4'), so the baseline is 3. The description adds nothing about escrow_id beyond the schema, but with full coverage 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 clear verb+resource: 'Retrieve metadata about an existing escrow vault.' An agent can distinguish it from create_escrow_vault and evaluate_escrow_work by the read-only lookup framing. It does not, however, explicitly name a sibling or contrast its role against them, 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?

Usage is only implied: you call this to inspect an existing vault, keyed by its receipt code. There is no statement of when to prefer this over siblings like view_job, audit_task, or evaluate_escrow_work, and no prerequisites or exclusions are given.

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

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

Annotations 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added behavioral detail is the registry context, which hints that unregistered wallets are a possible outcome, but it never states what happens on a miss, whether auth is needed, or any rate limits.

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?

Front-loaded one-line purpose followed by a use case and a returns list; no filler prose. The 'Returns:' block largely restates the output schema, which is the only wasted line.

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 needn't enumerate return fields, and it covers purpose, use case and scope adequately. A missing note on the not-found/unregistered case is the only real 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?

Single parameter with 100% schema description coverage, so the schema fully documents the wallet_address format (r...). The description adds no format, validation, or lookup-key nuance beyond the schema, which is the expected baseline at full coverage.

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

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

States a specific verb (look up) and resource (registered NFT issuer) keyed on an XRPL wallet address, which is a distinct lookup axis from the sibling lookup_nft_issuer. It does not name that sibling or otherwise explicitly contrast itself, 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?

Gives a clear use case — verifying whether an NFT's minting wallet belongs to a known, verified organisation in the AgentTrust registry. It provides no exclusions or alternative-tool routing (e.g. when to use lookup_nft_issuer or verify_wallet_domain instead), so it is context without boundaries.

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, non-destructive and openWorld, so the safety profile is covered. The description adds that the quote is 'live' and DEX-routed (volatile, market-derived), which is useful, but it omits quote expiry/slippage behavior and the fact that the call also probes trustline state (that detail lives only in the schema).

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

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

Two short sentences, zero filler, with the core action front-loaded and the usage note following. Every clause 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?

An output schema exists, so return-value explanation is not required, and annotations carry the safety profile. For a two-parameter read-only quote tool this is nearly complete; the remaining gap is that it doesn't clarify how the result should differ in use from the sibling get_dex_quote output.

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

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

Schema description coverage is 100%, so both xrp_amount and worker_address are fully documented in the schema, including the trustline-check side use of worker_address. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource+route: 'Get a live XRP to RLUSD conversion quote via the XRPL DEX.' The RLUSD-specific framing implicitly separates it from siblings like get_xrp_price and get_dex_quote, though neither is named explicitly, so an agent must still infer the boundary.

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?

Gives concrete trigger conditions: use before creating an RLUSD-denominated escrow, or before claiming an escrow to understand current USD value. That is clear context, but it names no alternative tool and gives no exclusion (e.g. when to prefer get_dex_quote or get_xrp_price instead).

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 declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial context they cannot carry: rate limits, cost model, the meaning of score bands (below 30 / 30–60 / 60+), and a downstream consequence (KYC-verified wallets can create escrows up to $10,000). This is behavior an agent needs to reason about the result.

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 definition is front-loaded with purpose, then signals, then cost/limits, then score interpretation — a logical order with no wasted sentences. The opening 'Open reputation layer for XRPL agents' is slight positioning flavor rather than operational content, which keeps it from a 5.

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?

An output schema exists, so return values need not be explained, and the description still notes that it returns a per-signal breakdown. Combined with cost, rate limits, score bands, and sibling routing, an agent has everything needed to call it 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?

With a single parameter and 100% schema description coverage, the schema already documents wallet_address fully. The description adds no format or syntax detail for the parameter beyond what the schema provides, 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?

States a specific verb and resource ('returns a 0–100 trust score for any wallet') and enumerates the 11 signals it aggregates, so the agent knows exactly what it produces. It is clearly distinguishable from narrow siblings like check_wallet_kyc and check_wallet_sanctions, which cover only individual signals.

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?

Gives explicit routing guidance: 'For scoring multiple wallets at once, use batch_wallet_trust_scores() instead ($0.10 per batch of up to 50).' It also discloses cost ('Free to query') and a rate limit (20 calls/hour/IP), which is the practical condition that would push an agent toward the batch sibling.

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

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

Adds traits beyond the annotations: the challenge is one-time (consistent with idempotentHint=false), expires in 30 minutes, requires the memo value as hex, and no private key is ever transmitted because the signed on-chain tx is the proof. These are operationally critical details an agent cannot infer from readOnlyHint/openWorldHint alone.

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

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

Four short sentences, front-loaded with the action, then the mechanism, then the required follow-up call, then the expiry constraint. Every sentence carries information the agent needs to act.

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

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

Covers the mechanism, the signing requirement, the follow-up tool, and the 30-minute TTL, and return values are covered by the output schema. It leaves minor gaps such as what happens if the challenge expires or is reused, but nothing required for a correct invocation 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?

Only one parameter, and the schema already documents wallet_address at 100% coverage, including the 'r...' format hint. The description adds no input-side syntax beyond that, so the baseline of 3 applies; the hex detail it mentions concerns the memo payload, not this parameter.

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

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

'Request a one-time verification challenge to prove ownership of an XRPL wallet' states a specific verb (request), a distinct resource (verification challenge), and the scope (ownership proof for an XRPL wallet). It is clearly separable from siblings like confirm_wallet_ownership and verify_wallet_domain, which it does not duplicate.

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?

States when to use it (to prove ownership) and prescribes the follow-up: broadcast the AccountSet tx then call confirm_wallet_ownership() with the tx hash. No alternatives or exclusion conditions are given, so a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds 'live', implying non-cached real-time retrieval, but says nothing about rate limits, cache/freshness windows, or failure modes when the price feed is 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?

Two short sentences, zero filler, with the what front-loaded and the when following it. 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?

With an output schema present, return values needn't be documented, annotations cover the safety profile, and there are no parameters to explain, so the description is nearly complete. The one meaningful omission for a price tool is data freshness/latency beyond the word 'live'.

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

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

The tool takes zero parameters (additionalProperties: false), so there is no parameter semantics for the description to compensate for; baseline for a 0-param tool is 4. The description usefully confirms the output denomination (USD and GBP), which is the only input-adjacent choice an agent might otherwise wonder about.

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 and resource ('Get the current live XRP price') plus the returned currencies (USD and GBP), so the agent knows exactly what it fetches. It does not explicitly differentiate itself from the sibling quote tools (get_rlusd_quote, get_dex_quote), though the resource name makes the distinction inferable.

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?

Gives a concrete when-to-use: convert XRP bounty amounts to fiat before deciding whether a job is worth taking, which ties the tool to a real workflow step. It offers no exclusions or alternatives (e.g., when to prefer get_rlusd_quote or get_dex_quote), so it stops short of full routing guidance.

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

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

Annotations declare a non-read-only, non-idempotent, open-world write, and the description goes beyond them by disclosing the exact execution flow (vault registration, returned unsigned transaction, sign-and-confirm step) plus white-label behavior via callback_url webhooks and echoed metadata. It doesn't restate reversibility/deadline consequences (auto-cancel), though those live in the schema.

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

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

Front-loads the core value in the first sentence, then uses clear labeled sections for the composition, proof gates, and white-label integration. Slightly verbose, but every section maps to a real decision the caller must make, so little is wasted.

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 an 18-param mutation with an output schema, the description covers the flow, the proof-gate surface, and the webhook/metadata integration, so an agent has enough to call it correctly without the description re-explaining return values. It omits some non-obvious prerequisites (e.g. the delegate DelegateSet precondition, which is left to the schema), leaving 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 already 100%, so the baseline is 3, but the description adds organizational meaning by grouping the proof-gate params (require_nft_proof, required_nft_issuer, nft_dvp, required_domain, required_vc_issuer_did) into a single 'buyers can require…' concept and explaining the metadata round-trip purpose. It does not add syntax detail beyond what the schema already carries.

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 compound action (register escrow vault + return ready-to-sign transaction) and explicitly names the two sibling calls it replaces: create_escrow_vault() + prepare_escrow(). An agent can distinguish it from the two-step path without opening any schema.

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?

Clearly frames the tool as a one-call shortcut versus the manual create_escrow_vault + prepare_escrow route, and states the follow-up ('only needs to sign the returned transaction and confirm it'). It does not explicitly say when NOT to use it (e.g. when the agent needs finer control or wants to reuse an existing vault), so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds useful domain context (bounties backed by XRPL escrow, auto-pay on AI approval), but says nothing about pagination, result ordering, or filtering behavior beyond what the schema documents.

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

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

Three short sentences, front-loaded with the core action and with no redundant filler. Slightly padded by the marketing-toned 'primary way' line, but overall efficient.

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

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

An output schema exists, so return values need no explanation, and annotations carry the safety profile. The remaining gap is sibling disambiguation (list_open_jobs) and any note on result ordering or paging, which the description never addresses.

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 all three parameters (limit, category, min_bounty_xrp) fully documented, including defaults and enum-like category values. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb ('Browse') and resource ('open bounties on the AgentTrust marketplace'), so the basic purpose is clear. However, it does not distinguish itself from the sibling 'list_open_jobs', which sounds like the same operation, leaving genuine ambiguity an agent cannot resolve from the text alone.

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 primary way autonomous agents discover work available on the protocol' implies the discovery use case, but there is no explicit when-to-use vs when-not, and no routing to alternatives such as list_open_jobs, view_job, or list_marketplace_skills.

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, destructiveHint=false and openWorldHint, so the safety profile is covered and the bar is lower. The description adds genuine behavioral context beyond that: listings are worker-published, no bidding is involved, and each record exposes the poster's XRPL wallet address for direct escrow creation.

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

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

The purpose is front-loaded in the first sentence and the two follow-on sentences explain the marketplace model without redundancy. It is slightly longer than strictly necessary for a list tool, but every sentence carries usable 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?

With an output schema present, rich annotations and full parameter coverage, the description only needs to orient the agent, which it does. The remaining gap is the absence of any signal separating this from the jobs-listing siblings.

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 limit, category, max_rate and min_rate are fully documented in the schema itself. The description adds no syntax, units or filtering semantics beyond what the schema already provides, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Browse agents and humans offering skills on the AgentTrust marketplace') and explains the underlying object clearly. It does not, however, distinguish itself from closely named siblings such as list_marketplace_jobs or list_open_jobs, which an agent would need to disambiguate.

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

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

Usage is implied rather than stated: it hints at the scenario of finding a worker to hire directly without bidding and 'go straight to creating an escrow.' It never names an alternative (e.g., list_marketplace_jobs, submit_bid) or states when this tool is the wrong choice.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful domain context (no escrow exists yet; the buyer creates escrow on award and payment is automatic on approval), but says nothing about the tool's own runtime behavior such as result ordering or pagination across the limit.

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

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

Three short sentences, front-loaded with what the tool does before moving to the bidding workflow. No filler, though the third sentence is arguably more workflow guidance than tool definition and could be trimmed.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, state semantics and the immediate next step in the workflow. An agent has enough to call it correctly, though the missing contrast with list_marketplace_jobs is the one remaining 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% — limit, category and min_budget are each fully documented in the schema with defaults, ranges and enum values. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource (browse jobs on the AgentTrust job board open for bidding) and clarifies the object's state (buyer requests with no escrow yet). It does not, however, differentiate itself from the closely named sibling list_marketplace_jobs, leaving the agent to infer the 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?

Usage is implied rather than stated: the description explains that these are bidding-stage jobs and names submit_bid() as the follow-up action, which hints at when to use it. But it never gives an explicit when-not condition or contrasts with alternatives such as list_marketplace_jobs or 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?

Goes well beyond the readOnly/idempotent/openWorld annotations: it enumerates all five status values with their trust implications, explains that matching is exact or close only, describes the registered=false + register_url failure mode, and lists the proof fields (verified_at, verified_by, toml_url, accountset_tx_hash) that allow independent confirmation. This is exactly the trust-relevant behavior an agent needs.

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?

Front-loaded with the core purpose, then a use case, then caveats, then the status enum, then returns — a sensible ordering with no filler sentences. It is on the long side, but the status-value list and the missing-result warning each carry distinct decision-relevant information.

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

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

For a read-only, open-world lookup, the description covers purpose, trust interpretation of every status, the negative-result case, and the evidence fields. An output schema exists so return values need not be restated, yet the description's summary of returns remains useful without being redundant.

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

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

Schema coverage is 100% for the single query parameter, so the baseline is 3. The description still adds value by clarifying matching semantics (exact-match or close-match only) and by confirming the dual company-name / wallet-address input mode that governs which sibling 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?

States a specific verb (look up) and resource (organisation in the AgentTrust XRPL NFT Issuer Registry) and describes what the registry maps (company names to verified XRPL wallet addresses). It does not explicitly distinguish itself from the sibling get_nft_issuer_by_wallet, which appears to be a near-duplicate lookup, so the agent must infer the split from the query parameter.

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?

Gives a concrete use case (checking whether an NFT was issued by a legitimate organisation before accepting it as proof of ownership or as an escrow delivery condition) and an explicit anti-pattern (do not treat a missing result as implicit approval). It never names an alternative sibling such as get_nft_issuer_by_wallet or verify_nft_ownership, so routing between near-duplicate lookups is left to inference.

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=false, openWorldHint=true, and destructiveHint=false, so the bar is lower. The description adds genuinely useful behavioral context beyond them: 'No fee, no funds held,' clarifying that posting itself is cost-free and non-custodial until the later escrow step.

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

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

Four sentences, front-loaded with the core action and the most decision-relevant fact ('no fee, no funds held'), followed by the pipeline. Efficient, though the multi-tool walkthrough is slightly expansive for a posting 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?

With an output schema present, return values needn't be explained, and safety is covered by annotations. The description adequately frames this as the posting step of a longer flow, leaving only minor gaps like job_id uniqueness expectations.

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 every one of the 8 parameters is already documented, including enums and defaults. The description adds no syntax, format, or constraint detail beyond the schema, making the baseline 3 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?

States a specific verb+resource ('Post a job to the AgentTrust job board') and immediately distinguishes itself from sibling workflow tools by naming list_open_jobs, submit_bid, award_job, and create_escrow_vault. An agent can tell what this tool is and where it sits in the pipeline without opening any schema.

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?

Gives strong when-to-use and what-happens-next context by walking the full lifecycle (discovery, bidding, negotiation, award, escrow), which routes the agent to the correct follow-up tools. It stops short of naming alternative entry points such as direct_hire or hire_and_pay, so it's clear but not fully exclusionary.

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 cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds useful context beyond them: the output is a pre-filled transaction dict with ledger sequence, fee, and condition, and it clarifies that the buyer signs and submits outside this tool. It omits permission/auth requirements, so not a 5.

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?

Front-loads the core purpose, then gives the call sequence in short, purposeful sentences. Slightly long but nearly every sentence carries procedural information an agent needs.

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

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

Output schema exists so return-value detail isn't required, yet the description still explains the return dict and the end-to-end sign/submit workflow, making it callable with minimal ambiguity. Missing only auth/permission notes.

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 parameters like escrow_id, amount_xrp, and the addresses are already documented. The description only alludes to the condition and pre-filled fields without mapping them to specific inputs, so baseline 3 is appropriate.

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

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

States a concrete verb and resource: 'Build a ready-to-sign XRPL EscrowCreate transaction.' It places itself in a workflow relative to create_escrow_vault and confirm_escrow_transaction, which distinguishes it from siblings. It doesn't explicitly name a sibling it replaces, 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?

Explicit prerequisite ('Call create_escrow_vault() first'), explicit follow-up ('Then call confirm_escrow_transaction() with the tx hash'), and a stated position ('the low-friction path'). The when-to-use sequence is fully spelled out, leaving nothing to inference.

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 only cover safety flags (readOnlyHint=false, idempotentHint=false, openWorldHint=true); the description goes well beyond them by disclosing the mandatory $0.05 fee, the accepted currencies (XRP or RLUSD), the exact destination address, and the successful return value (updated attempts_remaining). For a paid, non-idempotent mutation this is exactly the context an agent needs.

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?

Front-loads the action and the trigger, then the cost and return value — a well-ordered structure. The parenthetical about default 3 attempts and max_submissions pricing is useful background but slightly tangential to invoking the tool.

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

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

Covers trigger, required payment, destination address, currencies, and post-call workflow, and an output schema exists so return values need not be spelled out. An agent has everything needed to invoke this correctly in the escrow 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 both parameters are already fully documented in the schema, including the fee_hash format and recipient address. The description largely restates the same payment facts rather than adding syntax or constraints beyond them, 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?

States a specific verb and resource ('Purchase one additional submission attempt') and immediately scopes it to 'a vault that has hit its limit'. This is clearly distinguishable from siblings like evaluate_escrow_work or prepare_escrow without opening any schema.

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?

Gives an explicit trigger condition — 'When evaluate_escrow_work returns error "submission_limit_reached"' — names the exact alternative tool, and prescribes the follow-up step ('then resubmit with evaluate_escrow_work'). Nothing about when to use this tool is left to inference.

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=false and destructiveHint=false, but the description goes further: the rating feeds the counterparty's Trust Score (up to 15 pts), is one-per-escrow-per-rater, and is permanent and public. Permanence and public visibility are consequential side effects an agent must know before calling.

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?

Front-loaded with the core action, followed by impact, constraints and timing in short paragraphs. The closing call-to-action partly restates the timing already given, a minor redundancy, but the rationale it adds keeps it useful.

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, return values need not be explained, and 100% schema coverage handles parameters. The description covers timing, effect on trust score, permanence and frequency limits; only permission/auth prerequisites and whether the rating is revocable are left implicit.

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

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

Schema coverage is 100%, so every parameter including rating, escrow_id and rater_role is already documented in the schema, which sets the baseline at 3. The description only adds the one-rating-per-escrow constraint, which is a modest addition over the schema's own note.

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 (leave a rating), resource (peer rating for a counterparty), value range (1–5 stars) and trigger condition (after a completed escrow). This is clearly distinguishable from siblings like evaluate_escrow_work or audit_task, which judge work rather than record a peer rating.

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?

Explicit timing is given: call after an escrow completes, whether it passed or failed, and the one-rating-per-escrow-per-rater rule bounds repeated use. No alternative sibling is named as a substitute, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the thread is complete ('all messages'), includes both buyer and worker posts, and is ordered chronologically — useful for an agent reasoning about staleness or ordering.

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

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

Three short sentences, front-loaded with the action and free of filler. There is minor overlap between 'message thread' and 'all messages posted by buyers and workers,' which costs a point but does not impede scanning.

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

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

For a single-parameter read tool, the definition covers what it does, what it returns (all messages, chronological order), and when to call it, while annotations carry the safety profile and an output schema handles return structure. Nothing needed to invoke 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?

With a single parameter at 100% schema description coverage, the schema fully documents job_id and the description adds no format, source, or constraint detail beyond it. Baseline 3 is appropriate when 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 and resource ('Fetch the message thread for a job') and clarifies the scope as messages 'posted by buyers and workers.' It reads clearly as the read counterpart to send_job_message, though it never names a sibling explicitly the way the top-calibrated examples do.

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

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

Gives an explicit when-to-use: 'catch up on any clarifications or instructions before starting work or submitting a bid,' which ties the call to concrete workflow moments. No when-not-to-use or named alternative (e.g., send_job_message for posting) is provided.

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 declare non-read-only, non-idempotent, non-destructive, closed-world behavior, so the safety profile is largely covered. The description adds a genuinely useful behavioral fact beyond that: messages are visible to both the buyer and the awarded worker, which affects what an agent should write. It stops short of noting side effects like notifications or the fact that the optional bid_id scoping is unannotated.

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

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

Two brief paragraphs, front-loaded with the action and followed by scope and visibility. The closing clause ('without leaving the AgentTrust platform') is slightly promotional padding, but overall it is tight.

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

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

With an output schema present and full parameter coverage, the description only needs to carry purpose and usage, which it does, plus the visibility trait. An agent has enough to invoke it correctly; minor gaps like notification behavior or message-length limits are not decision-critical.

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 in the schema; the baseline of 3 applies. The description implies bid_id's tie to pre-escrow negotiation but adds no syntax, format, or constraint detail beyond what the schema provides.

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

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

States a specific verb and resource ('Send a message on a job thread') and frames the purpose with concrete scenarios (clarifying requirements, sharing progress, negotiating before escrow). It does not explicitly name the sibling read_job_messages to draw the send/read boundary, but the verb makes the distinction self-evident.

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?

Gives clear when-to-use context: pre-escrow negotiation, deliverables, deadlines, scope changes, and staying on-platform. No explicit when-not-to-use or named alternative is given, so it stops short of the 5 bar.

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

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

Annotations only declare non-read-only, open-world, non-idempotent, non-destructive. The description goes well beyond that: it discloses the $0.50 cost, accepted payment assets (XRP, RLUSD, USDC), the required out-of-band browser action via verification_url, automatic notification on completion, the resulting state transition to kyc_verified, and the $10,000 escrow unlock. That is exactly the behavioral context annotations cannot carry.

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

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

Front-loaded with the action and fee, then prerequisites, then return value and effects. Every sentence carries operational weight, though the multi-paragraph form is heavier than strictly necessary for a two-parameter 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?

Despite an output schema existing, the description still names the key return artifact (verification_url) and the downstream consequences. Combined with the prerequisite chain and status-check follow-up, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds marginal meaning by tying fee_hash to a concrete $0.50 payment in named assets and by framing wallet_address as the operator being verified, but it does not add syntax or format detail the schema lacks.

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 and resource — 'Start a Didit identity verification session for a wallet operator' — and implicitly distinguishes itself from check_wallet_kyc, which it names as the status-confirmation sibling. An agent can tell exactly what this tool initiates without opening the schema.

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?

Gives an explicit prerequisite ('Call get_fees() first to get the current fee amount and accepted assets') and an explicit follow-up alternative ('Safe to call check_wallet_kyc() afterwards to confirm status'). When-to-use, prerequisites, and the routing alternative are all present.

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 this as a non-readonly, non-idempotent, open-world write. The description adds genuinely useful context beyond that: the buyer-award path (award_job()), and the distinct notification/polling behavior for human vs AI submitters. It does not disclose auth/payment requirements or whether a bid can be withdrawn or edited.

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?

Front-loaded with the core action, followed by the award path and then actor-specific guidance in two tight sentences. No filler; each sentence carries distinct 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?

An output schema exists so return values needn't be explained, and all parameters are covered. The description adequately conveys the bid lifecycle and submission expectations, though it omits edge conditions like bid withdrawal or minimum-price rules.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including worker_email's dual-notification behavior. The description's human-vs-AI framing of worker_email adds only marginal interpretation beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb+resource: 'Submit a bid on an open job posting,' which cleanly identifies the operation. It contextualizes the downstream flow (buyer awards via award_job()), but does not explicitly differentiate from potential siblings like direct_hire or claim_job.

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

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

It gives clear conditional guidance by actor type: human workers include worker_email for notifications, AI agents poll view_job(job_id) instead. The lifecycle note that the buyer reviews and awards via award_job() also frames the context of use. It stops short of stating when to prefer submit_bid over alternatives such as direct_hire.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuine context beyond them: the escrow delivery-condition role and the fact that the AgentTrust evaluator invokes it automatically during NFT DvP escrows. It also previews the return fields.

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?

Front-loads the core purpose, then the usage context, then the return values in three tight sentences. No redundancy and nothing wasted.

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?

An output schema exists, yet the description still summarizes the return shape (verified, nft_token_id, metadata match, issuer details). Combined with the usage context, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents wallet_address, issuer_wallet, and required_metadata with format examples. The description's 'from a specific issuer, optionally matching metadata' only restates those roles at a high level, adding little beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Verify that a wallet holds an NFT from a specific issuer, optionally matching metadata.' The NFT-scoped framing implicitly separates it from wallet-level siblings like confirm_wallet_ownership and check_wallet_kyc, but it never names an alternative, so it stops short of full sibling differentiation.

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

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

Gives a concrete when-to-use scenario: 'Use as an escrow delivery condition: before releasing payment, confirm the seller has transferred the correct NFT.' It also notes the evaluator calls it automatically. There is clear context but no explicit when-not-to-use or named 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?

The description discloses the key behavioral fact the annotations can't: this reaches out over the open web to fetch a TOML file, and success writes a trust-score contribution (explaining readOnlyHint=false despite the 'verify' name). The idempotent, non-destructive profile is consistent with the stated behavior. It does not mention failure modes or rate limits, keeping it short of a 5.

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?

Front-loaded with the core action and mechanism, then a short mechanism/precondition paragraph. Every sentence carries information, though the middle paragraph is slightly padded and the 'Returns' line duplicates the output 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?

Given only two well-documented params, an output schema, and annotations, the definition covers what an agent needs: the external-fetch nature, the required TOML location and [ACCOUNTS] key, and the side effect on trust score. A note on failure cases (e.g., what happens if the file is absent or mismatched) would make it complete.

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

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

Schema description coverage is 100% and both params are documented in-schema, so the baseline is 3. The description reinforces that the domain must host the TOML and that the wallet must appear in it, but adds no format or syntax 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?

States a specific verb+resource (verify a wallet's domain ownership) and names the exact mechanism (XRPL Foundation xrp-ledger.toml at /.well-known/). This is clearly distinguishable from siblings like confirm_wallet_ownership or verify_nft_ownership, which cover different ownership proofs.

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 the precondition for success (the domain must publish an xrp-ledger.toml listing the wallet under [ACCOUNTS]) and the payoff (10 pts toward trust score), which implies when to reach for it. However, it never explicitly says when to use this versus confirm_wallet_ownership or get_wallet_verification_challenge, so alternative selection is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing that all current bids are returned and that an 'awarded' status surfaces awarded_bid_id as the winning bid — useful conditional behavior not visible in the structured fields.

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

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

Three short sentences, each carrying distinct information: what is returned, when to use it, and how to read the awarded case. The core purpose is front-loaded and there is no filler.

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

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

An output schema exists, so return values need not be enumerated, and the description still covers the one non-obvious result nuance (awarded_bid_id). Purpose, trigger, and the key conditional outcome are all present for a single-parameter read 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?

There is a single parameter with 100% schema description coverage, and the schema already explains that job_id comes from list_open_jobs() or post_job(). The description adds no format or constraint detail beyond that, 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?

States a specific verb and resource ('View a job posting and all current bids'), and the mention of bids hints at the single-job scope that separates it from list_open_jobs. It stops short of explicitly naming a sibling to contrast against, so it falls just under the top mark.

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?

'Use this to check the status of a job you posted or bid on' gives a clear when-to-use condition tied to the caller's relationship to the job. There is no explicit when-not guidance or named alternative for listing jobs, so it is strong but not complete routing.

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