Developers / MCP

Let your agents choose the right RPC, not just any RPC.

A real-time decision layer for selecting RPC endpoints across chains. The MCP server exposes the same ranking engine that powers rpcscan.xyz wallet routing, so every tool call returns a decision derived from live probe telemetry, not a static record.

Endpoint: https://mcp.rpcscan.com · Auth: none for the read tools listed below · Caching: 30 s edge TTL

What actually happens when you call `rpcscan.fastest`

rpcscan.fastest does not return a static list. It evaluates every endpoint we have for the chain in real time using:

Latency percentiles (p50 / p95) across the most recent probe window
Success rate (recent window, with failures penalised rather than silently dropped)
Block-height freshness vs. observed chain head
TLS posture: PQ class > cipher strength > cert key + signature alg > chain validity
Misconfiguration penalties (no OCSP, no SCTs, expired-soon, broken chain, capped at −20)
Provider stability history, where repeat regressions count against future picks

The output is a weighted decision, not "lowest latency." That is the entire point of the page: fast classical RPCs are still classical - and a fast endpoint with a broken cert chain will get filtered out before it can drain a wallet.

Why not just hardcode an RPC?

Hardcoding a single RPC URL leads to:

Silent degradation. Your endpoint slows down, your dApp slows down, nobody alerts.
Regional latency cliffs. What was fast in us-east is 800 ms in Singapore.
Outages with no fallback. One CDN incident takes you offline.
Inconsistent block freshness. A lagging node returns stale state and your tx fails.
Exposure to weaker TLS. The cheap RPC you grabbed two years ago is still on classical X25519 and may be the one being recorded.

RPCScan continuously re-ranks endpoints and routes around failures automatically. The MCP tools expose that decision so agents can do the same.

Tools

Each tool advertises a determinism class: stable (cached within the 30 s edge window, so repeated calls return identical output), fresh (re-evaluated per call), or fuzzy (best-effort, ranking may drift). Agents should pick the tool that matches the determinism the caller needs.

rpcscan.fasteststable within cache window

Returns exactly one endpoint. Stable within the 30 s edge-cache window.

The single best RPC URL for a chain. Selection blends p50 / p95 latency, recent-window success rate, block-height freshness vs. chain head, TLS posture (PQ class > cipher > cert key+sig > misconfig penalty), and provider stability history. Not a "lowest latency" lookup - a weighted decision.

{
  "tool": "rpcscan.fastest",
  "arguments": { "chain": "base" }
}

Response

{
  "chainId": 8453,
  "chainSlug": "base",
  "recommendedUrl": "https://8453.rpcscan.xyz",
  "score": 94,
  "tlsClass": "pq-hybrid",
  "tlsGroup": "X25519MLKEM768",
  "p50Ms": 38,
  "p95Ms": 87,
  "successRate24h": 99.94,
  "headLagBlocks": 0,
  "provider": "publicnode",
  "lastProbedSecAgo": 12,
  "fallbacks": [
    "https://base.llamarpc.com",
    "https://mainnet.base.org"
  ]
}

rpcscan.reportfresh per call

Returns the full ranked dataset for a chain. Use when you need control, filtering, or fallback logic of your own.

Every endpoint we have probed for the chain, with the same per-component scoring data the score-breakdown UI uses. Includes latency percentiles, success rate over multiple windows, current TLS group + cipher + cert + score, observed misconfig codes, last-probed timestamp.

{
  "tool": "rpcscan.report",
  "arguments": { "chain": "ethereum" }
}

rpcscan.comparestable within cache window

Top N endpoints side-by-side. Avoids forcing the agent to parse the full report when all it wants is "show me three options."

Returns the highest-ranked N endpoints with metric columns aligned. Best for "give the user a choice" or "rotate across the top three" patterns.

{
  "tool": "rpcscan.compare",
  "arguments": { "chain": "ethereum", "limit": 5 }
}

rpcscan.pqstable within cache window

Filters endpoints by post-quantum class.

Pass class = "pq-pure" | "pq-hybrid" | "any-pq". Returns endpoints negotiating that class on the most recent successful probe. Use this when the calling app has explicit forward-secrecy requirements (institutional flows, MEV bots, long-lived sessions).

{
  "tool": "rpcscan.pq",
  "arguments": { "chain": "ethereum", "class": "pq-hybrid" }
}

rpcscan.providersstable within cache window

Provider rollup with stability + PQ-adoption stats.

Per-provider aggregates (Cloudflare, Google, Ankr, PublicNode, Alchemy, …): how many endpoints we observe under that provider, their median TLS score, what fraction of their endpoints have transitioned to PQ in the last 90 days. Useful for "should I trust this provider" research.

{
  "tool": "rpcscan.providers",
  "arguments": { "days": 7 }
}

rpcscan.searchbest-effort fuzzy

Fuzzy resolver across chains, providers, RPC URLs, explorer hosts. Best-effort, not guaranteed to be deterministic across cache windows.

For when the agent has a free-text identifier ("op mainnet", "8453", "rpc.ankr.com") and needs the canonical chain record. Returns ranked candidates so the caller can disambiguate.

{
  "tool": "rpcscan.search",
  "arguments": { "q": "base mainnet" }
}

Agent-style examples

Real workflows compose multiple tools. The MCP layer is designed for agents that chain calls together, not just one-shot lookups.

Use rpcscan.fastest for Arbitrum, then call eth_blockNumber.
If the request fails, retry with the next best endpoint from rpcscan.report.

Find a Base RPC endpoint with PQ-hybrid TLS and p95 under 100ms.
(call rpcscan.pq with chain=base, class=pq-hybrid; filter result by p95Ms < 100)

List all Ethereum endpoints, then drop any with classical-only TLS
or a broken chain.
(call rpcscan.report; filter where tlsClass != "classical" and !issues.includes("broken-chain"))

Compare the top 5 Ethereum endpoints and present them to the user
in a table with score, latency, PQ class, and provider.
(call rpcscan.compare with chain=ethereum, limit=5)

Determinism vs. freshness

Responses are edge-cached with a ~30 s TTL. Within that window: stable tools return identical output for identical inputs. Repeated calls are safe to memoise. After the TTL:rankings may shift based on fresh probe data. So an agent that gets a different "fastest" for Ethereum a minute apart isn't seeing a bug; it's seeing the routing layer respond to a real change in upstream conditions.

Trust model

RPCScan does not proxy or modify JSON-RPC responses. The MCP tools return metadata and routing decisions only.
Wallet RPC URLs (<chainId>.rpcscan.xyz) forward traffic to the upstream we picked, but do not alter request or response payloads.
All rankings are derived from observable probe data, and every component of every score is queryable per-endpoint at /tls/score-breakdown?url=….
The MCP server is read-only. There is no write surface.

Failure handling

If no endpoints meet health thresholds for a chain:

rpcscan.fastest returns the best available candidate plus a degraded: true flag and a reason string ("all-classical", "no-recent-success", "head-stale").
Wallet routing through rpcscan.xyz automatically rotates across the fallback list.
Downstream clients should treat degraded responses as a signal to back off retries rather than hammering the chosen endpoint.

Regional awareness

Latency is currently measured from a single probe region. Future versions will expose region-specific rankings (measurement already multiplexes across pools), and the response shape includes a probeRegion field today so agents can tell where the numbers came from.

Quickstart

Point your MCP-compatible client (Claude Desktop, Cursor, Windsurf, custom agent) athttps://mcp.rpcscan.com.
Tools auto-discover, with no manual registration. Call rpcscan.fastest with a chain name or chainId and you have a routing decision.
Optional: install the typed SDK for non-MCP clients.

npm install @rpcscan/mcp

import { RpcscanMCP } from '@rpcscan/mcp';

const rpcscan = new RpcscanMCP();
const best = await rpcscan.fastest({ chain: 'ethereum' });
// best.recommendedUrl, best.score, best.tlsClass, best.fallbacks[]

Use cases that compose well

Autonomous agents that rotate RPCs intelligently between calls.
Security tooling that hard-filters classical-only or low-score endpoints.
Monitoring bots that alert on TLS-posture regressions (subscribe to /regressions).
Wallet integrations that pick a fresh endpoint per transaction instead of pinning.
Research and analytics: pull the full PQ-adoption dataset programmatically.

HTTP API vs. MCP

Use	HTTP API	MCP
Manual curl / browser	✓ direct	✗ requires MCP client
Shell scripts / cron	✓	✓ via SDK
LLM agents / Claude / Cursor	awkward	✓ native
Auto-discovery of tool surface	-	✓
Determinism class advertised	-	✓ per tool
Same edge cache, same data	✓	✓

Schema & spec

MCP-compliant tool descriptors are published at https://mcp.rpcscan.com/schema. The same data is available as OpenAPI for HTTP clients at /api. Response shapes are versioned, and breaking changes ship behind a new tool name (e.g. rpcscan.fastest.v2) so existing agents don’t break silently.

Status & uptime: /health. Live PQ adoption: /pq-adoption. Real-incident motivation for why this layer exists: /security/incidents.

What actually happens when you call rpcscan.fastest