@quackai/q402-mcp

Official

by quackai-org

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.11.14
Disambiguation4/5
Most tools have highly specific names and descriptions, but the set includes several overlapping money-movement tools (q402_pay, q402_batch_pay, q402_request_pay, q402_bridge_send, q402_oft_send) and three stub tools (q402_bridge_history, q402_bridge_gas_tank, q402_oft_history) that could confuse. Unrelated travel tools further muddy the domain boundary.
Naming Consistency5/5
All tools use snake_case with a consistent verb_noun pattern, and the q402_/travel_ prefixes cleanly separate the two domains. No camelCase or mixed conventions.
Tool Count2/5
50 tools is far above the typical well-scoped range. The server bundles many sub-domains (payments, recurring, redstone, bridge, OFT, yield, stake, escrow, requests) plus unrelated travel tools, and includes non-functional guidance stubs, making it feel bloated and hard to navigate.
Completeness4/5
The Q402 domain is covered thoroughly: payments, batch, recurring rules with full lifecycle, escrow lifecycle, yield deposit/withdraw, staking, requests, and even event-driven redstone triggers. The main gaps are the three stub tools that defer to a dashboard, and a few missing update operations (e.g., no redstone trigger update, no travel cancellation), but the core surface is complete.
Average 4.5/5 across 50 of 50 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 44 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and exceeds it. It discloses that the tool intentionally surfaces as an error, requires owner-sig auth, is dashboard-bound, and details the future shape of results. This gives the agent complete awareness of the tool's current non-functional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with 'READ-ONLY GUIDANCE TOOL' and the key limitation (not yet wired), but it includes a long future-shape specification that may be more than needed for a stub. Still, the structure is logical and every sentence contributes context, making it slightly verbose but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stub tool with one optional parameter and no output schema, the description fully covers current behavior, intentional error surfacing, authentication context, and a concrete user-facing redirect. It also outlines the future response format, which is helpful for an agent planning around upcoming functionality. The only minor gap is the exact error message text, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional ownerAddress parameter, which already explains it defaults to the configured wallet. The description adds no additional parameter semantics 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this is a read-only guidance tool for bridge history, not yet wired in the release, and directs the user to a dashboard. It distinguishes itself from sibling bridge tools by focusing on history and explicitly noting it returns a pointer rather than actual history data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: until session-binding lands, point the user to the dashboard link and specific tab. It also references the live q402_bridge_send tool for the same follow-up context, helping an agent understand when to use this stub versus expecting real data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly says 'Read', indicating a non-mutating operation, and lists the returned content (state, parties, amount, tx hashes). This covers the key safety aspect (no side effects) for a status query, though it omits details like authentication or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly crafted sentence that front-loads the verb and resource, enumerates valid states, and lists the key returned fields. Every word adds value; there is no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description conveys the essential return values (state, parties, amount, tx hashes) as well as the possible state enums. It is complete enough for an agent to invoke and interpret the result, though it does not explicitly detail the response structure (e.g., JSON shape) or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the sole parameter 'escrowId' is fully described as 'The esc_... id from escrow_create.' The description does not add additional parameter-level meaning beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource (a Q402 escrow's current state), listing the possible state values and the contained data (parties, amount, tx hashes). This makes it immediately distinguishable from sibling escrow mutation tools like q402_escrow_release, q402_escrow_refund, and q402_escrow_dispute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the read-only counterpart to the escrow lifecycle tools, but it does not explicitly state when to prefer this over alternatives or mention any preconditions (e.g., 'use this before calling release/refund'). The context from sibling names helps, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses that the tool returns the total amount in currency, which is useful, but it does not mention whether the quote is binding, expires, or has any side effects. For a quote tool, the absence of side effects is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and every sentence adds value: the first states what it does, the second explains the workflow. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter tool with no output schema, the description explains the return value and usage context. It covers the essential information an agent needs: what to pass, what to expect, and the surrounding workflow. It does not detail edge cases, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the schema already explains each field. The description adds limited additional meaning by tying hotelId to travel_search_hotels and mentioning date range, but this is largely redundant with the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a price quote for a specific hotel and date range' with a specific verb and resource. It also mentions the return value (total amount) and differentiates from siblings like travel_search_hotels, travel_book_hotel, and travel_get_booking_status by focusing on the quote step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides workflow context: 'Use the hotelId from travel_search_hotels' and 'Present the quote to the user before proceeding to travel_book_hotel.' This implies when to use it in the booking sequence, but it does not explicitly state when not to use it or mention alternative tools beyond the workflow reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses read-only nature, authentication via Multichain API key with no private key required, default wallet behavior when walletId is omitted, and the scope of 12 supported EVM chains. This is strong behavioral transparency, though it doesn't mention error cases or data freshness, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a purpose: what it does, what it returns, auth, parameter, and use cases. It is front-loaded with the tool's primary purpose. While a bit dense, it avoids fluff and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers return content, auth, parameter default, and usage triggers. It explains the byChain breakdown and the constraint to USDC/USDT across 12 chains. It does not define 'archive state' or 'per-tx and daily caps' in detail, but these are reasonably self-explanatory. Overall, it is complete for a read-only introspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single walletId parameter, and the schema already explains optionality, lowercase address, and default resolution. The tool description merely restates this as 'optional walletId for owners who hold more than one wallet; omit to use the server-default wallet', adding no meaningful semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is 'Read-only Agent Wallet introspection' and enumerates specific return values: wallet address, per-tx and daily caps, archive state, aggregate USD balance, and per-chain breakdown. It explicitly distinguishes from siblings by noting the per-chain breakdown across 12 EVM chains and the use case 'before routing a payment', which differentiates it from tools like q402_balance or q402_wallet_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger phrases: "Use this whenever the user asks 'what's in my agent wallet?', 'how much do I have on Base / on each chain?', or 'what's the spending limit?'" This gives clear when-to-use guidance. However, it does not name alternatives or state when not to use it, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full safety burden. It explicitly states 'Read-only; no auth required', which is a key behavioral disclosure. It also reveals return behavior (both LINK and native fee). While it doesn't discuss potential edge cases like rate changes, it provides solid transparency for a quote tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and scope, the second explains the output and safety. Every word earns its place, with no redundancy or fluff. It's front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward with four well-documented parameters and no output schema. The description covers purpose, output, and safety. It doesn't mention that quotes may be estimates or subject to change, but given the tool's simplicity and the rich sibling context, it's nearly complete. A 4 reflects one small gap: no explicit caveat about quote validity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that amount refers to USDC and chains are limited to the triangle, but adds no extra parameter-level detail beyond what the schema already provides. It does not compensate for any gaps because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Quote') with a clear resource ('Chainlink CCIP fee for bridging USDC across the 3-chain triangle'). It explicitly names the three chains and distinguishes itself from siblings like q402_quote and q402_oft_quote by focusing on CCIP bridging fees and returning both LINK and native fee options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for quoting bridge fees, and it's read-only with no auth required. It also explains the benefit (picking the cheaper path). However, it does not explicitly state when not to use it or mention alternatives like q402_oft_quote, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the confirm:true requirement, the precondition of an arbiter and deadline, and that the arbiter resolves off-tool afterward. This provides a clear behavioral picture, though it does not detail the escrow's post-dispute state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. Every clause adds necessary context (party, arbiter, deadline, off-tool resolution, confirmation), with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action, the description adequately covers prerequisites, the action itself, and the follow-up resolution process. The absence of an output schema is not a gap because the description explains the intended flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in detail. The description re-emphasizes confirm:true and indirectly references escrowId provenance, but adds minimal semantic value 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: a party (buyer or seller) disputes an open escrow. It adds specific constraints (requires arbiter, before release deadline) that distinguish it from related escrow tools like release or refund, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when an escrow is open, has an arbiter, and is before the release deadline. It also mandates user confirmation first. It does not explicitly name alternative tools, but the context is strong enough to guide selection without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the action is permissionless, time-limited, and requires user confirmation. It doesn't detail side effects or error conditions, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and key constraints. Every word earns its place; no fluff or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the essential when, what, and confirmation steps. It could mention success/error behavior, but the overall context is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces the confirm parameter's meaning ('confirm with the user first') but doesn't add information beyond the schema's own clear descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'refund' with a clear resource ('locked escrow') and beneficiary ('to the BUYER'). It also states the timing condition ('after the release deadline'), distinguishing it from sibling tools like escrow_release or escrow_dispute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit timing constraints ('only valid AFTER the release deadline...') and a confirmation requirement ('Confirm with the user first'). It doesn't explicitly mention sibling alternatives, but the conditions are clear enough for an agent to know when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the irreversible effect ('never fires again') and the required authentication ('Authenticated by the Multichain API key'). It does not mention potential side effects like idempotency or error handling, but the key traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose, then mention authentication and a cross-reference to a related tool. Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cancellation tool with no output schema and no annotations, the description covers the essential points: what it does, permanence, auth, and how to find the identifier. It is complete enough for an agent to use it correctly, though it could mention what happens if the trigger doesn't exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a useful hint that the triggerId can be found via q402_redstone_trigger_list, giving context for obtaining the value, but it does not elaborate further on parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Permanently cancel a RedStone trigger so it never fires again.' This distinguishes it from sibling tools like trigger_create and trigger_list, making it unambiguous which operation it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use by stating the action's permanent nature and authentication requirement, and it explicitly directs the user to q402_redstone_trigger_list to find the triggerId. It lacks explicit exclusions (e.g., when not to use), but the guidance is sufficient for a cancellation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format (list with specific fields) and importantly the mock mode default behavior ('returns deterministic fixture hotels'), which is non-obvious and critical for setting expectations. It does not explicitly state that it is a read-only operation, but this is implied by its search nature and the subsequent travel_get_quote step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first states the core purpose, the second details the return values, and the third provides integration and mock mode information. Every sentence contributes new information, with no redundant or filler content. The structure is front-loaded with the action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete for a search tool: it covers purpose, return fields, integration to travel_get_quote, and mock mode default. It does not mention edge cases such as no-results behavior or result ordering, but these are less critical given the tool's simplicity and the absence of an output schema. The mock mode disclosure is particularly valuable in a multi-tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for destination, checkIn, checkOut, and guests. The description adds only a high-level reference to 'destination' and 'date range' and does not provide extra meaning beyond the schema parameters. It does not mention the 'guests' parameter, but the schema already covers it. The description adds no additional parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search'), resource ('hotels'), and scope ('at a destination for a given date range'). It distinguishes from sibling tools like travel_get_quote, travel_book_hotel, and travel_get_booking_status by focusing on the search/list step. The return content (IDs, names, locations, ratings, nightly prices) is explicitly enumerated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it is for searching hotels, and the instruction to use the returned hotelId with travel_get_quote guides the agent to the next step. It does not explicitly state exclusions (e.g., when not to use it), but the integration hint strongly implies its role in the workflow. Sibling tool names reinforce the differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and states 'Read-only and free: any live API key (Trial or Multichain)', disclosing safety and auth requirements. It also explains attribution nuances, but does not cover pagination or rate limits, which are minor for a simple report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: core report content, example use cases, and attribution/safety. It is front-loaded with the main purpose and has zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description sufficiently covers what is returned (spend, tx count, label, caps), when to use it, and its safety profile. There are no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'window' is fully described in the schema with an enum and default. The description adds only an example ('this week'), which is minor, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Per-agent spend report') and clearly states what it shows: USD spent, tx count, labels, and caps for each Agent Wallet. It also includes example questions, making its purpose unmistakable and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool through example questions ('what did my Research agent spend this week?') and explains the attribution model for precise per-agent reporting. It does not explicitly name alternative tools or exclusion criteria, but the use case is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states 'Read-only', discloses conditional behavior when both keys are set, and details the trial-credit output (days-left and credits-remaining). It also adds external links for further context, which is useful but not exhaustive (e.g., no mention of error handling or empty-key scenarios).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Verify the configured API key(s) and report...') followed by conditionals and links. Every sentence adds value: read-only flag, dual-key behavior, trial details, and dashboard pointer. It is moderately sized, not overly verbose, and despite being a bit longer than strictly necessary, it remains tightly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, no output schema, and no parameters, the description provides a strong level of completeness: it explains the tool's read-only nature, conditional outputs, and points to external resources for additional needs. The only notable gap is the lack of explicit handling for cases where no keys are configured, but for a verification tool with this scope, the coverage is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100% with an empty object. The description correctly does not attempt to explain parameters, and instead focuses on behavioral context. Baseline 4 for zero-parameter tools is appropriate, and the description adds relevant context about the keys involved without needing to document parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Verify' and resource 'API key(s)', and clearly states it reports each one's plan tier (live vs sandbox vs trial). This distinguishes it from sibling tools like q402_wallet_status, which focus on wallet state rather than API key plan status. The read-only declaration and trial-specific details further clarify the tool's exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the dual-key scenario and when to use this tool to show both trial and paid credits. It also explicitly points to the dashboard for per-chain gas tank balances, giving a when-not-to-use direction. However, it does not name any sibling tools as alternatives, leaving a small gap in direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses read-only and free access with any live API key, and details the exact data returned including failure/hold information. This is substantial transparency for a read-only summary tool, though it omits specifics like rate limits or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence listing all key outputs, followed by a usage sentence with concrete examples. Every phrase adds value; no filler or repetition. The structure front-loads the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates the full set of returned information, making it easy for an agent to predict results and decide if this tool fits a query. It also covers read-only access and API key requirements, so the context is complete for a summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions (window enum with default 7d, walletId optional lowercased address). The description reinforces the window choices with usage examples but does not add meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes treasury activity with a specific verb ('Summarize') and resource ('treasury activity'), and it enumerates detailed outputs (USD spent, tx count, breakdowns, vendors, payouts, escrow, failures). This distinguishes it from sibling tools like q402_agent_spend_report or q402_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit example queries are provided: 'summarize my treasury', 'why did my balance drop yesterday' (with window:24h), and 'what did we spend this week'. This gives clear context for when to use it, though it does not explicitly mention when not to use it or name alternative tools for overlapping scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully carries the transparency burden and does so thoroughly: it discloses that the tool is a read-only guidance stub, returns implemented:false intentionally, requires owner-sig auth, and will not return actual history. It even explains the 'implemented:false' design decision to prevent LLM confusion, going beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than a simple stub, but every sentence carries necessary information: status, auth, return behavior, future shape, and the sibling alternative. The front-loaded 'READ-ONLY GUIDANCE TOOL' immediately sets expectations, though the prose could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an intentionally non-implemented tool, the description covers all critical context: current behavior, auth constraints, future return schema, and the correct sibling for USDC/CCIP. It does not specify the exact dashboard pointer shape, but that is not essential for a guidance stub and the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for the single optional ownerAddress parameter, including format and default behavior. The description adds no parameter-specific detail, so it doesn't go beyond what the schema provides, but the schema is sufficient, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read-only guidance stub for USDT0 OFT bridge history, explicitly stating it is 'not yet wired' and reports implemented:false with a dashboard pointer. It distinguishes itself from q402_bridge_history by directing USDC/CCIP users there, so the purpose is both specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when not to rely on it (not yet wired), notes the auth requirement (owner-sig, dashboard-bound), and gives an explicit alternative for USDC/CCIP ('use q402_bridge_history'). It doesn't explicitly state 'use this tool only for status discovery,' but that is strongly implied by the guidance-tool framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication via the Multichain API key and explicitly states 'no funds move,' which helps the agent understand safety and auth requirements. It doesn't mention additional behavioral aspects like data freshness or pagination, but for a simple list operation, these are not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. The first sentence front-loads the core action and return fields; the second sentence adds essential auth and safety context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description is complete. It states what is listed, enumerates the data attributes included, and gives auth/no-funds context. Sibling tools are clearly distinct, and the description sufficiently answers what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single optional walletId parameter (100% coverage), so the description doesn't need to add parameter semantics. The description provides no additional detail about the parameter, which is acceptable given the schema already says 'Optional. Defaults to server default wallet.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('RedStone triggers on the user's Agent Wallet'), and enumerates the specific fields returned (feed, condition, recipient, amount, mode, armed state, fire history). This distinguishes it from sibling trigger operations like create or cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a read-only listing operation for the user's triggers and notes that no funds move. While it doesn't explicitly name alternatives or state 'use this before creating/canceling triggers,' the context makes the use case clear, and the sibling names (create/cancel) are obvious contrasts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what the tool returns (hotel, dates, amount, currency, status) and enumerates the possible status values (confirmed, pending, cancelled, not_found). This gives the agent a good sense of behavior, though it doesn't explicitly state read-only semantics, it's strongly implied by 'Retrieve'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no unnecessary words. It efficiently conveys action, input, and return details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read-only status tool: it states the purpose, the input provenance, the returned fields, and the possible statuses including an error-like 'not_found'. No output schema exists, so the description appropriately summarizes the response contents. There are no missing critical details for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for bookingId with 'Booking ID from travel_book_hotel.' The description repeats this same information ('using the bookingId returned by travel_book_hotel') without adding new semantic meaning. Therefore, the description adds no value beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('current status of a hotel booking'), and clearly distinguishes from sibling tools like travel_search_hotels and travel_book_hotel. It also specifies the input source (bookingId from travel_book_hotel), making the tool's role in the booking flow unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the usage context: retrieving status after booking, using the bookingId from travel_book_hotel. This provides clear context for when to use it, though it doesn't explicitly mention alternatives or exclusions. The guidance is clear enough for an agent to select it vs. other travel tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden; it discloses the operation is read-only with no auth and describes the return values (native messaging fee and delivered amount). It does not cover error conditions or rate limits, but this is sufficient for a quote tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, return, and alternative/read-only. Front-loaded with the core function, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description appropriately states the return information. It covers the token, chain set, and read-only nature, leaving little ambiguity for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter text for src/dst/amount, so the description need not add parameter detail; it doesn't. The description doesn't delve into parameter semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the tool quotes LayerZero fees for USDT/USDT0 bridging across the OFT set, a specific verb+resource. It clearly distinguishes itself from sibling q402_bridge_quote for USDC.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs USDC users to q402_bridge_quote instead, and the description implies use for USDT OFT quotes. Also notes read-only and no auth, providing context for when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing key behavioral traits: it is server-managed (Mode C), sandbox-by-default, requires consent token for live execution, and sends to the same wallet address on the destination. It does not cover fee handling, slippage, or failure behavior, but the disclosed traits are significant and actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action (bridge USDT0 across chains), and includes the crucial same-wallet constraint plus an explicit sibling alternative. Every clause earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description provides a solid operational overview: chain list, asset type, wallet mode, sandbox default, live requirements, and USDC alternative. It does not mention the prerequisite quote flow (though consentToken implies a preview), nor gas funding details, so it is not fully complete but is well above the minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces that sandbox defaults to true and that confirm and consentToken are needed for live bridges, but it does not add substantial parameter-level detail beyond the schema. The schema already explains raw decimal units, enums, and the consent token source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bridges USDT0 across specific chains via LayerZero OFT, and specifies it sends from the Agent Wallet to the same wallet address on the destination. This distinguishes it from the sibling tool q402_bridge_send, which is explicitly mentioned for USDC.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: it is for USDT0 cross-chain bridges, with a direct alternative named (q402_bridge_send for USDC via CCIP). It also states the required conditions for a live bridge (confirm:true + consentToken) and that sandbox is the default, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 WRITE/MOVES FUNDS, gasless execution, server-managed key path, confirmation requirement, sandbox default, and retry safety with dedup, all beyond what structured annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headers for confirmation, sandbox, and retry safety. Every sentence provides necessary operational detail, making the length justified and front-loaded with the WRITE-MOVES FUNDS warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, it covers operational workflow (preview/confirm, sandbox flag, retry safety) and references response status ('uncertain'). It doesn't fully describe the response shape, but the critical usage scenarios are all addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; all five parameters have descriptions that already explain 'max', tier APR, consentToken flow, etc. The description adds no significant new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly it 'Stakes the Agent Wallet's Q (QuackAI) token into QuackAiStake on BNB Chain, gaslessly.' Verb+resource+chain makes it distinct from siblings like q402_unstake and q402_pay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: call first without confirm to preview, then re-call with confirm:true + consentToken; sandbox default and retry safety are also covered. It references q402_pay as a similar pattern but doesn't explicitly name alternatives for staking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses critical details: the first call makes no booking, returns a needs_confirmation status and consentToken, requires relaying preview verbatim, and enforces a spend limit guard tied to an environment variable. This is rich, safety-relevant context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the purpose, and the following sentences add only necessary procedural and safety details. Every sentence earns its place, and the structure helps the agent process the two-phase flow without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 8-parameter tool with no output schema and no annotations, the description covers the key workflow: quote prerequisite, two-phase consent, preview relay, spend limit, and consentToken re-call. It omits the return value of the second call or success handling, which would be useful, but the described flow is otherwise complete enough for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds contextual meaning for amount and consentToken by linking amount to the quote prerequisite and explaining the two-phase token flow, but it does not substantially elaborate on other parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Book a hotel,' a clear verb+resource statement that immediately identifies the tool's purpose. It further distinguishes itself from siblings like travel_search_hotels and travel_get_quote by framing this as the final booking step after obtaining a quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Always call travel_get_quote first to obtain the amount,' providing a clear prerequisite and usage context. It thoroughly explains the two-phase consent workflow, but does not explicitly mention when not to use the tool or list alternative tools, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it warns 'MOVES REAL FUNDS', explains gasless sponsorship via EIP-7702, details key requirements (server signs for Agent Wallet, otherwise Q402_PRIVATE_KEY), and mandates user confirmation. This is exceptionally transparent for a financial mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit long but front-loaded with purpose and every sentence contributes critical information (mechanism, real funds, key requirements, confirmation). The use of caps and clear segmentation helps scanning, though it could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (funding escrow with gasless flow) and lack of output schema, the description covers purpose, mechanism, prerequisites, and mandatory confirmation. It doesn't state return values, but that's not essential here; overall it's sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes both params. The description adds value by explaining that escrowId comes from escrow_create and clarifying that confirm:true must only be set after explicit user confirmation of the exact action, reinforcing the safety intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific verb ('Fund') and resource ('pending escrow'), plus the mechanism ('gaslessly locks the amount into the vault via EIP-7702'). It distinguishes from sibling escrow tools like release, refund, and dispute by focusing on the funding step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use this tool (after escrow_create, before release/refund) and provides an explicit safety rule: 'ALWAYS confirm the exact amount/seller/chain with the user before calling (confirm:true)'. It doesn't explicitly mention alternatives, but the sibling names make that clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly warns that the tool 'MOVES REAL FUNDS irreversibly' and requires user confirmation, both crucial for a high-stakes operation. It does not cover failure modes or auth details, but the primary risk is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each purposeful: the action/actor, the irreversibility warning, and the confirmation requirement. No filler or repetition, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 2-parameter tool with no output schema. The description covers what it does, who does it, the irreversible nature, and the necessary confirmation step. The sibling tool list provides enough surrounding context for an agent to select it correctly. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions, so the baseline is 3. The description adds context by tying 'confirm' to a real-world precondition ('Confirm with the user first') and by qualifying 'escrowId' as a 'locked escrow'. This reinforces behavioral meaning beyond the schema's boolean const.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'BUYER releases a locked escrow to the SELLER'. It names a specific verb, resource, and actor, and differentiates from sibling tools like escrow_refund and escrow_dispute by specifying the buyer-signed, gasless release direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the exact context: this is the buyer's action to release funds to the seller. It also provides a critical usage instruction: 'Confirm with the user first (confirm:true)'. It does not explicitly mention when not to use or compare to alternatives, but the actor/action pairing gives clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly: discloses read-only nature, no API key needed, no funds move, unconditional full matrix return, inability to filter by trial scope, and the q402_pay TRIAL_BNB_ONLY behavior. This goes beyond the schema and annotations to give critical operational expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer than a two-sentence description, every sentence adds essential information: purpose, chain list, return behavior, trial caveat, RLUSD note, safety, and usage placement. It is front-loaded with the primary action and contains no filler, earning its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates well by explaining the return value (full chain × token matrix), including RLUSD, and the trial-account implications. It also covers prerequisites (none), side effects (none), and integration with q402_pay, making the tool fully self-contained for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are already rich with enums and special narrowing notes for RLUSD and USDG. The description adds context for trial-row interpretation but does not materially extend parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool compares gas costs and supported tokens across the 12 chains Q402 relays, with the chain list enumerated. It distinguishes itself from sibling tools by explicitly positioning this as the quote-before-pay comparison tool, unlike q402_pay or q402_bridge_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this before q402_pay so the user can see what's available and pick a chain. It also explains the trial-vs-multichain scope limitation and directs the caller to treat rows outside BNB/Avalanche as informational when a Trial API Key is intended. Does not explicitly contrast with sibling quote-like tools, but provides clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses read-only behavior ('Read-only; no API key required'), explains the internal verification process ('re-runs the same canonical-JSON + EIP-191 recovery'), and warns about the unimplemented txHash path. It does not describe error formats or rate limits, but the essential behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parenthetical, front-loaded with the main purpose. Every sentence provides necessary information: purpose, usage context, parameter requirement, and behavioral caveat. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description fully covers what the agent needs to know: what it does, when to use it, what to pass, and what it returns (settlement record + boolean). It even mentions the future txHash lookup. No significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds crucial value by explicitly stating 'receiptId is required' (despite schema not marking it required) and explaining that txHash is unimplemented and will return notFound. This goes beyond the schema and helps the agent choose the correct parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Look up a Q402 Trust Receipt by its rct_… receiptId and return the settlement record + a locally-verified ECDSA boolean'. It identifies the specific resource (Q402 Trust Receipt) and the action (look up), distinguishing it from sibling tools like q402_pay (which creates) and q402_balance (which queries balances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use after q402_pay to give the user a shareable verified-by-Q402 URL, or to independently verify a receipt id someone shared with you.' It also clearly says that passing only txHash returns notFound, implying receiptId is the correct path. However, it does not name alternative tools for exclusion, though it is contextually clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses immediate cancellation, that the rule will not fire again, authentication via the Multichain API key, and idempotency with a 409 response for already-cancelled rules. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences pack all essential info: action, parameter source, behavior, auth, idempotency, and usage workflow. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose, precondition (call list first), behavioral details, authentication, and an error case. It is self-contained and sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description only repeats the ruleId source (from q402_recurring_list) and adds no new parameter-specific meaning beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel an active recurring-payment rule on the Agent Wallet,' with a specific verb and resource. It also distinguishes from siblings by emphasizing immediate cancellation, unlike pause/resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Use this whenever the user says stop my recurring payment to X' and provides a workflow to call q402_recurring_list first. However, it doesn't mention alternatives like pause or resume, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the operation is a read ('Read'), discloses authentication requirements ('Authenticated by the configured Multichain API key - no private key required'), and details the return content. While it doesn't mention error cases or lack of mutation explicitly, the 'Read' verb and auth note provide substantial transparency. A slight deduction for not addressing potential edge cases like empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose. The second sentence lists return fields with compact notation (e.g., 'frequency (hourly:N / daily / weekly:{day} / monthly:N / monthly:last)'), and the third provides usage + auth in one line. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and no output schema, this description is highly complete. It covers the exact data returned, usage context, and authentication. No critical information is missing 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (walletId is explained in the schema as optional and lowercased). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Read the user's active recurring-payment rules on their Agent Wallet' with a specific verb and resource. It also enumerates the exact return fields, leaving no ambiguity about its function. It distinguishes itself from sibling tools like q402_recurring_create by mentioning 'before authoring a new rule'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'Use this when the user asks "what scheduled payouts do I have?" or before authoring a new rule with q402_recurring_create.' This provides clear trigger scenarios and names an alternative tool, satisfying the requirement for when/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 only the next fire is skipped, cadence is preserved, active status is required, and authentication requires a paid Multichain API key. It does not mention return values or error handling, but the core behavioral traits are covered well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly verbose but front-loaded with the core action. Each sentence contributes meaningful context: what it does, when to use it, prerequisites, authentication, and a prerequisite call. No fluff, but could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, no output schema, and no annotations. The description covers the main action, usage cases, prerequisites, and parameter sourcing. It lacks explicit mention of return format or edge cases (e.g., what if the rule is already skipped), but overall it provides sufficient context for an agent to invoke it correctly in most situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage of the two parameters, so baseline is 3. The description adds value by specifying that ruleId should be confirmed via q402_recurring_list, giving context on how to obtain a valid value. It also implicitly describes walletId's default behavior via the schema description. This extra guidance justifies one point above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Skip ONLY the next scheduled fire of a recurring-payment rule' and specifies the resource. It also distinguishes itself from sibling tools like pause/cancel by emphasizing that cadence is preserved. The examples further clarify the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use scenarios with user phrasing examples, states the prerequisite that the rule must be active (with a when-not for paused/cancelled rules), and instructs to call q402_recurring_list first. This gives the agent clear usage context and alternatives implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently explains that the tool is non-monetary, creates a shareable request, returns a req_ id and /pay link, defaults the recipient to the Agent Wallet, and supports billing oneself. It could mention edge cases or error behavior, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficiently structured. Every sentence conveys essential information: what the tool does, key behavioral caveats, return values, and integration with sibling tools. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description effectively communicates return values (req_ id and /pay link), default behaviors, trial key compatibility, and how to use the tool in a workflow (with q402_request_status and q402_request_pay). This makes the tool self-explanatory for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with individual descriptions, so the baseline is 3. The description adds valuable semantic context, particularly that the recipient defaults to Q402_AGENT_WALLET_ADDRESS and that you can 'bill yourself with just an amount'. This goes beyond the schema's dry documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: it publishes a Q402 payment request (invoice/bill), explicitly distinguishing it from payment execution tools. It uses specific language like 'Publish' and 'creates a shareable request to RECEIVE money', and even names the sibling tool q402_request_pay that will actually pay it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context: it notes that no funds are moved, no confirmation is needed, a Trial key works, and suggests pairing with q402_request_status for polling. It also implies the alternative of using q402_request_pay for actual payment. However, it does not explicitly say when NOT to use this tool, such as for immediate fund transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the read-only nature, authentication method (Multichain API key), and safety guarantee ('no private key, no funds move'). It also explains key behavioral details like the 'max' semantics for unstaking and staking, which is transparent and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and well-structured: it starts with READ-ONLY, covers return values, authentication, safety, and typical use cases in just three sentences. Every clause adds value, and the layout is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly enumerates returned fields (tier, principal, APR, times, matured flag, aggregate totals, max values) and explains the meaning of 'max'. Combined with authentication details and usage guidance, it is fully self-contained for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single optional walletId parameter with a clear description (schema coverage 100%). The tool description does not add parameter-level details beyond the schema, but it does provide context about whose positions are shown, which aligns with the default wallet behavior. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb ('show') and specific resource ('Agent Wallet's open Q staking positions on QuackAiStake (BNB)'). It differentiates from siblings by emphasizing READ-ONLY and listing exact returned data, distinguishing it from q402_stake, q402_unstake, and q402_yield_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit natural-language use cases ('what are my Q stakes?', 'how much Q can I unstake?') and points to using it before q402_unstake with amount 'max'. However, it does not explicitly state when not to use this tool or name alternative read tools like q402_balance, so it falls just 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the read-only and non-mutating nature ('does not trigger or modify anything'), mentions authentication via API key, and describes the return payload structure including the partial-failure flag. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the core purpose, followed by usage prompts, auth, and return details. The auth sentence is somewhat generic but still earns its place for transparency. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains what is returned (up to 50 entries, newest first, with timestamp, USD amount, tx hashes, partial-failure flag). It also covers prerequisites and behavior, making it complete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already described. The description adds little beyond schema, except the note that ruleId comes from q402_recurring_list, which is also in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads past-fire history of a recurring-payment rule, which is a specific verb (read) and resource. It distinguishes itself from sibling tools like q402_recurring_list or q402_recurring_create by focusing on historical execution data, not configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists example user queries that should trigger this tool ('when was the last fire?', 'did Friday's payout go out?') and instructs to call q402_recurring_list first to obtain ruleId. This provides clear when-to-use guidance and prerequisite steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that nextRunAt is advanced to avoid an immediate stale-fire, that income states require pre-actions (restoring wallet, raising cap/re-subscribing), and that cancelled rules are permanently ineligible. This goes beyond the schema and gives the agent crucial behavior expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each carrying distinct information: purpose, transitions, scheduling behavior, cancellation caveat, and auth requirement. It is front-loaded with the core action and avoids redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex stateful mutation with no output schema, the description covers the tool's purpose, valid input states, side effect on nextRunAt, and the key exception (cancelled rules). It lacks explicit return-value or failure-mode information, but that's a modest gap given the clarity of the state machine and schema. A 4 reflects this near-completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%; the schema itself already documents ruleId as coming from q402_recurring_list and thoroughly explains walletId defaults. The description adds no new parameter-level detail beyond restating 'ruleId (from q402_recurring_list)' and referencing state preconditions. Therefore it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource: 'Resume a paused or stopped recurring-payment rule.' It goes beyond a generic verb by enumerating the exact supported state transitions (paused→active, paused-by-archive→active, fired-cap-exceeded→active), which uniquely distinguishes it from sibling tools like q402_recurring_pause, q402_recurring_cancel, and q402_recurring_skip_next.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context: it tells the agent to take ruleId from q402_recurring_list and lists the exact preconditions for each resume path. It also gives an alternative for cancelled rules ('re-author via q402_recurring_create'), and its sibling list clearly maps to a recurring-payment workflow, so the agent can choose this tool over pause/cancel/skip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses this is a WRITE operation that moves funds, explains the gasless mechanism (Mode C, server-signed, relayer-sponsored gas), per-record execution, confirmation requirements (confirm:true + consentToken), and references 'uncertain-retry semantics' and gates from q402_stake. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear labels (WRITE, PER-RECORD, REQUIRES CONFIRMATION) and front-loads the purpose. Every sentence contributes essential information about execution mode, parameter semantics, or prerequisites. Slight density but appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (per-record unstaking, confirmation flow, gasless execution), and the description covers prerequisites, parameter semantics, and safety checks. It does not detail return values for preview vs confirm, but given no output schema exists, this is not strictly required. It also references 'uncertain-retry semantics' without expounding, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema: it explains that 'all' and 'ith' are mutually exclusive, indicates 'ith' originates from q402_stake_positions, and describes the two-phase consent/confirmation flow. This goes beyond the basic property descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: unstaking matured Q from QuackAiStake on BNB back to the wallet. It specifies the resource (Agent Wallet's stake), the protocol (QuackAiStake), and the network (BNB), and distinguishes it from siblings like q402_stake_pending or other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use q402_stake_positions first to identify exitable records, and explains the 'ith' vs 'all' distinction. It notes a stake can only be unstaked after its lock elapses, giving a clear precondition. Does not explicitly mention alternatives, but names the prerequisite tool and gives context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden: it states 'No auth required and no funds move - this is purely a preview of available yield', discloses it reads curated markets on BNB/Base, and clarifies the optional chain filter behavior. This is excellent transparency for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with action and safety, then return fields, scope, alternatives, parameter usage, and trigger scenarios. It is longer than strictly necessary but every sentence adds relevant context; a slight trim would make it a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and no output schema, the description fully covers purpose, safety, returned fields, supported chains, filtering, and when to invoke it. It leaves no significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `chain` is fully described in the schema (enum+description), and the tool description adds filtering semantics ('omit it to see every supported chain') and chain-to-asset coverage (USDC/USDT vs USDC only), helping the agent decide parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'READ-ONLY - list the Q402 Yield lending markets the Agent Wallet can supply into', a specific verb+resource+scope. It enumerates returned fields and distinguishes from siblings by stating it's a preview of available yield rather than a deposit/withdraw or positions tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit trigger phrases ('where can I earn yield?' or 'what's the lending APY on <asset>?') and says to use it 'before supplying', while referencing deposit/withdraw tools. However, it does not explicitly mention q402_yield_positions for viewing current holdings, so exclusion guidance is slightly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly. It discloses the confirmation gate, sandbox behavior (no real funds unless live key + env var), retry safety (status='uncertain', idempotencyKey replay), server-side key handling, gas sponsorship, and venue reporting. This goes far beyond a typical description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but all content is purposeful, formatted in scannable uppercase lead-ins ('REQUIRES CONFIRMATION', 'SANDBOX BY DEFAULT', 'RETRY SAFETY') that front-load critical behaviors. It is dense with information but avoids fluff. Slight deduction for length, though nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 params and no output schema, the description fully covers operational prerequisites (confirmation, sandbox), retry handling (uncertain status, idempotency key), chain/token constraints, and where to find results ('reported in the receipt'). It even references related tools for pre-condition checks. This is comprehensive for a high-complexity transaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: clarifies amount='max' can be less than full position due to caps, explains consentToken flow, and gives the full retry-safe idempotencyKey semantics ('re-calling with the same key replays the first result instead of double-withdrawing'). This lifts it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE - MOVES FUNDS. Withdraws the Agent Wallet's supplied stablecoin out of its Q402 Yield lending position back to the Agent Wallet.' This names the specific verb (withdraw), resource (Q402 Yield lending position), and direction (back to Agent Wallet), making the tool's purpose unmistakable. It also distinguishes from siblings like q402_yield_deposit and q402_yield_positions, creating clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Use q402_yield_positions first to see the current position size', explicit confirmation workflow ('Call it FIRST without confirm... get explicit approval, THEN re-call'), sandbox default conditions, and chain availability ('Other chains are not yet available'). It does not explicitly name a contrary alternative sibling, but the guidance is concrete and actionable enough to rate above baseline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and meets it. It discloses the read-only nature, the auth limitation (requires owner-sig auth, dashboard-bound), the static vs. live behavior, and what the response will and will not contain. This is a model of transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with 'READ-ONLY GUIDANCE TOOL' to immediately set expectations. Every sentence earns its place, covering purpose, content, limitation, and usage. It avoids redundancy and is well-structured for agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fully compensates by specifying exactly what the response contains (fee model, chain list, deposit address, dashboard pointer) and its limitations. It provides enough context for an agent to decide when to invoke this tool vs. alternatives, and to set user expectations correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the only parameter, ownerAddress, with a clear pattern and description. The tool description does not add parameter-level detail, but since the schema fully documents it, the baseline of 3 is appropriate. The optionality and default behavior are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states this tool returns static guidance for the Bridge Gas Tank, not live data. It specifies the exact content: LINK/native fee model, 3-chain CCIP triangle, canonical deposit address, and dashboard pointer. It clearly distinguishes itself from live bridge tools like q402_bridge_history and q402_bridge_send by noting it is 'not yet wired' and returns no numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this to route a user to the right top-up flow.' It also states when-not/exclusions: 'don't expect numbers in the response' and explains that live balance is dashboard-bound until session-binding lands. It references the same follow-up as q402_bridge_history, providing a sibling context for the limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job: it discloses edge-latched exact-once firing, no instant-fire when already past threshold, API-key authentication/no private key, paid subscription requirement, and amount/recipient rails. This goes far beyond a typical 'creates a trigger' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: purpose, examples, critical edge-case behavior, auth, subscription, limits, and related-tool guidance. It is front-loaded with the core action and then logically layers constraints and prerequisites without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no annotations, and no output schema, this description is exceptionally complete for safe invocation. It covers prerequisite discovery (q402_redstone_feeds), cancellation path, behavioral edge cases, auth model, subscription tier, and amount rails. The schema fills the remaining parameter-specific details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful semantic context beyond the schema: feedId must be readable/allowlisted via q402_redstone_feeds, the payout is bounded by wallet limits and local Q402_* rails, and chain requires a paid subscription. It does not walk through every param, but the examples help clarify op/threshold/amount semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Arm a gasless payout that fires when a RedStone feed crosses a threshold.' Concrete examples (ETH >= 2000, NAV <= 0.98) make the operation unambiguous. It also distinguishes itself from siblings by explicitly pointing to q402_redstone_feeds for picking a feedId and q402_redstone_trigger_cancel for stopping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says to call q402_redstone_feeds first and to use q402_redstone_trigger_cancel to stop, and it states the paid Multichain subscription requirement. It does not explicitly contrast with immediate-payment or recurring-payment siblings (e.g., q402_pay or q402_recurring_create), but the threshold-crossing use case is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and discloses key behaviors: read-only, free, requiring only a live API key. It explains the address-based vendor limitation, the condition for showing human names, and what fields to expect in both modes. This goes beyond typical safety hints to cover operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with the main purpose in the first sentence. Each subsequent sentence covers a specific aspect (modes, limitations, access). It is concise at ~90 words and every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two modes), the description fully explains what the agent can expect from each mode, including return fields and a key constraint. It also addresses authentication requirements and confirms read-only/free status. Without an output schema, this is sufficient for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how the `vendor` parameter toggles between two distinct result sets and what each set contains. It also clarifies the `window` default and the optional `walletId` context, enriching the schema's simple descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Vendor payment history.' It provides specific verbs and resources, and distinguishes between two modes: with a vendor address for detailed payment info and without for a leaderboard. It also explicitly answers questions like 'how much have we paid Alice so far?' making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by explaining both invocation modes and example questions. It does not explicitly name alternative tools, but the use cases ('which vendors get paid every month?') imply when to use this tool over siblings. The note about address-based vendors and rule labels adds an important prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it explicitly states 'Read-only - no signing, no on-chain TX, no quota consumption' and 'Requires Q402_PRIVATE_KEY in env.' It also reveals the return format per chain. This is strong disclosure beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with every clause earning its place: scope, return shape, safety, pairing, and prerequisite. It is front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 0-parameter schema and no output schema, the description fully describes the tool's behavior, output structure, and requirements. It also connects to a related sibling, making it contextually complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object, so there are no parameters to document. The description still adds context by identifying the wallet source (EOA derived from Q402_PRIVATE_KEY), which is the implicit parameter, earning a solid baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Report' and a precise resource: 'EIP-7702 delegation status of your Q402 wallet across all 12 Q402-supported chains.' This unambiguously distinguishes it from sibling tools such as q402_balance or q402_clear_delegation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a direct pairing with q402_clear_delegation for resetting a specific chain, and notes the environment prerequisite (Q402_PRIVATE_KEY). However, it does not explicitly state exclusions or alternative tools for other status queries, so it stops short of a full when-to-use/not-to-use guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 read-only behavior, no API key requirement, automatic phase detection, and the two output surfaces (agentInstructions, userInstructions). It also reveals the security policy for handling exposed private keys and warns about slot-mismatch scenarios in live-check mode. This is exceptionally transparent for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, starting with the core purpose and then layering usage triggers, output surfaces, multi-turn flow, and security policy. Every section provides essential operational guidance for a complex diagnostic tool. It is not concise in word count, but the length is justified by the tool's multi-phase behavior and critical onboarding role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description thoroughly explains what the tool returns: agentInstructions, userInstructions, recommendedActions, securityNotice, and phase-specific live-check diagnostics (quota, delegation, relay reachability, slot warnings). It also covers the multi-turn interaction pattern and security handling, making the tool fully understandable for an agent without needing external docs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details because there are none to explain. It instead explains how the output varies based on the detected phase, which is more relevant than any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run a Q402 health check' and explicitly states it covers both 'first-install onboarding AND ongoing diagnostics'. It further clarifies that it detects the current phase, distinguishing it from siblings like q402_pay, q402_balance, and q402_wallet_status. The purpose is unambiguous and differentiates from other q402_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit trigger phrases ('Use when the user says any of: "set up Q402", "verify Q402", ...'), declares itself the 'FIRST tool to call after install, BEFORE q402_pay or q402_balance', and gives detailed multi-turn instructions for the first-install phase. This clearly tells the agent when and how to use the tool, including what to do in subsequent turns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the state transition to 'paused', the cron skipping behavior, full reversibility via resume, and authentication requirements. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, but slightly redundant: it mentions ruleId provenance twice ('Takes a ruleId (from q402_recurring_list)' and later 'Read q402_recurring_list first to find the matching ruleId'). Still, every sentence carries meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description covers all necessary context: purpose, usage, behavior, reversibility, alternatives, authentication, and prerequisites. It is fully complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the source of ruleId ('from q402_recurring_list') and reinforces the prerequisite of listing first. This goes slightly beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Pause an active recurring-payment rule.' It clearly distinguishes this from sibling tools like q402_recurring_cancel and q402_recurring_resume by explicitly mentioning them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios ('pause my Friday payout', 'hold on, stop my recurring rule for now') and contrasts with cancel ('gentler than cancel, no re-authoring required'). Also instructs to read q402_recurring_list first to find the ruleId, giving a clear prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses safety behaviors: sandbox by default, two-phase consent, ambiguity gates, multi-wallet disambiguation, and zero gas cost. It also warns about server-mediated batches being paid-only and the need for explicit user confirmation, offering comprehensive operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with clear paragraphs for triggers, routing, ambiguity, sandbox, wallets, and consent. Some repetition exists (e.g., 'confirm:true alone does NOT send' appears both in the description and schema), but the density is appropriate for the tool's complexity and safety-critical nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description compensates by explaining all possible non-success statuses (needs_confirmation, ambiguous, needs_wallet_choice) and the conditions that trigger them. Edge cases like trial limits, multi-wallet ambiguity, and sandbox activation are thoroughly covered, making the tool fully operable without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial semantics beyond the schema, such as auto-routing behavior of keyScope, the walletMode selection process (eoa/agentic-local/agentic-server), and the consentToken re-derivation mechanism that prevents batch swapping. These details are not in the schema parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as 'Send gasless payments to MULTIPLE recipients on a single chain × token in one call' and explicitly distinguishes it from q402_pay for non-batchable chains, making its purpose and scope unmistakable. It also states that this tool IS the wallet for the session, leaving no ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It begins with an explicit trigger: 'USE THIS TOOL whenever the user asks to send the same token to multiple recipients...' and provides examples. It also gives clear alternatives, like using q402_pay in a loop for xlayer/stable, and explains conditions for trial vs multichain key scopes, sandbox mode, and wallet selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly. It discloses the sandbox default, conditions for live payments (Q402_ENABLE_REAL_PAYMENTS=1 and a live Multichain API key), the server signing process, auto-funding from the Gas Tank, debit behavior, two-phase consent mechanics, and the AGENT_WALLET_DELEGATED error resolution path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It is front-loaded with the core purpose, then logically flows through sandbox behavior, signing/funding, consent flow, and error handling. The density is justified by the tool's complexity, and nothing feels redundant or promotional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the execution flow, prerequisites, consent, error handling, and sibling tool references. However, there is no output schema and the description only partially specifies return values: it mentions a synthetic messageId for sandbox and the preview payload, but what a live successful call returns (e.g., messageId, receipt, status) is not explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning beyond field names. It explains the consentToken lifecycle (preview → re-call with token), how confirm interlocks with sandbox, that sandbox defaults to true, that feeToken defaults to LINK, and that walletId comes from q402_agentic_info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Execute a Chainlink CCIP USDC bridge across the 3-chain triangle (eth/avax/arbitrum) on behalf of the user's server-managed Agentic Wallet (Mode C).' This clearly distinguishes it from sibling tools like payments or quotes, and the mention of Mode C adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit recommended flow: 'q402_bridge_quote first → preview + confirm cost with the user → q402_bridge_send with sandbox: false, confirm: true, consentToken.' It also explains when to call without consentToken (preview) and when to re-call, and points to q402_clear_delegation for a specific error case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and exceeds it: it discloses the two-phase consent flow (preview + token, then execute), wallet-mode signing differences, gas sponsorship per chain, and automatic delegation re-creation on next q402_pay.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet front-loaded: first sentence states purpose, subsequent sentences cover usage, exclusions, wallet modes, gas, and consent flow. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (two-phase consent, multiple wallet modes, chain-specific gas), and the description fully explains all mechanics despite no output schema. It is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds operational meaning beyond the schema, such as how walletMode relates to signing locations and the consentToken re-derivation from chain+wallet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Clear the EIP-7702 delegation on a Q402 chain for the configured wallet.' It clearly distinguishes from siblings by naming q402_pay, q402_wallet_status, and q402_agentic_info as related but different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call ('reset a chain's delegation, OR to switch a wallet off the q402 rail so it can use the x402 rail'), when not to ('don't clear right before a normal pay'), and which tools to pair with first (q402_wallet_status / q402_agentic_info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the tool moves no funds, creates a pending record, server-side signing implications, and the release approval nuance for Agent-Wallet escrows. It also mentions optional arbiter changes dispute resolution, and timeout-refund behavior. This is rich behavioral disclosure beyond basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but every sentence earns its place: purpose, funding options, chain/token context, arbiter behavior, and approval nuance. It front-loads the core action and zero-funds fact, then logical detail. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description clarifies return (escrowId) and pending state. It covers creation lifecycle, funding mechanism, multi-party roles (buyer, seller, arbiter), chain and token constraints, and release approval requirement. For a complex escrow creation tool with 8 params, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (6 of 8 params described), so baseline is 3 but description adds significant semantics for walletId (buyer/funder, server signs gasless lock) and explains the meaning of arbiter (dispute resolution vs release-or-timeout-refund only). It also clarifies amount as human-readable decimal in schema, and description reinforces chain specifics. However, memo and releaseDays get no additional color beyond schema, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Create a Q402 Gasless Escrow'. It specifies non-custodial, EIP-7702, publishes a 'pending' record, returns escrowId, and explicitly states 'MOVES NO FUNDS'. This distinguishes it from siblings like q402_escrow_lock/release/refund which act on an existing escrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use walletId vs omit it, how that affects funding and signing. Also specifies chain and token availability (BNB mainnet USDC/USDT) and optional arbiter behavior. It differentiates from other escrow tools by noting the lock step follows ('funds it straight away'), and mentions dashboard approval for Agent-Wallet release, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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: discloses subscription requirements per chain, trial-key rejection error (MULTICHAIN_REQUIRED), server-side caps (perTxMax, dailyLimit) and how they interact with the daily bucket, local rails (Q402_MAX_AMOUNT_PER_CALL, Q402_ALLOWED_RECIPIENTS), and the API key auth model. This is far more transparent than typical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense paragraph that front-loads the core action (author a recurring rule) and then systematically covers alternatives, requirements, limits, and cancellation. Every sentence contributes essential information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (9 params, mutation, no output schema), the description covers purpose, alternatives, error conditions, scheduling behavior, server-side limits, and local policy enforcement. It is sufficiently complete for an agent to select and invoke it safely without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by illustrating cadence syntax, emphasizing the confirm:true requirement with explicit user consent, and explaining the paid-subscription rule for every chain. These examples and constraints clarify intent beyond the field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Author a new recurring-payment rule on the user's Agent Wallet.' It clearly distinguishes this from sibling tools (q402_recurring_cancel, q402_recurring_list, etc.) by defining the create action and noting single-recipient scope versus the dashboard for multi-recipient payroll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'use the dashboard for multi-recipient payroll' and 'trial keys ... should keep using q402_pay for one-shot Trial sends.' It also points to q402_recurring_cancel for stopping rules, giving clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully carries the behavioral burden. It discloses the return shape ({ enabled, allowedFeeds, dataServiceId }), the no-auth requirement, and the rejection behavior that this tool prevents. It appropriately characterizes the operation as a read-only discovery without making side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: main purpose, usage guidance, and return shape. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a discovery tool with no parameters and no output schema, this description covers all essential aspects: what it returns, why to use it, and prerequisites. It's especially strong because it tells the agent exactly how to use the returned data to avoid triggering an error later.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the schema, so the baseline is 4. The description adds relevant context about authentication (no API key) and what to do with the result, but since there are no inputs, there's nothing more to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Discover which RedStone feeds this deployment can drive triggers off') and clarifies that it also checks if the feature is enabled. It distinguishes itself from sibling tools like q402_redstone_trigger_create by positioning this as the discovery step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before q402_redstone_trigger_create and explains the consequence of using a non-allowlisted feed. Also states that no API key is required, which is a usage prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure. It states 'Read-only, no API key,' lists the returned fields (amount, token, chain, recipient, status), and explicitly notes that 'An unknown or expired id returns notFound:true (no throw).' This is transparent and helps the agent anticipate outcomes without guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, direct and front-loaded. Every sentence adds value: purpose, return details, usage guidance, and error handling. No redundant wording or unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers all essential aspects: purpose, parameters, return values, auth requirements, use cases, and error behavior. It is fully self-contained and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline is 3. The description adds context by explaining the parameter is a 'req_ id' returned by q402_request_create and that unknown/expired ids yield notFound:true, which complements the schema's pattern description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Look up a Q402 payment request by its req_ id.' It specifies the resource (payment request) and the verb (look up), and distinguishes it from sibling tools like q402_request_pay and q402_request_create by focusing on status retrieval rather than creation or payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use it to poll a request you created, or to inspect a requestId before paying it with q402_request_pay.' This clearly indicates when to use the tool and references an alternative (q402_request_pay), while also explaining behavior for unknown/expired ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral load. It clearly discloses that the tool 'MOVES FUNDS' and is a write operation, explains the sandbox-by-default behavior requiring both a live key and Q402_ENABLE_REAL_PAYMENTS=1, details the retry-safety semantics around status='uncertain' and idempotencyKey, and mentions server-managed signing and gas sponsorship. This is exemplary transparency for a financial mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is tightly structured with clear section headers (REQUIRES CONFIRMATION, SANDBOX BY DEFAULT, RETRY SAFETY) and every sentence delivers critical operational information. The front-loaded purpose statement and step-by-step usage guidance make it efficient despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no output schema, no annotations), the description covers all necessary context: authentication, chain-specific constraints, confirmation flow, sandbox mode, retry safety, and sequencing with related tools. It even addresses failure semantics (status='uncertain') and the prevent-double-spend behavior. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 8 parameters at 100% coverage, so the baseline is 3. The description adds valuable meaning beyond the schema by explaining the confirm parameter's two-phase semantics ('Call it FIRST without confirm to get a one-line preview... THEN re-call with confirm:true') and by elaborating idempotencyKey's retry behavior (re-calling with the echoed key 'replays the original result'). These additions justify a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Supplies the Agent Wallet's stablecoin (USDC / USDT) into Q402 Yield's curated lending market for the chosen chain so it starts earning supply APY.' This uses a specific verb ('supplies') and resource ('Q402 Yield's curated lending market'), and clearly distinguishes it from siblings like q402_yield_withdraw and q402_yield_reserves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use q402_yield_reserves first to show available markets + APY, and q402_yield_positions afterward to confirm the supplied balance.' It also explains the two-phase confirmation flow (call without confirm first, then with confirm) and notes chain limitations ('Other chains are not yet available'). This goes beyond mere context to give a complete usage workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so comprehensively: it discloses sandbox-by-default behavior with 'success: false' and 'sandbox: true' response markers, two-phase consent via consentToken, multi-wallet ambiguity with ambiguousWalletChoice, and the EIP-7702 delegation side effect that changes the user's wallet display. It also clarifies that confirm:true alone does not send funds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but structured with clear headings (SENDER ECHO, MULTI-WALLET DISAMBIGUATION, EIP-7702 SIDE EFFECT, TWO-PHASE CONSENT) and is front-loaded with the most critical use directive. Every paragraph addresses a distinct behavioral or safety aspect needed for a money-moving tool, so the length is justified and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex payment tool with no output schema, the description covers all key response variants (sandbox with success:false/sandbox:true, preview with needs_confirmation, senderWallet echo, ambiguousWalletChoice, postPaymentTip). It also enumerates prerequisites (Q402_TRIAL_API_KEY, Q402_PRIVATE_KEY, Q402_ENABLE_REAL_PAYMENTS) and edge cases, making the tool self-sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes all 11 parameters (100% coverage), the description adds significant meaning: it explains keyScope's auto-selection logic, walletMode's multi-wallet disambiguation, consentToken's re-derivation and two-phase flow, and confirm's requirement to also validate splits/conditions in hookParams. It also adds critical token/chain restrictions (RLUSD on Ethereum, Q on BNB, USDG on Robinhood) beyond the enum lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence is an explicit directive: 'USE THIS TOOL whenever the user asks to send, transfer, or pay USDC / USDT / RLUSD' and explicitly names the tool as the session wallet that signs locally and submits via Q402's gasless relay. It distinguishes from siblings by naming alternative tools like q402_batch_pay, q402_wallet_status, and q402_clear_delegation for related but distinct actions, and details supported chains/tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit routing rules ('Auto-routing: chain ∈ {bnb, avax} + Q402_TRIAL_API_KEY set → Trial... anything else → Multichain') and when-not-to-use guidance: if native gas tokens bounce, call q402_wallet_status and q402_clear_delegation instead. It also tells the agent never to refuse payment requests and to surface sandbox setup messages when env isn't configured, leaving no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It clearly warns 'MOVES FUNDS' and details exact prerequisites: 'requires confirm:true, a live API key, and Q402_ENABLE_REAL_PAYMENTS=1'. It also explains the two-phase consent flow ('Omit on the FIRST call... re-call with the SAME requestId plus this token to execute') and the non-redirectable nature of the payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, usage, safety warning, prerequisite, precursor step, and differentiation from siblings. It is front-loaded with the core action and remains readable despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a fund-moving, two-phase consent tool with no output schema, and the description covers all necessary context: exact usage flow, prerequisites (confirm, API key, env var), safety constraints (non-redirectable), and the billing-workflow position. It is as complete as one could expect for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds critical semantic context beyond the schema. It explains that requestId determines 'the exact amount + token + recipient the request specifies - you cannot redirect or change them,' and clarifies the consentToken's re-derivation from request terms, which is not in the schema. This meaningfully enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Pay a Q402 payment request from your own Agent Wallet, gaslessly.' It clearly distinguishes this from q402_pay by framing it as the agent-to-agent billing path: 'agent A bills with q402_request_create, agent B settles here.' This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Give it a req_ id (from a /pay link, a 402 Payment Required response, or whoever billed you)' and advises 'Call q402_request_status first to show the user what they're paying.' It also contrasts with q402_pay and q402_request_create, making the appropriate context salient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses READ-ONLY behavior, authentication via API key, that no private key is required, and that no funds move. It also explicitly states what the tool does NOT report (principal/accrued earnings), preventing hallucinated earnings claims.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('READ-ONLY - show...') and then efficiently covers output, authentication, chain scope, limitations, and parameter semantics. No sentence is wasted; the length is justified by the need to warn against unsupported earnings claims.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return fields and the aggregate USD value. It covers optional params, default wallet resolution, supported chains, and a critical functional caveat. The tool is fully specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both params described), but the description adds significant value: walletId is optional and the server resolves the default wallet from the API key; the Q402_AGENT_WALLET_ADDRESS env var is mentioned; chain filter is optional and chains are listed. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'show the Agent Wallet's current Q402 Yield lending positions' and enumerates the returned data (protocol, chain, asset, market address, position value, APY, aggregate USD). This specific verb+resource distinguishes it from transaction siblings like q402_yield_deposit and q402_yield_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this whenever the user asks...' with concrete example queries. It also explains when to pass walletId vs. omit it, and notes the optional chain filter. This clearly directs the agent on when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![q402-mcp MCP server](https://glama.ai/mcp/servers/quackai-org/q402-mcp/badges/card.svg)](https://glama.ai/mcp/servers/quackai-org/q402-mcp)

Score Badge

Copy to your README.md:

[![q402-mcp MCP server](https://glama.ai/mcp/servers/quackai-org/q402-mcp/badges/score.svg)](https://glama.ai/mcp/servers/quackai-org/q402-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/quackai-org/q402-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server