Allows inspection of MEV-relevant activity on the Polygon blockchain, including pending mempool transactions and confirmed swaps using tools like check_pending_swaps_on_pool and check_confirmed_swaps_on_pool.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mev-mcp check pending swaps on WMATIC/USDC pool"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for inspecting MEV-relevant activity on Polygon — pending mempool traffic, confirmed swap history, and gas pricing — exposed as tools an AI agent (or you, via Claude Desktop) can call directly.
This is a diagnostic and research tool, not a production MEV detector. It's built to be honest about what it sees and what it misses, rather than to look more capable than it is.
Tool | What it tells you | Source |
| Pending transactions touching a given Uniswap v3 pool, broken down by route type, plus a self-check against confirmed history | Public mempool ( |
| Ground-truth swap count and originating contracts for a pool over a recent block range | Finalized chain state ( |
| Gas price distribution over recent blocks |
|
| Connectivity check | — |
Polygon only. Arbitrum uses a centralized sequencer with no public mempool, so pending-transaction tools aren't meaningful there.
Related MCP server: mev-history-mcp
Swaps on a given pool can be routed through many different contracts — Uniswap's own SwapRouter, SwapRouter02, UniversalRouter, or any of a long list of aggregators (1inch, Odos, Paraswap, and others). check_pending_swaps_on_pool currently decodes:
Direct calls to the pool contract
SwapRouter / SwapRouter02 single-hop swaps (exactInputSingle, exactOutputSingle) and multi-hop swaps (exactInput, exactOutput, via packed-path decoding)
UniversalRouter V3_SWAP_EXACT_IN / V3_SWAP_EXACT_OUT commands
1inch AggregationRouter v6 swaps
That's a meaningful slice of mempool traffic, but it is not exhaustive. In testing on a moderately active Polygon pool, well over half of confirmed swap volume routed through contracts outside this list — other aggregators, smart-contract wallets, and routing contracts we haven't decoded yet.
Rather than let that show up as a silent count: 0 — indistinguishable from "this pool is just quiet" — check_pending_swaps_on_pool runs a quick confirmed-swap check over a comparable window and returns a coverage_estimate field alongside the raw count:
{
"count": 0,
"routes": { "router_swap": 0, "universal_router_swap": 0, "aggregator_1inch": 0, "direct_pool_call": 0 },
"confirmed_check": { "swap_count": 4, "by_to_address": { "...": 1 } },
"coverage_estimate": "low — confirmed swaps exist on this pool but none were caught pending; likely routed through unrecognized contracts"
}Possible coverage_estimate values:
no_recent_activity — no confirmed swaps in the last N blocks (~M min); this pool appears genuinely inactive — confirmed window large enough (≥300 blocks) to trust a zero result
inconclusive — … window too short to draw conclusions — confirmed window smaller than the minimum reliable threshold
low — confirmed swaps exist on this pool but none were caught pending; likely routed through unrecognized contracts — pool is active but none of the pending transactions matched a known router
low / medium / high (ratio R: N pending caught vs M confirmed) — at least some pending matches found; ratio against confirmed volume gives a coverage signal
unknown — confirmed check failed: ExceptionType: message — the self-check itself threw an exception; raw count still stands
unknown — confirmed check returned error: … — RPC or other error from the confirmed check endpoint
If you need a quick, reliable read on whether a pool is active at all — independent of mempool coverage — use check_confirmed_swaps_on_pool directly. It reads finalized blocks, so it has no router-coverage blind spot, only the same long-tail-of-aggregators caveat in its by_to_address breakdown (you'll see contract addresses it doesn't attempt to label).
Python 3.10+
An RPC provider for Polygon with mempool (eth_subscribe) support — most free-tier providers (including Alchemy's free tier) support this for newPendingTransactions
For check_confirmed_swaps_on_pool: an eth_getLogs-capable endpoint. Free-tier plans often cap the block range per call (Alchemy's free tier: 10 blocks); the tool chunks requests automatically, configurable via MEV_MCP_LOGS_CHUNK_SIZE (default 10). On a paid plan, raising this (e.g. to 500) significantly speeds up confirmed-swap lookups.
git clone https://github.com/matiosera3-ops/mev-mcp
cd mev-mcp
pip install -e .Add to your Claude Desktop config (claude_desktop_config.json):
{
"mcpServers": {
"mev-mcp": {
"command": "python",
"args": ["-m", "mev_mcp.server"],
"env": {
"POLYGON_RPC_URL": "https://your-polygon-rpc-url",
"MEV_MCP_LOGS_CHUNK_SIZE": "10"
}
}
}
}Not yet published to PyPI — install from source for now.
Router coverage is partial. See above. Contributions adding decoders for additional aggregators (Odos, Paraswap, 0x) are welcome — the existing SwapRouter/UniversalRouter/1inch decoders in pending_swaps.py are a template for the calldata-matching pattern used.
Mempool visibility depends on your RPC provider. Different providers see different shares of the public mempool. hashes_seen / hashes_resolved in the raw tool output give you a sense of how much traffic your provider surfaces.
Free-tier eth_getLogs limits make check_confirmed_swaps_on_pool slow on a free Alchemy plan (chunking in 10-block calls). Fine for occasional diagnostic use; not built for high-frequency polling.
No Arbitrum mempool support, structurally — there isn't a public one to watch.
MIT
Queries already-mined (confirmed) blocks for Uniswap v3 Swap events on
the given pool. Returns the total swap count and a breakdown by the to
address of each swap transaction (router, aggregator, or direct caller).
This is NOT a mempool tool — it reads finalized on-chain state via eth_getLogs. Use it to establish ground-truth swap volume and compare against check_pending_swaps_on_pool: a large gap between confirmed volume and pending detections points to a mempool coverage issue, not swap scarcity. Polygon only.
Args: pool_address: the Uniswap v3 pool contract address to query chain: only "polygon" is currently supported lookback_blocks: number of recent confirmed blocks to scan (default 600 ≈ 20 min at ~2 s/block on Polygon)
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | polygon | |
| pool_address | Yes | ||
| lookback_blocks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it reads finalized on-chain state via eth_getLogs, is not a mempool tool, and only works on Polygon. Despite no annotations, the description fully conveys the behavioral traits (read-only, confirmed blocks, chain constraint).
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?
Concise yet complete: two short paragraphs, front-loaded with purpose, then behavior, then usage guidance, then parameter details. Every sentence adds value without redundancy.
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?
Covers tool purpose, input parameters, output (total count + breakdown), chain constraint, and relationship to sibling tool. No output schema, but description sufficiently explains return value. Complete for its complexity.
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?
Despite 0% schema description coverage, the description explains each parameter: pool_address as the Uniswap v3 pool address, chain as only polygon, lookback_blocks as number of recent confirmed blocks with default 600 (~20 min on Polygon). Adds context and default meaning beyond schema.
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?
Description clearly states it queries confirmed blocks for Uniswap v3 Swap events on a given pool, returns total swap count and breakdown by 'to' address. It explicitly distinguishes from sibling tool check_pending_swaps_on_pool (confirmed vs pending) and specifies Polygon only.
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 explicit guidance: use to establish ground-truth swap volume and compare with check_pending_swaps_on_pool to diagnose mempool coverage issues. Also clearly states what it is NOT (mempool tool), aiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watches the public mempool for pending transactions touching a given Uniswap v3 pool — either direct calls to the pool, or single-hop swaps routed through a known Uniswap v3 router (SwapRouter or SwapRouter02) whose calldata references both of the pool's tokens.
Polygon only — Arbitrum uses a centralized sequencer with no public mempool, so this isn't available there. See the README for details.
Note: only catches single-hop router swaps (exactInputSingle / exactOutputSingle). Multi-hop swaps (exactInput / exactOutput) encode the route as a packed path that isn't decoded yet — see roadmap.
Args: pool_address: the pool contract address (catches direct calls) token0: address of one of the pool's two tokens token1: address of the pool's other token chain: only "polygon" is currently supported duration_seconds: how long to watch, capped at 60 seconds (default 15)
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | polygon | |
| token0 | Yes | ||
| token1 | Yes | ||
| pool_address | Yes | ||
| duration_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: watches mempool, duration cap of 60 seconds, only single-hop swaps decoded, and platform restriction. This provides complete transparency for an AI agent.
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?
Well-structured with clear sections: purpose, platform restriction, limitations, and parameter list. Front-loaded with core action. The Args list is slightly verbose but necessary due to missing schema descriptions.
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?
Given 5 parameters, no output schema, and no annotations, the description is comprehensive. It covers all parameters, constraints, limitations, and platform specifics, providing sufficient context for effective tool usage.
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?
Despite 0% schema coverage, the description includes an Args section explaining each parameter's purpose: pool_address, token0, token1, chain (only polygon), duration_seconds (capped at 60). Adds meaning beyond schema names.
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 clearly states it watches the mempool for pending transactions touching a specific Uniswap v3 pool, including direct calls and single-hop router swaps. It distinguishes from the sibling 'check_confirmed_swaps_on_pool' by focusing on pending vs confirmed.
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?
Explicitly states it is only for Polygon and not available on Arbitrum due to centralized sequencer. Also notes limitation to single-hop swaps and directs to README for details, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the gas price distribution (base fee + priority fee percentiles) over the last N blocks. Works on any supported chain — does not require mempool access, just standard eth_feeHistory.
Args: chain: "polygon" or "arbitrum" block_count: number of recent blocks to sample (default 20, max 1024)
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| block_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it uses standard eth_feeHistory and does not require mempool access, adding value beyond parameter names. No annotations are provided, so the description carries the burden well. Could mention that it returns a distribution but not the exact structure.
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 concise sentences plus a clean Args list. Front-loaded purpose, no wasted words, efficient structure.
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?
Covers main purpose, parameter details, and implementation context. Lacks explicit return value description but the purpose implies what to expect. Good given simplicity and lack of output schema.
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?
With 0% schema coverage, the description adds meaning for both parameters: lists specific chain values (polygon, arbritrum) and describes block_count with default and max. Slightly inconsistent with 'any supported chain', but still helpful.
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 clearly states it returns gas price distribution percentiles over the last N blocks, using a specific verb and resource. It distinguishes from sibling tools like swap checks and hello, which are unrelated.
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?
It mentions working on any supported chain and not requiring mempool access, providing context for when to use. However, it lacks explicit when-not or alternative tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simple connectivity check — confirms the MCP server is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a simple connectivity check with no side effects, which is adequate but lacks additional behavioral context such as idempotency or latency expectations.
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?
The description is a single sentence that is concise, direct, and front-loaded with the core purpose. Every word is meaningful with zero redundancy.
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?
Given the tool's simplicity (zero parameters, output schema present), the description provides complete context for an agent to understand its purpose and use. No additional details are necessary.
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 has no parameters, so the description adds no information beyond the schema. Per the guideline, zero parameters sets a baseline of 4. The schema coverage is 100%, and the description is consistent.
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 clearly states it is a connectivity check to confirm server reachability, with a specific verb 'check' and resource 'connectivity'. It is distinct from sibling tools about swaps and gas prices.
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 implies the tool should be used to verify server reachability. Although no explicit exclusions or alternatives are provided, the context of sibling tools makes the usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: confirmed swaps vs. pending swaps are clearly differentiated, gas prices and connectivity are separate concerns. No overlap exists.
All tools use snake_case with consistent verb_noun patterns (check_confirmed_swaps_on_pool, check_pending_swaps_on_pool, get_gas_price_percentiles, hello). The pattern is predictable and easy to understand.
4 tools is slightly below average but appropriate for a focused MEV monitoring server. The set covers core functionality without unnecessary bloat, though could benefit from one or two additional tools for breadth.
Covers main areas (swap history, mempool monitoring, gas data) but has notable gaps: multi-hop swap decoding missing, only Polygon for swaps, Arbitrum limited to gas. No tool for pool metadata or token details.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Crypto market intelligence, token rug-checks, and wallet verification in one MCP server.
MCP server for Fuse Network: balances, tokens, staking, DeFi data, swaps and on-chain transactions.
Tenderly MCP server for blockchain dev — simulate, debug, and test on 100+ networks.
MCP server for Renzo protocol data, including chains, vaults, operators, and ezETH metrics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matiosera3-ops/mev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
