# com.cleartracedata/cleartrace (remote · cleartracedata.com)

Neutral on-chain execution benchmarking: slippage, revert rates, MEV, and DEX frontend attribution.

- Trust score: 70/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- remote · `cleartracedata.com`: 70/100 (this document), [markdown](https://verifymcp.io/servers/com-cleartracedata-cleartrace/cleartracedata.md), [page](https://verifymcp.io/servers/com-cleartracedata-cleartrace/cleartracedata)

## Channel facts

- Endpoint: `https://cleartracedata.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Endpoint Security**: 49/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 7 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS enforcement could not be verified: the plaintext port answered with HTTP 406, which proves neither a plaintext path nor enforcement.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2154 tokens (~307/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 77/100
  - Stability observed for 23 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 7 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the com.cleartracedata/cleartrace MCP server?

com.cleartracedata/cleartrace is a hosted endpoint at https://cleartracedata.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-cleartracedata-cleartrace 'https://cleartracedata.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-cleartracedata-cleartrace": {
      "url": "https://cleartracedata.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-cleartracedata-cleartrace": {
      "type": "http",
      "url": "https://cleartracedata.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-cleartracedata-cleartrace]
url = "https://cleartracedata.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-cleartracedata-cleartrace": {
      "type": "remote",
      "url": "https://cleartracedata.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-cleartracedata-cleartrace --url 'https://cleartracedata.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-cleartracedata-cleartrace:
    url: "https://cleartracedata.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-cleartracedata-cleartrace": {
      "Transport": "http",
      "Url": "https://cleartracedata.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-cleartracedata-cleartrace -t streamable-http -u 'https://cleartracedata.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-cleartracedata-cleartrace": {
      "type": "http",
      "url": "https://cleartracedata.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-19 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-14 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-12 (score 67, +1)

No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-10 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-09 (score 65, +3)

- [functional regression] Schema quality: 215 → 307
- [functional improvement] Tool coverage: 0% → 100%
- [cosmetic] “attribution” reworded the description of “chain”
- [cosmetic] “attribution” reworded the description of “limit”
- [cosmetic] “attribution” reworded the description of “project”
- [cosmetic] “contract_attribution” reworded the description of “address”
- [cosmetic] “contract_attribution” reworded the description of “chain”
- [cosmetic] “execution_benchmarks” reworded the description of “chain”
- [cosmetic] “execution_benchmarks” reworded the description of “limit”
- [cosmetic] “explain_transaction” reworded the description of “chain”
- [cosmetic] “explain_transaction” reworded the description of “deep”
- [cosmetic] “explain_transaction” reworded the description of “price”
- [cosmetic] “explain_transaction” reworded the description of “tx_hash”
- [cosmetic] “request_api_key” reworded the description of “company”
- [cosmetic] “request_api_key” reworded the description of “email”
- [cosmetic] “request_api_key” reworded the description of “name”
- [cosmetic] “request_api_key” reworded the description of “use_case”
- [cosmetic] “revert_rates” reworded the description of “chain”
- [cosmetic] “revert_rates” reworded the description of “comparable_only”
- [cosmetic] “revert_rates” reworded the description of “limit”
- [cosmetic] “revert_rates” reworded the description of “project”

### 2026-09-07 (score 62, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-05 (score 61, +41)

- [security regression] HSTS header: unverified → fail
- [security regression] HTTPS: pass → unverified
- [security improvement] DNSSEC: unverified → pass
- [security improvement] Injection markers: unverified → pass
- [security improvement] TLS certificate: unverified → pass
- [security improvement] Transport: fail → pass
- [security] Authorization: Authorisation not fully verified: no authorisation is required to call this server, and 7 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
- [functional regression] Schema quality: 233 → 1508
- [functional regression] Schema quality: unverified → fail
- [functional improvement] Tool coverage: unverified → 100
- [functional] Stability: fail → 0.27
- [functional] This server's schema is too large to store in full, so we cannot compare its tools day to day

## MCP tools (7)

### `execution_benchmarks` (~258 tokens)

DEX and aggregator execution benchmark

Rank DEXs and aggregators by realized execution quality: median slippage against a 1-minute VWAP baseline, expressed as a score of 0-100 (higher means less slippage).

This score measures SLIPPAGE ONLY. Revert rates and MEV exposure are tracked as separate metrics and are deliberately not folded in, so do not present this as an overall 'best execution' ranking -- a venue can score well here and fail often, and the caller has to ask `revert_rates` to find that out.

Execution quality is not uniform across chains: pass a chain for a single-chain ranking, or 'all' for the blended cross-chain rollup, and do not describe the blend as if it were one chain's result.

Input parameters:

- `chain` (string): One of: ethereum, base, arbitrum, optimism, or 'all' (the default) for the blended cross-chain rollup. Do not describe the blend as one chain's result.
- `limit` (integer): 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 convers…

### `revert_rates` (~459 tokens)

On-chain transaction 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 parameters:

- `chain` (string): 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.
- `comparable_only` (boolean): 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 ven…
- `limit` (integer): 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 convers…
- `project` (string): 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.

### `attribution` (~348 tokens)

Cross-frontend volume 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 parameters:

- `chain` (string): 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.
- `limit` (integer): 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 convers…
- `project` (string): 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.

### `contract_attribution` (~230 tokens)

Attribution and label for one address

What ClearTrace knows about a single contract or wallet address: its per-chain volume split across the four attribution vectors, plus any label resolved for it.

Most useful on the ANONYMOUS routers and proxies that aggregate views leave unnamed -- that is the differentiated question this answers. Known, named protocol contracts are often keyed by name rather than address upstream and may return nothing here, so an empty result for a famous router is not evidence the address is obscure.

An address that resolves to no label is reported with a null label. Report that as 'not identified', which is what it means: these are genuinely anonymous deployments, and guessing an operator from volume or deployer alone has been wrong before.

Input parameters:

- `address` (string, required): A single contract or wallet address, 0x-prefixed hex. Case-insensitive; checksummed or lowercase both work. One address per call.
- `chain` (string): One of: ethereum, base, arbitrum, optimism. Omit to return the address's split across all four, which is usually what you want, since the same deployment often appears on several.

### `explain_transaction` (~302 tokens)

Explain one transaction's routing and origin

Classify a single transaction against the attribution engine: which frontend or router originated the trade and by which evidence, the pools it touched, any fee recipients, and whether it was sandwiched.

Confidence is per-vector and is reported per result -- a calldata suffix is strong evidence a specific frontend tagged the swap, while a fee recipient is indirect evidence and is never rated high. Pass that qualification through instead of stating the frontend flatly.

\`estimated_volume_usd` (only with price=true) is a best-effort spot price on the dominant leg. It is an approximation for orientation and must never be quoted as a settlement figure. Fee amounts are exact raw token integers with no decimals or pricing applied. deep=true costs more upstream credits; leave it off unless a shallow classification came back unattributed.

Input parameters:

- `chain` (string): One of: ethereum, base, arbitrum, optimism. Defaults to ethereum, and an unrecognised value falls back to ethereum rather than failing, so pass the transaction's actual chain explicitly.
- `deep` (boolean): Run the deeper classification pass. Slower. Worth setting only when the default pass came back unattributed.
- `price` (boolean): Include price and value context alongside the routing classification.
- `tx_hash` (string, required): The transaction hash, 0x-prefixed hex. Must exist on `chain`: this does not search the other chains, so a hash from the wrong chain returns nothing rather than an error.

### `gas_prices` (~110 tokens)

Live gas prices per chain

Current gas price on each supported chain, from RPC.

On the L2s (Base, Arbitrum, Optimism) this is the EXECUTION gas price only and excludes the L1 data availability fee, which is a real and sometimes dominant part of an L2 transaction's cost. Any cost estimate built from this figure on an L2 is a lower bound and should be labelled as one; comparing an L2 'cost' against Ethereum's on this basis overstates the L2's advantage.

### `request_api_key` (~214 tokens)

Get a free ClearTrace API key

Mint a free API key that multiplies this server's rate limits by 10x. Requires an email address.

The key changes LIMITS ONLY. Every figure served here is public and identical with or without one, there is no paid tier, and no data is gated behind it -- so present this as raising a ceiling, never as unlocking content. Ask the user before submitting their email; do not invent an address to satisfy the argument. The key is returned once and cannot be shown again, so surface it to the user verbatim.

Input parameters:

- `company` (string): Optional. Where they work.
- `email` (string, required): The user's own email address. ASK THEM FOR IT; never invent one to satisfy this argument. The key is mailed nowhere and returned once in the response, so this is a lead record, not a delivery channel.
- `name` (string): Optional. The user's name.
- `use_case` (string): Optional, one line on what they are building. The single most useful field here.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-cleartracedata-cleartrace/cleartracedata#diagnostics

## Score history

- 2026-09-20: 70
- 2026-09-19: 70
- 2026-09-18: 69
- 2026-09-17: 69
- 2026-09-16: 68
- 2026-09-15: 68
- 2026-09-14: 68
- 2026-09-13: 67
- 2026-09-12: 67
- 2026-09-11: 66
- 2026-09-10: 66
- 2026-09-09: 65
- 2026-09-08: 62
- 2026-09-07: 62
- 2026-09-06: 61
- 2026-09-05: 61
- 2026-09-04: 20
- 2026-09-03: 60
- 2026-09-02: 59
- 2026-09-01: 59
- 2026-08-31: 59
- 2026-08-30: 58
- 2026-08-29: 56
- 2026-08-28: 57

## Common questions

### What is the com.cleartracedata/cleartrace MCP server?

com.cleartracedata/cleartrace is an MCP server listed in the public MCP registry as com.cleartracedata/cleartrace. Neutral on-chain execution benchmarking: slippage, revert rates, MEV, and DEX frontend attribution. This page covers its hosted endpoint (https://cleartracedata.com/mcp).

### Is the com.cleartracedata/cleartrace MCP server safe to use?

com.cleartracedata/cleartrace scores 70 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the com.cleartracedata/cleartrace MCP server expose?

com.cleartracedata/cleartrace exposes 7 tools: execution_benchmarks, revert_rates, attribution, contract_attribution, explain_transaction, and 2 more. Their descriptions and schemas cost roughly 1,921 tokens of context every time the server is loaded.

### Does the com.cleartracedata/cleartrace MCP server require authentication?

No. We connected to com.cleartracedata/cleartrace without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the com.cleartracedata/cleartrace MCP server still maintained?

com.cleartracedata/cleartrace is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://cleartracedata.com/mcp
- Website: https://cleartracedata.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-cleartracedata-cleartrace/cleartracedata.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-cleartracedata-cleartrace/cleartracedata.json
- HTML version of this page: https://verifymcp.io/servers/com-cleartracedata-cleartrace/cleartracedata