Skip to main content
Glama

cleartrace

by com.cleartracedata
OverviewDiscussionsAdmin

On-chain transaction revert rates

revert_rates

The share of a venue's routing transactions that fail on-chain, per chain. Reported separately from slippage because reliability and price are different questions.

DO NOT RANK ACROSS EXECUTION MODELS. A revert rate measures reliability only where the failing transaction is the user's own -- a 'router' venue, where the user signs and submits the swap. On a batch-auction or intent venue a solver settles, and an order that cannot be filled never becomes a transaction at all, so its on-chain revert rate is structurally near zero no matter how well or badly it fills. Sorting every venue by revert rate puts those at the top and means nothing. comparable_only (the default) returns only the rows that may legitimately be ranked against each other.

Read user_revert_rate_pct when present: the headline rate on some cells stays inflated by address-rotating spam senders that no per-sender filter separates cleanly, and the user-only figure is the measured genuine-user experience. Each row carries its execution_model and a revert_comparable flag; quote them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoOne of: ethereum, base, arbitrum, optimism. Omit for all four; an unrecognised value is not an error and falls back rather than failing, so pass one of the four or nothing.
limitNoRows to return, 1-100, default 20. Values outside that range are clamped, not rejected. The ceiling is deliberately low because results land in a context window, where a large page evicts the conversation.
projectNoVenue key to filter to, e.g. 'uniswap', 'oneinch'. Omit for every venue. Match the `project` value returned by this or `attribution`; it is not a display name.
comparable_onlyNoDefault true, and leave it true unless you know why not. It restricts rows to venues whose execution model makes a revert rate comparable at all. Setting it false returns batch-auction and intent venues whose near-zero on-chain revert rate is structural, not a reliability signal, and ranking those against routers is the error this flag exists to prevent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / chain / description
      Added value: +"One of: ethereum, base, arbitrum, optimism. Omit for all four; an unrecognised value is not an error and falls back rather than failing, so pass one of the four or nothing."
    • addedInput schema / properties / comparable_only / description
      Added value: +"Default true, and leave it true unless you know why not. It restricts rows to venues whose execution model makes a revert rate comparable at all. Setting it false returns batch-auction and intent venues whose near-zero on-chain revert rate is structural, not a reliability signal, and ranking those against routers is the error this flag exists to prevent."
    • addedInput schema / properties / limit / description
      Added value: +"Rows to return, 1-100, default 20. Values outside that range are clamped, not rejected. The ceiling is deliberately low because results land in a context window, where a large page evicts the conversation."
    • addedInput schema / properties / project / description
      Added value: +"Venue key to filter to, e.g. 'uniswap', 'oneinch'. Omit for every venue. Match the `project` value returned by this or `attribution`; it is not a display name."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden. It discloses the comparable_only default behavior, the structural near-zero rates for non-router venues, spam-sender inflation of headline rates, and the presence of execution_model and revert_comparable flags on each row. This goes well beyond a generic statement of what the tool returns.

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 definition, then organized around the ranking caveat, the comparable_only guidance, and the user-rate caveat. It is dense but every sentence earns its place by conveying a real usage trap or output interpretation point.

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?

There is no output schema, so the description appropriately names key return fields (user_revert_rate_pct, execution_model, revert_comparable) and tells the agent to quote them. It could be slightly more explicit about the full row shape, such as the presence of chain and project columns, but the essential semantics for correct use are covered.

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 even without parameter details in the tool description. The schema already documents defaults, clamping, allowed chain values, and the meaning of comparable_only, so the description adds little new parameter-level meaning beyond reinforcing the same caveat.

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 first sentence states precisely what the tool measures: 'The share of a venue's routing transactions that fail on-chain, per chain.' It distinguishes the metric from slippage by saying 'reliability and price are different questions,' which separates it from a likely sibling like execution_benchmarks.

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-not guidance: 'DO NOT RANK ACROSS EXECUTION MODELS' and explains why ranking batch-auction/intent venues by revert rate is meaningless. It also tells the agent to keep comparable_only as default, to read user_revert_rate_pct when present, and to quote the row-level fields, leaving little room for misinterpretation.

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

All cleartrace toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources