blueDEX

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

Annotations already declare readOnly, idempotent, open-world, and non-destructive, and the description adds substantial context: the specific verification fields returned and the warning to sign only when routerAllowlisted is true. This is critical safety-relevant behavioral disclosure beyond the structured metadata.

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

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

Three tight sentences with no filler. The purpose is front-loaded, the output shape is stated compactly, and the safety warning is placed prominently so the agent cannot miss it.

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

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

For a multi-chain transaction builder with no output schema, the description covers the output format and the verification workflow meaningfully. It could be slightly stronger on how inputs correspond to the quote, but it provides enough for correct invocation and safe handling.

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

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

Schema description coverage is low at 33%, and the description does not compensate by explaining any input parameters. It references a 'quoted swap' but does not clarify semantics for amount, slippageBps, or how buy/sell objects map to output. The taker and source descriptions in the schema help, but amount and slippage remain underdocumented.

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

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

Begins with a specific verb and resource: 'Build an unsigned transaction for a quoted swap.' It also clarifies the output format (EVM fields or Solana base64) and the verification block, making its role distinct from quote-fetching or execution siblings.

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

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

Clearly implies this tool is used after obtaining a quote and before signing. It gives strong safety guidance by directing the agent to verify routerAllowlisted against the allowlist from get_meta. It does not explicitly name an alternative or state when not to use it, but the quoted-swap precondition is evident.

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

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

The description discloses key behavioral traits: custodial at the venue during the swap, blueDEX never holds funds, and the flow of sending from asset to deposit address. It also mentions the refundAddress parameter's purpose. Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description adds valuable context about the custodial nature and settlement flow.

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

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

The description is concise and well-structured, with the core purpose front-loaded, followed by the flow explanation and a pointer to list_instant_assets. Every sentence adds value without redundancy.

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

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

The description covers the essential context: what the tool does, the flow, custodial behavior, and where to find asset ids. It lacks an explicit output schema, but the description explains the return value (deposit address). Minor gap: no mention of timeouts or failure handling beyond refundAddress, but overall 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.

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 parameters. The description adds context about the deposit address flow and refundAddress purpose, but doesn't add significant new 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.

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

The description clearly states the tool's purpose: opening an instant shift for assets without an on-chain DEX route, with specific examples (Tron, BTC, cross-chain). It distinguishes itself from siblings by explicitly mentioning the instant shift mechanism and the deposit address flow, which differentiates it from build_swap_transaction and plan_route.

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

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

The description provides clear context on when to use this tool (for assets with no on-chain DEX route) and mentions using list_instant_assets for ids. It doesn't explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to infer the appropriate use case.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint, destructiveHint=false), lowering the bar. The description adds one genuinely behavioral detail – data is scoped to the top liquidity pool rather than an aggregate – which is non-obvious and useful. But it omits other operationally relevant traits like history depth, data freshness, or how pool selection changes over time. No contradiction with annotations.

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

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

Two short, information-dense sentences with zero filler: the first fixes the output and scope, the second enumerates supported timeframes. The core function is front-loaded before any secondary detail, and every clause earns its place.

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

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

For a read-only tool with no output schema and 3 well-constrained params, the description covers the essentials: what is returned (OHLCV), the supported timeframes, and the pool-scoping caveat. However, with no output schema present, the description carries the burden of explaining the return shape (candle ordering, timestamp format, field structure) and any history limits, which are absent. Annotations compensate for the safety side, keeping this at a minimum-viable 3.

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

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

Schema description coverage is only 33% (only `timeframe` is documented), so the description needed to compensate for `chain` and `address`. Instead, it merely restates the timeframe enum values already present in the schema and adds no meaning for `chain` (e.g., network context) or `address` (e.g., token address format). The 'top pool by liquidity' clause is tool-level context, not parameter semantics.

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

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

The description precisely identifies the output ('OHLCV candles') and the resource ('a token'), and sharpens scope with 'top pool by liquidity', making the function unambiguous. The explicit verb comes only from the title/name ('Get'), not the description itself, so it stops short of a 5.

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

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

Usage is implied by the resource type – an agent wanting price chart data would select this tool, and the sibling set (swap building, quotes, instant shifts, onramps) is functionally distinct. However, the description states no explicit when-to-use or when-not-to-use conditions, and names no alternative, leaving routing largely to inference.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds meaningful behavioral context by enumerating the possible status values and noting that deposit/settle transaction hashes appear 'once available', which helps an agent understand the state progression.

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

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

A single sentence that front-loads the core operation, immediately specifies the id source, and packs the complete status vocabulary plus the tx-hash detail. No filler or redundant restatement of the annotations or schema.

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

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

For a simple one-parameter read-only lookup with no output schema, the description is complete: it identifies the input origin, enumerates every possible status value, and flags the additional tx-hash fields that will appear. Nothing needed to invoke the tool correctly is missing.

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

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

The schema only defines 'id' as a required string with no description, so the description carries the burden of explaining the parameter. It does so by saying the status is looked up 'by id (from create_instant_shift)', clarifying that the id is the one returned by the creation tool.

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

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

The description clearly identifies the resource: status of an instant shift looked up by id, and distinguishes this from the creation tool by referencing 'from create_instant_shift'. It lacks an explicit verb like 'get' or 'retrieve', but combined with the title the purpose is unambiguous.

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

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

The parenthetical 'from create_instant_shift' implies this tool is used after creating an instant shift and passing its id, giving useful context. However, it does not state when to prefer this over sibling tools, nor does it provide any exclusions or alternative routes.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false plus openWorldHint=false. The description adds useful behavioral context by labeling the data as 'published transparency data' and specifying what categories the agent will receive. For a parameterless read operation, there is little hidden behavior left to disclose.

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

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

Two concise sentences with no filler: the first lists the data categories, and the second gives the audit use case. Everything earns its place.

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

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

For a zero-parameter, read-only metadata tool, the description plus annotations fully orient an agent: it knows what the tool returns, why to use it, and that it is safe/non-mutating. No output schema means additional format details could help, but the stated data categories are sufficient for correct invocation.

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

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

The tool has zero parameters, so the input schema already fully conveys parameter semantics. The description appropriately focuses on the data content rather than repeating an empty schema.

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

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

The description states a specific verb and resource ('Get treasury + router allowlist') and enumerates the exact data contents: treasury addresses, router allowlist, fee schedule, and paused venues. This clearly distinguishes it from the sibling swap/quote/route tools.

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

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

It explicitly says 'Use this to audit quotes and transactions,' giving a clear context for when to invoke the tool. It does not name alternative tools or exclusions, but no sibling appears to offer equivalent audit data, making the intended usage unambiguous.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context by specifying that the tool returns the winning venue quote, every venue quote for transparency, and the fee recipient address auditable against get_meta. No contradiction with annotations.

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

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

Three sentences with no filler: the purpose is front-loaded, the return behavior is summarized, and the cross-chain capability is stated concisely. Every sentence earns its place.

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

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

With no output schema, the description usefully explains the return values: winning venue quote, all venue quotes, and the fee recipient address. It also covers a notable edge case (cross-chain EVM support). It does not mention quote expiry or error behavior, but for a read-only quote tool this is reasonably complete.

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

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

Schema description coverage is 50%; the schema documents amount and slippageBps, while the description adds cross-chain semantics for sell/buy tokens with the Arbitrum-to-Base example. It does not restate or clarify nested buy/sell object structure beyond what the schema provides, so it only partially compensates for the gap.

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

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

The description opens with a specific verb and resource: 'Get the best swap route across DEX aggregator venues.' This clearly distinguishes it from siblings like build_swap_transaction, which would construct a transaction, and get_chart, which serves a different purpose.

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

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

The description implies use when a best swap quote is needed and notes cross-chain support on EVM, but it does not explicitly state when to use this tool versus siblings such as build_swap_transaction or plan_route. No exclusions or alternative routing are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds value by clarifying the lane scope and indicating that the output is a list of ids for subsequent use. It does not detail error cases or ordering, but for a simple read-only list this is adequate.

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

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

Two tightly written sentences, front-loaded with the core purpose. No redundant phrases; every word contributes. The example id and pointer to create_instant_shift are placed at the end, but the message is immediately clear.

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

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

For a parameterless, no-output-schema tool, this description is fully sufficient. It states what is listed, what is returned, and how the output should be used. Nothing an agent needs to call it correctly is missing.

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

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

With zero parameters and 100% schema coverage, the description needs no parameter explanation. The baseline for 0 params is 4, and the description still enriches by explaining the returned id format ('usdt-tron') and its purpose, which is useful context not in the schema.

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

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

The description clearly states the tool lists assets reachable via the INSTANT lane, specifies the corridors (Tron/USDT-TRC20, BTC, stablecoin), and explicitly mentions it returns ids for use with create_instant_shift. This verb+resource+scope is specific and distinguishes it from siblings like list_onramps or build_swap_transaction.

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

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

The description advises that returned ids are to be used with create_instant_shift, giving clear usage context. It does not explicitly discuss when not to use it or compare with other listing tools, but the purpose is unambiguous enough to guide selection. A brief exclusion note could push this to 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context: blueDEX operates none of these, takes no custody, coins land in user's wallet, and only Transak and MoonPay are agent-callable (with KYC). No contradiction with annotations.

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

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

The description is long but information-dense, front-loaded with the core purpose then expanding into safety, KYC levels, and usage context. Every sentence contributes value, though it could be slightly more structured (e.g., bullet points) for scannability.

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

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

No output schema exists, so the description must convey what the tool returns. It describes the nature and categories of on-ramps (no-KYC vs KYC, agent-callable, BTC-only) well, but does not specify the exact output structure. However, for a listing tool, the description is sufficient for an agent to understand and present results.

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

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

Tool has zero parameters, so schema coverage is 100%. Baseline for 0 params is 4; the description correctly does not attempt to explain non-existent parameters. No additional parameter semantics needed.

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

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

The description clearly states the tool lists fiat on-ramps, specifying they are reputable independent services signposted by blueDEX. It distinguishes this tool from siblings by focusing on on-ramps for acquiring a first coin, with a clear verb and resource.

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

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

Explicitly states when to use: 'Surface this when a human asks how to get their first crypto.' It also provides nuanced guidance on agent-callable vs human-mediated routes and fallbacks, helping the agent decide if this tool is appropriate in a given context.

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

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

Adds substantial context beyond the readOnly/idempotent annotations: it discloses per-leg custody (non-custodial vs custodial-at-venue), fee disclosure, ordered return shape, and execution order. This is rich behavioral information for a planning tool.

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

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

Dense but well-structured: purpose and composition are front-loaded, the example clarifies the abstract parameter formats, and the final execution instruction earns its place. No filler or redundant restatement.

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

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

For a complex multi-hop planning tool with no output schema, the description fully covers return contents (ordered legs, custody, amounts, fees, total output) and next actions. It leaves little ambiguity about how to consume the result.

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

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

Schema coverage is 100% and the description mostly restates the schema's parameter formats for from/to/amount. It does add a helpful cross-chain example mapping the parameters to a real route, but it does not add meaningfully new semantic details beyond the schema.

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

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

States a specific verb and resource: 'Plan the cheapest MULTI-HOP route between ANY two assets' and decomposes it into DEX swaps and instant-lane bridges. The example and explicit leg types make it clearly distinguishable from single-hop siblings like get_swap_quote and create_instant_shift.

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

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

Clearly implies when to use this tool: whenever a multi-hop route is needed. It also gives explicit follow-up routing by stating DEX legs go through build_swap_transaction and bridge legs through create_instant_shift, but it does not explicitly contrast with single-hop planning alternatives such as get_swap_quote.

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

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

Annotations already signal read-only, idempotent, non-destructive behavior. The description adds valuable behavioral specifics beyond those hints: it returns unsigned swaps, keeps gas-positive legs only, bundles the sweep fee onto one leg, and clarifies that approval/signing is left to the user (non-custodial).

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

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

Three dense sentences front-load the purpose, then describe the input, the returned plan, the fee behavior, custody model, and supported chains without redundancy. The chain list in prose is slightly redundant with the enum but useful as a network whitelist.

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

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

The description is complete enough for selecting and invoking the tool: required inputs, defaults, supported chains, and the plan's high-level shape are all present. With no output schema, it still stops short of specifying the exact plan structure, though it names legs and approvalTarget implicitly.

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

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

Schema description coverage is 100%, so the schema already documents wallet, dust, chain, slippageBps, and targetToken. The description mostly restates defaults (USDC) and the dust-list shape in prose; the only additive context is that the caller must supply balances ('you know your own balances'). This modest addition does not push far above the full-coverage baseline.

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

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

The description opens with a specific verb and resource: 'Consolidate many small leftover token balances (dust) into one token (default USDC) on an EVM chain.' It clearly differentiates this planning tool from execution/build siblings by emphasizing that it returns an unsigned swap plan, not a signed transaction.

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

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

The description gives a clear context for use: dust consolidation, user-supplied balances, and supported chains. It does not explicitly say when not to use it or name alternatives like build_swap_transaction, but its scope is specific enough that an agent can decide appropriately.

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