Skip to main content
Glama

Cross-frontend volume attribution

attribution

Which frontend, router or interface originated on-chain DEX volume, aggregated per contract per chain. This is the dataset ClearTrace exists for: it names the venue behind volume that block explorers leave as an anonymous contract.

THE VOLUME COLUMNS ARE TWO DIFFERENT KINDS AND MUST NOT BE SUMMED TOGETHER. direct_volume_usd, aggregator_volume_usd, proxy_volume_usd and aggregator_partner_volume_usd partition total_volume_usd between them. calldata_suffix_volume_usd and erc20_fee_volume_usd are OVERLAYS: they re-describe dollars already counted in the first group, seen through a different attribution vector. A suffix figure larger than the total is therefore correct and is not a bug. Adding an overlay to a partition column double-counts.

Volumes refresh weekly and are dated to the Monday of their window, so present them as a week's volume and never as today's.

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.
projectNoFrontend or router key to filter to, e.g. 'uniswap', 'oneinch'. Omit for every attributed venue. This is the machine key, not a display name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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 / 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: +"Frontend or router key to filter to, e.g. 'uniswap', 'oneinch'. Omit for every attributed venue. This is the machine key, not a display name."
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does it well: it warns that volume columns are of two kinds, that overlays must not be summed with partition columns, and that a suffix figure larger than the total is expected behavior. It does not explicitly state read-only behavior or rate limits, but the substantive data behavior is disclosed.

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 purpose statement is front-loaded, and the critical column-semantics and freshness warnings are essential for correct use. The description is somewhat long and contains a mild editorial phrase, but every substantive sentence contributes to preventing misinterpretation.

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

Completeness4/5

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

The description is largely complete: it names the key return columns and explains their relationships, and the schema covers all three optional parameters. Since there is no output schema, it would benefit from explicit statements about row grouping or response envelope, but the core invocation and interpretation guidance is sufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The input schema already documents chain, limit, and project with defaults, fallback behavior, clamping, and accepted values; the description adds no parameter-level meaning beyond that.

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

Purpose4/5

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

The description states exactly what the tool does: it identifies which frontend, router, or interface originated on-chain DEX volume, aggregated per contract per chain. It is clear and distinguishes the tool from generic contract lookups, but it does not explicitly differentiate itself from the closely named sibling contract_attribution.

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

Usage Guidelines4/5

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

It gives strong usage context: use this tool when you need to name the venue behind anonymous contract volume, and it explains how to interpret/display results (weekly, never as today's). It does not explicitly state when to choose this tool over alternatives, but the context is clear and no exclusions are given.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources