Server Quality Checklist

Tool Scores

• get_transaction_historyA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses key behavioral traits: it returns specific data fields (transaction IDs, statuses, chains, timestamps) and supports pagination via cursor. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'Get' implies reading). The description adds value but doesn't fully compensate for the lack of annotations.

  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 zero waste: the first sentence states the purpose and return data, the second adds pagination support. It's front-loaded with the core functionality and efficiently structured without unnecessary details.

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

  Completeness3/5

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

  Given no annotations and no output schema, the description provides basic completeness for a read operation: it states what data is returned and mentions pagination. However, for a tool with 3 parameters and no structured output definition, it could benefit from more detail on response format, error handling, or limitations. It's adequate but has clear gaps in behavioral context.

  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 schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema: it mentions pagination via cursor, which is already covered in the cursor parameter description. No additional parameter semantics are provided, so the baseline score of 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the verb ('Get') and resource ('past Relay bridge and swap transactions for a wallet address'), specifying the scope of transactions (bridge and swap) and the target (wallet address). It distinguishes from siblings like get_transaction_status (which checks individual transactions) and get_bridge_quote/get_swap_quote (which provide estimates rather than history).

  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 usage for retrieving historical transaction data for a wallet, but doesn't explicitly state when to use this tool versus alternatives like get_transaction_status (for single transaction details) or other query tools. It mentions pagination support, which provides some context for handling large result sets, but lacks explicit guidance on use cases or exclusions.

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

• estimate_feesA
  4/5.0
  Behavior3/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 does well by stating this is a non-committal estimation tool (not execution) and describing the return format breakdown. However, it lacks details about potential limitations, error conditions, rate limits, or authentication requirements that would be important for a fee estimation 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 perfectly concise with three sentences that each earn their place: first states the core purpose, second describes the return format, third provides usage context. No wasted words, well-structured and front-loaded with the most important 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 fee estimation tool with 6 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the non-execution nature, return format breakdown, and usage scenarios. The main gap is the lack of output schema, but the description compensates by describing the return format ('breakdown of gas fees, relayer fees, and total cost impact').

  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 schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about what the tool does with those parameters (estimating fees for bridges/swaps). This meets 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 clearly states the tool's purpose with specific verbs ('estimate fees for a bridge or swap') and distinguishes it from execution tools like 'execute_bridge' by emphasizing 'without committing to execution'. It explicitly identifies the resource (fees) and scope (bridge/swap operations).

  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 this tool ('useful for comparing routes or showing users expected costs'), which implicitly differentiates it from execution tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools like 'get_bridge_quote' or 'get_swap_quote'.

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

• get_supported_tokensA
  4/5.0
  Behavior3/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 describes the search functionality and return format (token symbol, name, address, chain availability), but lacks details on rate limits, authentication needs, error conditions, or pagination behavior beyond the 'limit' parameter. This is adequate but leaves gaps for a search 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 front-loaded with the core purpose in the first sentence, followed by usage guidance and return details. Every sentence earns its place with no wasted words, making it highly efficient and 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?

  Given the tool's moderate complexity (search with filtering), no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage context, and return format, but could benefit from more behavioral details (e.g., performance expectations or error handling) to fully compensate for the lack of structured fields.

  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 schema fully documents all four parameters. The description adds no additional parameter semantics beyond what's in the schema, but the baseline is 3 when schema coverage is high. The description does imply the tool's purpose aligns with the parameters (e.g., searching with 'term'), but doesn't enhance the schema's details.

  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 specific verbs ('Search for tokens supported by Relay across chains') and resources ('tokens'), distinguishing it from siblings like get_supported_chains (which focuses on chains rather than tokens) and get_swap_quote (which is for quotes, not token discovery).

  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 this tool ('Use this to find token contract addresses before getting quotes'), which implicitly suggests it's a preparatory step for tools like get_swap_quote or execute_bridge. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings.

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

• get_swap_quoteA
  4/5.0
  Behavior3/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 key behavioral traits: it's a read-only operation (returns a quote, not executes), outputs estimated amounts/fees/time, and supports cross-chain swaps. However, it lacks details on rate limits, error conditions, or authentication needs, which are important for a financial 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 efficiently structured in two sentences: the first states the purpose and scope with helpful examples, and the second specifies the return values. Every sentence adds critical information with zero waste, making it easy 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?

  Given the complexity (cross-chain swaps, 7 parameters) and no annotations/output schema, the description is reasonably complete: it covers purpose, scope, and return values. However, it could improve by mentioning prerequisites (e.g., wallet connectivity) or error handling, which would be valuable for an agent.

  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 schema fully documents all 7 parameters. The description adds minimal value beyond the schema—it mentions 'optionally across chains' which aligns with destinationChainId, but doesn't explain parameter interactions or provide additional semantics. Baseline 3 is appropriate when schema does the heavy lifting.

  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 specific action ('Get a quote for swapping'), identifies the resources involved ('different tokens'), and distinguishes it from siblings like 'execute_bridge' (which performs the actual swap) and 'get_bridge_quote' (which is for bridging, not swapping). The examples ('ETH on Ethereum → USDC on Base') provide concrete 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?

  The description provides clear context for when to use this tool ('for swapping between different tokens, optionally across chains') and implies alternatives through sibling tool names like 'execute_bridge' (for execution) and 'get_bridge_quote' (for bridging quotes). However, it does not explicitly state when NOT to use it or directly compare to these alternatives.

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

• execute_bridgeA
  4.3/5.0
  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 effectively describes key behaviors: it returns steps (not executes them), outlines the multi-step flow (approve/deposit for ERC-20, deposit for native), explains step kinds ('transaction' vs 'signature'), specifies how to handle returned steps (via wallet tool), mentions default sender behavior if wallet connected, and notes it returns a requestId for tracking. It doesn't cover error cases or rate limits, but provides substantial operational context.

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

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose. It uses bullet points and clear sections to explain steps and kinds, avoiding unnecessary repetition. While somewhat lengthy due to detailed explanations, every sentence earns its place by providing essential operational guidance. A slight deduction for density, but overall efficient.

  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 tool's complexity (multi-step bridge/swap flow) and lack of annotations or output schema, the description does a strong job of providing context. It explains what the tool returns (steps, requestId), how to use the output (via wallet tool), and covers key behavioral aspects. It could briefly mention error handling or response format, but for a tool with no output schema, it's largely 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?

  Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema—it only implicitly relates to 'sender' by mentioning wallet connection defaults. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance 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 clearly states the tool's purpose: 'Get a quote and unsigned transactions for a bridge or swap via Relay. Returns ALL steps required to complete the transfer.' It specifies the verb ('Get'), resource ('quote and unsigned transactions'), and distinguishes from siblings like get_bridge_quote (which likely only returns a quote) and get_swap_quote by emphasizing it returns the full transaction steps needed for execution.

  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 guidance on when to use this tool: for obtaining the steps to execute a bridge/swap via Relay. It distinguishes from alternatives by noting that after calling this tool, you must pass the steps to the 'wallet' tool with action 'execute' for actual execution. It also clarifies the relationship with sibling tools like get_transaction_status for tracking.

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

• get_bridge_quoteA
  4.4/5.0
  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 effectively describes what the tool does (returns estimates and breakdowns) and clarifies it's for quoting only (not execution), which is useful context. However, it doesn't mention potential limitations like rate limits, error conditions, or whether the quote is time-sensitive, leaving some behavioral aspects uncovered.

  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 perfectly concise and well-structured in just two sentences. The first sentence clearly states the purpose, scope, and return values, while the second provides crucial usage guidance. Every word earns its place with no redundancy or fluff.

  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 tool's moderate complexity (6 parameters, no output schema, no annotations), the description provides excellent contextual completeness. It clearly explains what the tool does, when to use it, and what it returns. The only minor gap is the lack of output schema, but the description adequately describes the return values (estimated output amount, fees breakdown, time estimate).

  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, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about the tool's purpose that helps understand parameter usage. This meets the baseline of 3 when schema coverage is high.

  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 specific verbs ('Get a quote for bridging') and resources ('the same token from one chain to another'), and distinguishes it from sibling tools by explicitly mentioning when to use get_swap_quote instead. It provides concrete examples (ETH on Ethereum → ETH on Base) and specifies the return values (estimated output amount, fees breakdown, time estimate).

  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 provides usage guidelines by stating 'Use get_swap_quote instead if you want to change the token type,' which clearly differentiates when to use this tool versus an alternative. This gives the agent specific direction on tool selection based on the user's intent.

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

• get_relay_app_urlA
  4.4/5.0
  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 effectively explains that this tool generates a URL for users to open in their browser to initiate transactions via the UI, which is valuable context beyond what the schema provides. However, it doesn't mention potential rate limits, authentication requirements, or error conditions.

  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 perfectly concise and front-loaded. The first sentence states the core purpose, the second explains the user action, and the third provides critical usage guidance with a clear alternative. Every sentence 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?

  For a tool with 7 parameters, no annotations, and no output schema, the description does well by clearly explaining the tool's purpose, usage context, and behavioral characteristics. However, it doesn't describe what the generated URL looks like or provide examples of the output format, which would be helpful given the lack of output schema.

  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 schema already documents all 7 parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema, but it does provide context about how the parameters are used ('pre-filled bridge/swap parameters'). This meets the baseline expectation when schema coverage is high.

  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: 'Generate a deep link to the Relay web app with pre-filled bridge/swap parameters.' It specifies the exact action (generate a deep link) and resource (Relay web app), and distinguishes it from sibling tools by explicitly contrasting it with get_transaction_status for tracking purposes.

  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 guidance on when to use this tool ('to START a new transaction via the Relay UI') and when not to use it ('do NOT use it to check on an in-progress transaction'). It also names a specific alternative tool for tracking purposes: 'For tracking, use get_transaction_status with the requestId.'

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

• get_supported_chainsA
  4.4/5.0
  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 the return format ('Returns chain IDs, names, native currencies, and status') and the tool's purpose in the broader workflow. However, it doesn't mention potential rate limits, authentication needs, or pagination 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?

  Two sentences with zero waste: the first states purpose and return values, the second provides explicit usage guidance. Every word earns its place, and key information is front-loaded.

  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 read-only tool with no annotations and no output schema, the description provides adequate context about what it does and when to use it. However, without an output schema, it could benefit from more detail about the return structure beyond the listed fields.

  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 schema already documents the single optional parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score 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 clearly states the specific action ('List all blockchain networks'), the resource ('supported by Relay'), and the purpose ('for bridging and swapping'). It distinguishes from siblings by focusing on chain metadata rather than transactions, fees, or 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?

  Explicitly states when to use this tool: 'Use this to resolve chain names to chain IDs before calling other tools.' This provides clear guidance on its role in the workflow and distinguishes it from alternatives like get_supported_tokens or transaction-related tools.

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

• walletA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing key behaviors: the 60-second timeout for status, that execute handles multi-step flows automatically, that private keys never leave the device, and the blocking nature of status. It could improve by mentioning error handling or rate limits.

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

  Conciseness3/5

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

  The description is front-loaded with purpose and actions, but includes lengthy bash command examples and installation instructions that could be separated. While informative, some sections (like the full python code) are verbose for a tool description.

  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 tool with 3 parameters, no annotations, and no output schema, the description provides substantial context: workflow sequences, parameter requirements, behavioral details, and integration instructions. It lacks explicit output descriptions but compensates with procedural guidance.

  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 description coverage is 100%, so baseline is 3. The description adds value by explaining when parameters are required (chainIds for 'pair', steps for 'execute') and providing context about the steps array ('Contains all steps to execute in order'), elevating 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 clearly states the tool's purpose: 'Connect a user's wallet via WalletConnect' with specific actions (pair, status, execute, disconnect). It distinguishes from sibling tools by focusing on wallet connection and transaction execution rather than quoting, estimating, or querying data.

  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 usage guidelines including a 'Typical flow' section (pair → render QR → status → execute_bridge → execute → get_transaction_status), when to call each action, and prerequisites like requiring chainIds for 'pair' and steps for 'execute'. It also specifies the critical sequence after calling pair.

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

• get_transaction_statusA
  4.5/5.0
  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 effectively describes the tool's behavior: it's a read-only status check (implied by 'Check'), discloses the possible status outcomes with explanations (waiting, pending, success, failure, refund), and provides operational context (Relay handles cross-chain delivery automatically, polling frequency). It doesn't mention rate limits or authentication needs, but covers the core behavioral aspects 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 well-structured and appropriately sized. It front-loads the core purpose, then provides status details, and concludes with important usage notes. While slightly longer than minimal, every sentence adds value (status explanations, workflow context, polling advice). No redundant or wasted content.

  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 tool's moderate complexity (status checking with specific outcomes), no annotations, and no output schema, the description provides strong contextual completeness. It explains the status meanings, workflow integration, and polling behavior. The main gap is lack of explicit return format details, but the status explanations partially compensate for no output schema.

  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 has 100% description coverage, so the baseline is 3. The description adds significant value beyond the schema by explaining the parameter's origin ('requestId returned from execute_bridge or from a quote's steps[].requestId') and contextualizing its use in the workflow. This enhances understanding beyond the schema's basic type information.

  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 purpose as 'Check the status of a Relay bridge or swap transaction' with the specific verb 'check' and resources 'Relay bridge or swap transaction'. It clearly distinguishes from siblings like get_transaction_history (which retrieves past transactions) and execute_bridge (which initiates transactions).

  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 usage guidance: it specifies when to use ('Use the requestId returned from execute_bridge'), when not to use (the user does NOT need to do anything else after execution completes), and alternatives (implied that other tools like execute_bridge or get_bridge_quote are for different purposes). It also includes polling frequency advice ('Poll every 5-10 seconds').

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