Skip to main content
Glama

mev_pressure

Requires a ChainHelix API key as bearer token, or 1 cent per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. MEV pressure per pool per minute on one chain: for every pool with detected MEV in the window, rows by type (sandwich, backrun, frontrun, arbitrage, jit, nft_mev), distinct victims and attackers, profit where measured, median gas multiple, first and last event. Plus the per-minute series of the chain, or of one pool when pool is given, and the chain metrics of its newest minute. window in minutes, default 60, max 1440; limit pools, default 50, max 200. Types overlap: a backrun transaction also emits an arbitrage row, so rows is a row count. Chains covered: bnb, ethereum, polygon, avalanche

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
poolNo
chainNo
limitNo
windowNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNo
poolNo
chainNo
errorNo
poolsNo
rulesNo
sourceNo
totalsNo
minutesNo
receiptNo
generatedNo
chainMinuteNo
latestEventAtNo
windowMinutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"New value: +"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"
  2. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"New value: +"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"
  3. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4"New value: +"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"
  4. Changed3 schema fields changed
    • addedInput schema / x-aliases
      Added value: +{
      +  "limit": [
      +    "Limit",
      +    "limits",
      +    "$limit",
      +    "_limit",
      +    "Limits"
      +  ],
      +  "pool": [
      +    "pools",
      +    "_pool"
      +  ]
      +}
    • addedInput schema / x-lexicon
      Added value: +{
      +  "bundleSha256": "c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4",
      +  "name": "ChainHelix Agentic Lexicon",
      +  "resolve": "lexicon_resolve",
      +  "spec": "lexicon_spec",
      +  "version": "0.1.0"
      +}
    • addedInput schema / x-vocab
      Added value: +{
      +  "chain": "onchain.chain",
      +  "limit": "data.limit",
      +  "pool": "defi.pool",
      +  "window": "market.window"
      +}
  5. Added

TDQS

A3.9/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 burden and does so thoroughly: it discloses the bearer-token requirement and per-call payment options, row overlap semantics, that rows is a row count rather than unique transactions, and default/max bounds. It even explains a counting pitfall ('a backrun transaction also emits an arbitrage row').

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

Conciseness3/5

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

The content is dense and mostly useful, but it is a run-on paragraph that front-loads billing/auth details before stating the tool's purpose. The structural issue is noticeable though the text is not bloated.

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 covers auth, chain coverage, defaults, max bounds, and output semantics, and an output schema exists to define return shape. The chief gaps are the optional-chain behavior and pool identifier format, so it is not fully complete.

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

Parameters4/5

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

Schema description coverage is 0%, but the description compensates by giving window and limit defaults/maximums and by explaining that pool switches the output to a single pool's series. It does not give an example or identifier format for pool, so compensation is not complete.

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 defines the resource precisely: 'MEV pressure per pool per minute on one chain,' and enumerates the returned dimensions (MEV types, victims, attackers, profit, gas multiple, event windows). It does not start with an action verb and does not explicitly differentiate from MEV siblings like mev_intel, so it misses the top score.

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

Usage Guidelines3/5

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

The description gives context clues that this is a per-chain, per-pool/per-minute MEV metric tool and documents chains and limits, but it never names alternatives or states when not to use it. Usage is implied from the data shape rather than explicitly instructed.

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