Agent Margin Router

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new operational context: multi-provider routing, license-aware caching, pay-per-call via x402 in USDC/USDT on Base, no API key or signup, and a 3-free-call-per-wallet tier. It stops short of describing failure behavior, cache staleness, or latency, but is well above the annotation baseline.

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

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

Four tight sentences, purpose front-loaded, then capability, then payment/access mechanics. Each sentence carries distinct information with no padding or repetition of the title.

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

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

With no output schema, the description does indicate the return shape ('Structured JSON extraction') and fully covers inputs, payment, and free-tier access. It could be stronger by noting error behavior or what the response looks like for failed extractions, but it is broadly complete for a paid, open-world extraction tool.

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

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

Schema description coverage is 100%, so every parameter (url, schema, wallet, api_key, x_payment, instructions) is already documented. The description restates the payment model but adds no syntax or format details beyond what the schema fields provide, making the baseline 3 correct.

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

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

States a specific verb+resource ('Structured JSON extraction') and enumerates the supported input formats (HTML, PDF, JS-rendered pages). None of the sibling tools (gas_fees, token_price, wallet_balance, etc.) do extraction, so the agent can route unambiguously.

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

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

Usage is only implied: the tool applies to 'any public URL' with the listed formats. There is no explicit when-to-use/when-not guidance, no statement about unsupported targets (private/authenticated URLs, rate-limited sites), and no alternatives to weigh since no sibling overlaps.

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

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

Annotations cover only readOnly and openWorld, so the description adds substantial unseen context: public-RPC aggregation with no API key, pay-per-call in USDC/USDT on Base via x402, and a 3-call free tier per wallet. It stops short of stating rate limits, cache behavior, or failure modes on unpaid calls, which would be needed for a 5.

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

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

Three dense sentences, front-loaded with what is returned and followed by data source and payment mechanics; each sentence carries information. Slightly compressed by abbreviated phrasing ('3 free calls per wallet'), but there is no filler.

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

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

With no output schema, the description steps in to describe the return shape (tiered fees plus per-transaction USD costs) and the chains covered, and it explains the payment prerequisites an agent must satisfy. Cache/pagination and error semantics for unpaid calls remain unspecified, so it is strong but not exhaustive.

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

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

Schema description coverage is 100% and the schema already documents every parameter, including the default chain 'base' and the wallet-unlocks-free-tier behavior that the description merely echoes. The description adds no format, range, or interaction detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description names the concrete resource (live EIP-1559 gas fees with slow/standard/fast tiers), the derived output (USD cost per transaction type across transfer, ERC-20 transfer, swap, NFT mint), and the exact chain set. An agent can tell this apart from token_price or market_spread without opening any schema.

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

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

Usage is only implied: an agent infers it should call this when it needs gas estimates or per-transaction cost data. There is no explicit statement of when to prefer this over token_price/market_spread, and no mention of when not to use it (e.g., for historical fees).

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the call is free and names the categories of data returned, which is useful context, but it omits latency expectations, rate limits, or whether failures signal downstream outages.

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 front-loaded sentence leading with the cost signal, then the payload. No filler, though it is terse enough that it could add one routing sentence at little cost.

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-param, annotation-covered read tool with no output schema, the description adequately conveys what the call returns. Nothing essential to invoking 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?

The tool takes zero parameters, so no parameter semantics are required. The baseline for a parameterless tool is 4, and the description introduces no misleading parameter implications.

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 ('Returns') and enumerates concrete resources: AMR service status, provider health, cache metrics. This clearly distinguishes it from the data/value siblings (gas_fees, token_price, wallet_balance), though it doesn't explicitly name a sibling.

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?

No guidance on when to call this versus alternatives. The 'Free' marker hints at a cost consideration but is not framed as a when-to-use rule, and no exclusions or preconditions are given.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: the x402 USDC/USDT on Base payment requirement, the no-signup model, and a 3-call free tier per wallet. It stops short of describing freshness guarantees or rate limits beyond the free tier.

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 zero waste: the capability and its slippage-adjusted qualifier lead, followed by venue scope and the payment model. Nothing is padded or repeated.

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 9-parameter, read-only, no-output-schema tool, the description covers the cost/auth model and what the result represents (spread and net edge). It could say more about the returned fields or quote freshness behavior, but the essentials for correct invocation are present.

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

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

Schema coverage is 100%, so the schema already documents all nine parameters including wallet, x_payment, and max_age_seconds. The description only loosely gestures at trade size ('given trade size') without adding format or interaction details beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource: a live cross-exchange crypto spread with slippage-adjusted net edge for a given trade size, scoped to major CEX venues. It is easily distinguishable from siblings like token_price or gas_fees, which do not compute cross-venue edge.

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

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

Provides useful prerequisite context – pay-per-call via x402, no API key/signup, 3 free calls per wallet – but never states when to prefer this over token_price or how to interpret results vs. a simple quote. Usage is implied rather than contrasted with alternatives.

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

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

Annotations only declare readOnlyHint=true, so the description's leading 'Free.' adds genuinely new behavioral context: the call itself costs nothing even though it exists to describe paid tools. It does not cover auth requirements, rate limits, or failure behavior for unknown tools, but for a read-only lookup it adds real value beyond the annotation.

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

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

Two tight sentences with the highest-value fact ('Free.') front-loaded, followed by the return contents and the agent-facing purpose. No filler and nothing redundant.

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

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

With no output schema, the description correctly carries the burden of describing the return payload (price, contract, pay-to wallet, network), which is exactly what an agent needs to construct a payment. It omits edge-case behavior such as an invalid or unknown tool value, keeping it just short of fully 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 coverage is 0% and the single 'tool' enum has five values with no per-value documentation. The description clarifies the parameter's intent ('for a given tool') but does not explain what each enum value means or whether the tool must be paid/available, so it only partially compensates for the coverage 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 pairs a specific verb ('Returns') with a precise resource ('the x402 payment requirements') and enumerates the returned fields (price, contract, pay-to wallet, network). It is clearly distinguishable from the sibling data tools by framing itself as the metadata lookup that precedes a payment, though it never names a sibling outright.

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?

'so an agent can construct an x402 payment' gives clear context for why and when to call it — a pre-payment pricing/metadata lookup. There are no explicit exclusions or named alternatives, but the usage condition is unambiguous for a one-parameter helper.

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

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

Annotations cover the safety profile (readOnly/openWorld), and the description adds material behavior beyond them: no API key, x402 pay-per-call in USDC/USDT on Base, and 3 free calls per wallet. It also discloses the aggregate return shape, though it does not mention rate limits or failure modes.

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 compact sentences, capability first, then pricing/free-tier. Every sentence carries distinct information and nothing is padded, though the venue parenthetical is somewhat list-heavy.

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 enumerates the return fields (median, min/max, deviation, confidence) and explains the payment/access model for a paid tool. Coverage is strong; minor gaps remain around refresh/caching and error behavior.

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

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

Schema coverage is 100%, so all seven parameters (asset, quote, venues, wallet, api_key, x_payment, max_age_seconds) are already documented in the schema. The description reinforces the venue list and free-tier wallet mechanic but adds little syntax 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.

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

States a specific verb+resource: 'Multi-venue median spot price for any major crypto asset' and names the four venues plus the aggregate outputs (min/max, deviation, confidence score). It is clearly distinct from a plain price lookup, though it does not explicitly contrast itself with the sibling market_spread.

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?

'One call instead of four' implies aggregation use, and the payment/free-tier note hints at how to make it work, but there is no explicit when-to-use vs. the sibling market_spread or any exclusions. Usage is implied rather than guided.

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 and openWorldHint, but the description goes well beyond them: it discloses the data source (public RPC nodes), that no API key is required, the per-call payment rail (x402 with USDC/USDT on Base), and a free-tier cap. These are meaningful behavioral facts an agent needs, though it says nothing about rate limits or failure/partial-chain behavior.

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

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

Two dense, front-loaded sentences with no filler; the core capability leads and the payment details follow. Slightly more text than strictly necessary, but every clause is informational rather than redundant.

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

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

For a read-only query with no output schema, the description adequately conveys what comes back (balances plus USD valuation), the supported chains/tokens, and the cost model. It is close to complete; the main omission is any pagination or partial-result/error behavior.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including chain options and token symbols. The description corroborates the chains and tokens but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource ('Native + stablecoin balances ... of any EVM wallet with USD valuation') and enumerates the exact tokens and chains covered, so the agent knows precisely what the tool returns. It does not explicitly distinguish itself from siblings like token_price or gas_fees, so it falls just short of the top mark in the absence of sibling differentiation.

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

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

The description supplies the payment/free-tier mechanics ('3 free calls per wallet', pay with USDC/USDT on Base via x402), which implies when the tool is economical to call, but it never states when to prefer this over token_price or how it relates to the other balance/price siblings. Usage is implied rather than guided.

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