How many crypto MCP servers answer today?
Listed MCP endpoints, checked daily: who answers a stranger, who asks for a key.
- As of2026-10-27
Checked
85
of 85 listed endpoints, on 2026-10-27 from 05:27 UTC
Answered anonymously
52
initialize + tools/list, ≥1 tool · 61.2%
Asked for credentials
25
401, or a 400 naming the missing key — live, not anonymous
No handshake
8
timeout, DNS, TLS, 404/405/3xx/5xx — from where we checked
What this cannot tell you
- One check from one place at one time. A server can answer from one network and not another; a TLS or DNS failure can belong to the path, not the server.
- A credential gate is a design choice, not a failure. Those servers are live; an agent without a key simply cannot use them.
- A handshake is not a working tool. It proves a process is listening and speaks MCP; no tool is judged by it.
- The population is this index's own list of MCP endpoints, not every crypto MCP server that exists.
- This is not an uptime figure. Endpoints with no reading in the counted run are excluded rather than counted against.
- Denominator
- Every listing in the index, not retired, that publishes an MCP endpoint URL (85), read in the latest daily run that covered at least half of them (85 read on 2026-10-27).
- Method
- Once a day, per listed endpoint, the handshake a Streamable-HTTP client makes, with no credentials: POST initialize, keep the Mcp-Session-Id if one is sent, POST notifications/initialized, then tools/list (8-second deadline per request; scripts/probe-live.mjs). Since 2026-09-26 two fallbacks apply: one same-origin trailing-slash redirect is followed (/mcp to /mcp/, no other redirect), and a 404/405 to that POST is retried over the legacy HTTP+SSE transport (GET the /sse URL, then initialize on the message URL it names, same origin only); a row read that way carries transport legacy_sse and the URL that answered (endpoint_used). Answered = initialize returned a protocolVersion and tools/list named at least one tool. A 401, or a 400 naming a missing credential, counts as asking for credentials and a 403/429 as refused; neither is a failure. The counts describe the latest run that read at least half the listed endpoints; an endpoint with no reading in that run is excluded rather than counted against.
- What it proves
- That a process is listening and speaks the protocol to a stranger (2,797 tools advertised across the answering servers). It proves nothing about whether those tools return correct data, are maintained, or suit what you intend to do.
- Rows
- Every endpoint, its outcome and the time of its reading: /api/export/mcp-handshakes.json. The day-by-day record per server is on status and reliability.
- Reproduce
Recount this page from the export:
curl -s https://satohub.ai/api/export/mcp-handshakes.json | python3 -c 'import json,sys,collections; d=json.load(sys.stdin); print(d["run_at"], dict(collections.Counter(r["outcome"] for r in d["endpoints"] if r["counted"])))'
Re-check any row yourself, with nothing but curl (replace <endpoint>):
curl -si -X POST <endpoint> -H 'content-type: application/json' -H 'accept: application/json, text/event-stream' --data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"repro","version":"1"}}}'A protocolVersion in the answer is the first half. For the tool list, send notifications/initialized and then tools/list to the same URL, each carrying the Mcp-Session-Id header the server returned, if it returned one.
A second column: answering a call is not answering a handshake
Every server that answered the handshake is asked one read-only call, chosen from its own tool list: the name must start list_, get_ or search_, must not contain send, sign, transfer, swap, buy, sell, execute, delete, write or create anywhere in it, and must take no required arguments and declare none that look like an address, a key, a secret or an amount. It is called with no arguments, under a ten-second deadline. 24 of the 26 asked returned a result (92.3%).
26 handshake-answering servers were not asked, because no tool qualified; not asked is excluded, never counted as a failure. A call that came back with an error is not a verdict on the server either — often it is the server saying an argument it did not mark as required is in fact required.
Data CC-BY-4.0 — attribution: data by satohub.ai. A handshake is a reading of one moment; unknown is a value here and never means zero.
Reference
QuestionsWhat people ask about this pageShowHide
Questions this page answers
- How many crypto MCP servers are actually answering today?
- In the latest full check on 2026-10-27, 52 of 85 listed endpoints completed initialize and then listed at least one tool for a client that sent no credentials. 25 answered but asked for credentials first, and 8 did not complete a handshake from where we checked. 85 listings publish an MCP endpoint in total; 0 were not read in that run and are excluded rather than counted as down.
- Is this an uptime figure?
- No, and it is deliberately not called one. It is the outcome of our own checks on one day. A check can fail because of our timeout, our network, or a host that simply refuses unfamiliar clients, and we cannot always tell which — so this is described as what our probe observed, never as someone else's downtime.
- What happens when a server asks for credentials?
- 25 endpoints answered but declined an anonymous client on 2026-10-27: a 401, a 400 naming the missing credential, or a 403 or 429. A credential gate is a design choice, not a failure — the server is live, and an agent without a key cannot use it — so it is counted on its own line.
- What does a successful handshake prove?
- That a process is listening and speaks the protocol: it returned a protocol version and, usually, a tool list — 2,797 tools advertised across the answering servers. It proves nothing about whether those tools return correct data, are maintained, or are appropriate for what you intend to do with them.
- Does a server that answers the handshake also answer a call?
- Not always, and the gap is the reason this second column exists. 24 of the 26 servers we asked on 2026-10-27 returned a result from one read-only call, a share of 92.3%. 26 handshake-answering servers were not asked at all, because none of their tools qualified as a read-only call; they are excluded rather than counted against.
- Which tool do you call, and how is it chosen?
- One tool per server per day, chosen from the server's own tool list: the name must begin list_, get_ or search_, must not contain send, sign, transfer, swap, buy, sell, execute, delete, write or create anywhere in it — so get_swap_quote is refused despite the prefix — and the tool must take no required arguments and declare none that look like an address, a key, a secret or an amount, even optionally. It is called with no arguments at all, under a ten-second deadline. If no tool qualifies, the server is not asked.
- If the call comes back with an error, is the server broken?
- Not necessarily, and this page does not say so. A common answer is the server telling us that an argument it did not mark as required is in fact required, or that its connection has to be unlocked first — which is the server working exactly as designed. The record keeps the server's own words beside the result, so an argument it wanted can be told apart from a backend that has fallen over.
- Where is the per-server list, and how do I check it myself?
- Every row this page is counted from is in the public export at /api/export/mcp-handshakes.json: the listing, its endpoint URL, the outcome, the tool count and the time of the reading. Pick any row and re-run the handshake with curl — the command is on this page — and you should get the same outcome, or a dated reason why not.
SourcesWhere the data comes fromShowHide
Sources — the Model Context Protocol specification
Cite this pagePlain text, APA or BibTeXShowHide
Cite this
52 of 85 listed crypto MCP servers answered and listed their tools without a key; 25 asked for a key and 8 did not connect, as of 2026-10-27.
Sato Hub, "How many crypto MCP servers answer today?", https://satohub.ai/numbers/mcp-servers-that-answer, as of 2026-10-27. Data CC-BY.
How this was measured
- Method
- Once a day, each listed MCP endpoint gets the handshake an anonymous client makes (initialize, then tools/list, 8-second deadline per request), and it answered when a protocolVersion came back and tools/list named at least one tool.
- Window
- The latest daily probe run that read at least half the listed endpoints.
- Data date
- MCP call
- none — No MCP tool returns this count: the banked mcp_alive_rate row counts a handshake alone, over the endpoints probed that UTC day, so it can differ from the page.
- URL
- https://satohub.ai/api/export/mcp-handshakes.json
- Recount
curl -s https://satohub.ai/api/export/mcp-handshakes.json | python3 -c 'import json,sys,collections; d=json.load(sys.stdin); print(d["run_at"], dict(collections.Counter(r["outcome"] for r in d["endpoints"] if r["counted"])))'
Machine source
- Handshake export (JSON): https://satohub.ai/api/export/mcp-handshakes.json