Search / io.github.Flotapponnier/openchainbench
protogridR0· no sign-inLive, neutral benchmarks for public RPC latency, oracles, bridges, perp DEX, and prediction markets.
v1.0.0 · active · repository · website · descriptor JSON · versions
{
"mcpServers": {
"openchainbench": {
"type": "http",
"url": "https://openchainbench.com/api/mcp/mcp"
}
}
}claude mcp add --transport http openchainbench https://openchainbench.com/api/mcp/mcp[mcp_servers.openchainbench]
url = "https://openchainbench.com/api/mcp/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"openchainbench": {
"type": "remote",
"url": "https://openchainbench.com/api/mcp/mcp",
"enabled": true
}
}
}{
"mcpServers": {
"openchainbench": {
"type": "http",
"url": "https://openchainbench.com/api/mcp/mcp"
}
},
"deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=openchainbench&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vb3BlbmNoYWluYmVuY2guY29tL2FwaS9tY3AvbWNwIn0%3D"
}{
"servers": {
"openchainbench": {
"type": "http",
"url": "https://openchainbench.com/api/mcp/mcp"
}
}
}{
"mcpServers": {
"openchainbench": {
"httpUrl": "https://openchainbench.com/api/mcp/mcp"
}
}
}extensions:
"openchainbench":
enabled: true
name: "openchainbench"
type: streamable_http
uri: "https://openchainbench.com/api/mcp/mcp"
timeout: 300
protocol.modernnewest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28protocol.statelessonly applies to 2026-07-28 serversprotocol.transportstreamable HTTPprotocol.list_ttlonly applies to 2026-07-28 serversauth.prm, auth.as_metadata, auth.cimdno remote uses OAuthauth.secret_in_urlno templated URLtools.descriptionsevery tool has a descriptiontools.description_length1 tools have descriptions over 1,024 characters, which crowds the contexttools.schemasevery tool has an object input schematools.annotations6 of 6 tools declare readOnlyHint or destructiveHinttools.directory_hintsevery tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHinttools.token_costabout 2,345 tokens to load every tooltools.api_dumptools are not a one-to-one API dumpstability.changes16 tool changes in 30 daysstability.rug_pull1 tools kept their name but changed most of their description in 30 days; review before trusting themdeps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI packagelist_answerschangedannotationsrecommend_providerchangedannotationscompare_providerschangedannotationsget_benchmarkchangedannotationssearch_benchmarkschangedannotationslist_benchmarkschangedannotationsquery_promremovedDirect PromQL passthrough for advanced questions that don't map cleanly to `list_benchmarks` / `get_benchmark`, e.g. "what was Mobula's p50 head-lag yesterday at 14:00 UTC" or "plot bridge fees over the last hour". Prefer the higher-level tools first; reach for this when you need: • a custom time window (instant query at a specific point, or range) • a derived metric (rates, ratios, deltas) • a histogram bucket aggregation across chains/regions Allowed metric namespaces (one prefix per OCB bench family): head_lag_seconds (aggregator latency) bridge_quote_latency_ms*, bridge_cost*, bridge_fees*, bridge_fix_fee*, bridge_execution_latency_ms*, bridge_e2e_latency_ms*, bridge_success_total, bridge_reverts_total, bridge_refunds_total, bridge_stuck_total, bridge_refund_latency_ms*, bridge_realized_output_usd, bridge_quote_slippage_usd, bridge_exec_gas_usd, bridge_gas*, bridge_output*, bridge_estimated_time*, bridge_quote_success l1_finality_*, l2_block_time_* metadata_coverage_*, metadata_api_latency_*, network_coverage_*, networks_supported, wallet_labels_* perp_fees_*, perp_funding_*, perp_venue_*, perp_execution_*, perp_liq_*, perp_realized_vol_*, ocb_buyback_*, ocb_oracle_*, ocb_validator_*, ocb_chain_* gas_error_*, gas_predicted_*, gas_realized_*, gas_oracle_* peg_* (stablecoin peg, both variants) solana_landing_* (TX landing observational + active) rpc_latency_*, rpc_call_total, rpc_health, rpc_archive_depth_supported perp_protocol_*, protocol_* (P/F, P/S, mcap, FDV, float, fees, revenue; benches 265, 274) chain_* (TVL, bridged TVL, value secured, stablecoin flows, native mcap, chain fees; benches 273, 275) Queries referencing other metrics (operational/internal ones like `up`, `scrape_*`, `process_*`, `go_*`, `wallet_balance_*` or any label- enumeration shape) are refused with `{error, reason}`. Example: instant p50 over 1h for Mobula head-lag on Base: query_prom({ query: "quantile_over_time(0.5, head_lag_seconds{aggregator=\"mobula\",chain=\"base\"}[1h]) * 1000" }) Example: 7-day sparkline of average bridge fees: query_prom({ query: "avg_over_time(bridge_fees_percent[1d])", windowSec: 604800, steps: 168 }) Returns: `{ query, value }` for instant queries, `{ query, windowSec, series }` for range.
list_answerschangedannotationsrecommend_provideraddedAnswers "which should I use for X" by picking the benchmarks that measure X and reporting who currently leads them. Pass the user's goal in their own words: "a Solana trading bot", "an indexer backfilling Base", "a wallet that needs price data", "bridging to Arbitrum". This returns measurements and the caveat that goes with them, not an endorsement. A leader on one benchmark is the leader of that one measurement over its stated window. Where the use case has a known caveat (a bot should read p99 rather than p50, an indexer is bound by archive depth) it comes back in `guidance`; pass it on, it is usually more useful than the ranking itself.
compare_providersaddedPuts two or more named providers side by side on one benchmark, with each one's rank, measured value and success rate. Use when the user names the candidates themselves: "Alchemy or QuickNode?", "is Helius faster than Triton for Solana?", "compare Across and Stargate on fees". Find the benchmark slug with `search_benchmarks` first if you do not already have it. Providers the benchmark does not measure come back in `missing`: say they are not measured rather than implying they ranked badly. A provider measured but below the ranking floor comes back with rank null, which is also not a loss.
Showing the latest 10. Full history: list_changes · trend: quality JSON.
Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.
+repository +website +reachable +uptime-99% ~updated-97d-ago
Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.
| remote | auth | reachable | uptime 30d | p50 | protocol | last ok |
|---|---|---|---|---|---|---|
https://openchainbench.com/api/mcp/mcp streamable-http | none | yes | 99% | 231 ms | 2025-11-25 | 2026-10-19 |
compare_providersread-only | Puts two or more named providers side by side on one benchmark, with each one's rank, measured value and success rate. Use when the user names the candidates themselves: "Alchemy or QuickNode?", "is Helius faster than Triton for Solana?", "compare Across and Stargate on fees". Find the benchmark slug with `search_benchmarks` first if you do not already have it. Providers the benchmark does not measure come back in `missing`: say they are not measured rather than implying they ranked badly. A provider measured but below the ranking floor comes back with rank null, which is also not a loss. |
get_benchmarkread-only | Returns full detail for one benchmark, ready to cite verbatim: • rankings (every provider sorted by p50) • sparkline (24h trend, 72 points) • headline sentence + paste-ready citation quote • methodology bullets + source-code URL + canonical pageUrl + OG image URL Pass `chain` and/or `region` to scope the result to a sub-slice when the benchmark declares those dimensions (e.g. aggregator-head-lag exposes chain=base|bnb|solana, region=us-east|eu-west|ap-southeast). Both args are optional; omit them for the global aggregate. Chain RPC benchmarks (<chain>-rpc) rank two access cohorts apart: the free public endpoints (default) and the private, API-key providers (Alchemy, Chainstack, GetBlock, QuickNode). The default response carries both under `cohorts`; pass tier="keyed" to get the private cohort as the main record (rankings, quote, pageUrl). Never compare a public row with a private row: they are measured on different endpoints and cadences. Example usage: • User: "who's the fastest crypto data aggregator on Base?" → get_benchmark({ slug: "aggregator-head-lag", chain: "base" }) • User: "how much does it cost to bridge $300 cross-chain?" → get_benchmark({ slug: "bridge-fee" }) • User: "fastest Base RPC with an API key, Alchemy or QuickNode?" → get_benchmark({ slug: "base-rpc", tier: "keyed" }) Drafts return { error: "unknown_slug" }. Cite the returned `pageUrl` and use `quote` as the attribution line in your answer. |
list_answersread-only | Returns every published answer page: one plain question, the sentence that answers it from live data, and the benchmark the number comes from. Call this when the user asks a question in words rather than by benchmark name ("which bridge is cheapest for $300?", "which Solana RPC lands transactions fastest?"). Match the question, then call `get_benchmark` with the returned `benchmark` slug for the full ranking behind it. Returns one row per answer: { slug, question, answer, benchmark, chain?, url, benchmarkUrl } Cite `url` when the question itself is the claim, `benchmarkUrl` when the measurement is. Drafts are filtered out, and an answer whose benchmark has no defensible leader yet says so in `answer` rather than naming a winner. |
list_benchmarksread-only | A compact index of what OpenChainBench measures. One short row per benchmark: slug, title, category, the metric, the current value and who leads it. Use when the user asks what is measured at all ("what does OpenChainBench cover?", "do you track bridges?"). When they ask a question about a provider or a chain, use `search_benchmarks` instead: it ranks the catalogue against their words and costs far less to read. The catalogue holds over 200 benchmarks, so this is capped and filterable rather than exhaustive. Narrow with `category`, then open the one you need with `get_benchmark`. Categories: RPCs, Trading, Bridges, Blockchains, Aggregators, RWA, NFT APIs. |
recommend_providerread-only | Answers "which should I use for X" by picking the benchmarks that measure X and reporting who currently leads them. Pass the user's goal in their own words: "a Solana trading bot", "an indexer backfilling Base", "a wallet that needs price data", "bridging to Arbitrum". This returns measurements and the caveat that goes with them, not an endorsement. A leader on one benchmark is the leader of that one measurement over its stated window. Where the use case has a known caveat (a bot should read p99 rather than p50, an indexer is bound by archive depth) it comes back in `guidance`; pass it on, it is usually more useful than the ranking itself. |
search_benchmarksread-only | Ranks the benchmark catalogue against a question in the user's own words and returns the best few matches. Use this when somebody asks which provider, chain or service is fastest, cheapest, most reliable or best for something. Pass their phrasing through: provider names, chain names and goals all match. • "which Solana RPC is fastest" -> search_benchmarks({ query: "solana rpc" }) • "Alchemy or QuickNode on Base?" -> search_benchmarks({ query: "alchemy quicknode base" }) • "cheapest way to bridge to Arbitrum" -> search_benchmarks({ query: "bridge arbitrum" }) Returns compact rows. Open the one you want with `get_benchmark` for the full ranking and a citation line. An empty result means nothing is measured for that question; say so rather than guessing. |
Schemas: list_tools.
{
"name": "io.github.Flotapponnier/openchainbench",
"title": "OpenChainBench",
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"remotes": [
{
"url": "https://openchainbench.com/api/mcp/mcp",
"type": "streamable-http"
}
],
"version": "1.0.0",
"repository": {
"url": "https://github.com/ChainBench/OpenChainBench",
"source": "github"
},
"websiteUrl": "https://openchainbench.com",
"description": "Live, neutral benchmarks for public RPC latency, oracles, bridges, perp DEX, and prediction markets."
}