Skip to main content
Glama
Baneado98

Mempool Doctor

by Baneado98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

_mcp-template-gated — MCP server template WITH the paywall gate baked in

This is the reusable factory template for every NEW MCP in the fleet. It is born with the server-side paywall gate already wired, so a new MCP can never again ship the premium tier for free (the bug that made conversion impossible on the first 10 servers).

The gate (the whole point)

  • src/mcpServer.ts — the locally-installed package. The FREE tier (deep=false) runs here. The PREMIUM tier (deep=true) does NOT run here: it is forwarded to the hosted /pro/run endpoint with Authorization: Bearer <KEY>. No key → an upsell (the premium is never executed for free).

  • src/server.ts — the hosted side. /pro/run is gated by two coexisting payment lanes:

    • x402 (USDC per call, for AI agents) via x402-express.

    • Stripe prepaid API key (for humans) — a valid Bearer key skips x402. The 402 body always shows BOTH lanes (pay_with_card_stripe + x402 accepts).

  • src/stripeLane.ts — Stripe Checkout → webhook mints an API key into KV.

  • src/kv.ts — Cloudflare KV (key store + funnel counters), degrades gracefully.

  • src/engine.ts — EXAMPLE engine. Replace run(input,{deep}) with the real logic. Keep the contract: deep=false cheap/local, deep=true premium/server-only.

Related MCP server: mev-history-mcp

Make a new MCP from this template

  1. Copy the folder: cp -r _mcp-template-gated <new-name>.

  2. Replace placeholders across the repo:

    • Mempool Doctor → human name, e.g. dns-doctor

    • mempool-doctor → npm/url slug, e.g. dns-doctor

    • SERVICE_KEY → the buyer's env var, e.g. DNS_DOCTOR_KEY (PowerShell one-liner is in the comment block of scripts/rename.txt.)

  3. In package.json/server.json/stripeLane.ts env defaults set:

    • STRIPE_KEY_PREFIX (e.g. dns_), STRIPE_PLAN_NAME, SERVICE_KEY_ENV, SERVICE_PRO_URL, homepage/PUBLIC_BASE_URL = the Vercel URL.

  4. Write the real engine.ts and the real tool schema/description in mcpServer.ts.

  5. npm install && npx tsc — must build clean.

Verify the gate (regla 7 — not done until this passes)

FORCE_LISTEN=true PORT=8899 PRO_API_KEYS=test_key X402_ENABLED=true node dist/server.js &
curl -s -o /dev/null -w "%{http_code}\n" "http://127.0.0.1:8899/run?target=x"                                  # 200 (free)
curl -s -o /dev/null -w "%{http_code}\n" "http://127.0.0.1:8899/pro/run?target=x"                              # 402 (no key)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer test_key" "http://127.0.0.1:8899/pro/run?target=x"  # 200 (paid key)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer wrong"    "http://127.0.0.1:8899/pro/run?target=x"  # 402 (bad key)

MCP stdio: deep=true without a key must print the UPSELL (never run premium); deep=false returns the local free result.

Production env (set in Vercel, sourced from config/)

STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, CLOUDFLARE_ACCOUNT_ID/API_TOKEN/KV_NAMESPACE_ID, optionally SERVICE_KEY. Everything degrades gracefully if a lane is unconfigured — the x402 gate + 402 always work even with no Stripe/KV. Never set the deep engine to run client-side.

Available Tools

1 tool
check_txA

Look up an EVM transaction live and answer 'is it stuck?'. Pass ':' or just a txhash (defaults ethereum; supports base/polygon/arbitrum/optimism/bsc). Reports pending/mined/not-found, compares the fee cap to the current base fee, returns MINED/HEALTHY/UNDERPRICED/STUCK. deep=true adds a concrete replace-by-fee + cancel gas plan and nonce-gap detection (premium). Read-only; never signs.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYes'<chain>:<txhash>' or a txhash (0x + 64 hex). Chains: ethereum, base, polygon, arbitrum, optimism, bsc.
deepNoWhen true, runs the PREMIUM tier. Requires an API key (set MEMPOOL_DOCTOR_KEY in your MCP env); without one you'll get instructions to unlock it. The free verdict needs no key.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description fully discloses behavior: it's read-only, never signs, and explains the deep parameter's additional features (replace-by-fee plan, nonce-gap detection). It does not detail output format, but this is acceptable given no output schema.

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?

Two sentences pack all necessary information: purpose, input format, chains, verdicts, deep parameter details, and read-only nature. No wasted words; front-loaded with core purpose.

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

Completeness5/5

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description provides complete context for correct usage, including input syntax, optional feature, and access requirements.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant value by explaining the target format (chain:txhash or just txhash, default ethereum) and the deep parameter's behavior and API key requirement, surpassing the schema's minimal descriptions.

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 description clearly states the tool's purpose: 'Look up an EVM transaction live and answer is it stuck?'. It specifies the input format, supported chains, and possible verdicts, making the tool's function unambiguous.

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?

The description explains when to use the tool (to check transaction status and get recommendations) and conditions for deep=true (requires API key). It lacks explicit when-not-to-use guidance but provides sufficient context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedcheck_tx
Deploy Server
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

TDQS

A4.6/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity. The tool's purpose is clearly described and distinct.

Naming Consistency5/5

Single tool naming is inherently consistent. The verb_noun pattern 'check_tx' is clear and follows a common convention.

Tool Count4/5

One tool is minimally sufficient for a focused utility like checking transaction status. While it limits functionality, it is appropriate for a single-purpose server.

Completeness4/5

The tool covers its intended purpose well, including multi-chain support and deep analysis options. No obvious gaps for a read-only transaction status checker.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • Mempool MCP Server

    alexandresanlim
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides real-time Bitcoin blockchain and mempool data to AI clients, allowing access to comprehensive Bitcoin network information through various data tools.
    31
    6 npm
    5
    MIT

  • mev-history-mcp

    sebastiancoombs
    F
    license
    Not graded
    quality
    C
    maintenance
    Pay-per-call MCP server for EVM MEV history, offering sandwich check, MEV exposure score, and pool density analysis on multiple chains with USDC payment on Base.
    -

  • @bitcoinbenji/mcp

    ocbenji
    A
    license
    B
    quality
    C
    maintenance
    MCP server offering 26 Lightning-paid tools for Bitcoin mempool intelligence and sovereign on-prem AI inference, with no third-party APIs and pay-per-call in sats.
    26
    8 npm
    1
    MIT