DEV Community: Eidon Ze

State of the MCP Registry, week of 2026-10-19

Eidon Ze — Mon, 19 Oct 2026 07:57:41 +0000

State of the MCP Registry, week of 2026-10-19
by ka, mcpreflight

Every Monday we re-scan the whole official MCP Registry with a read-only check. We send an initialize request, then a tools/list request. We never call a tool, never use a credential, never attempt a payment, and never retry a failing endpoint into apparent health. Everything below is reproducible with one open-source command, and the per-server reports and raw JSON are published.

Headline
Of 9,991 remote endpoints in the official registry, 4,783 complete a clean anonymous handshake. That is 47.9 percent. The remaining 5,208 split into three groups that are not the same thing and should stop being reported as one number.

3,171 endpoints require authentication by design. They answer an anonymous request with 401 and a WWW-Authenticate header, and several publish RFC 9728 protected-resource metadata. These are not broken. We report them as AUTH_GATED as a first-class status.
1,984 endpoints give no anonymous response at all. Some are auth-gated without advertising it, some are simply down. From outside we cannot separate those two, and we say so rather than guess.
53 endpoints fail outright.
The published figure from earlier in October was 4,879 clean handshakes, or 48.8 percent. That number was computed before authentication was split out as its own status, so endpoints that require a login were counted as having given no anonymous handshake. Both numbers are correct for the status scheme in force when they were produced, and the weekly series now uses the split scheme.

Paid endpoints and the shape of the 402 challenge
We also probe the x402 payment endpoints found in the registry, read-only, and fingerprint the challenge each one returns. Two numbers are reported on purpose and must not be conflated. Real 402 counts endpoints whose paid resource answered with a 402 status at all. A valid challenge counts only those whose 402 also named the scheme, the network, the amount and where to pay.

Cohort of 293 endpoints, two consecutive weeks:

week cohort clean handshake rate auth gated no response failed
2026-10-15 293 218 74.4% 0 74 1
2026-10-19 293 212 72.4% 2 78 1
The same seller cohort lost two points of handshake success in one week. A 402 status on its own is not a working challenge, and a single handshake pass rate hides that gap, which is why we report the challenge shape separately.

What a server costs you before you ask it anything
On a reachable endpoint, the tools/list payload is what a client loads into context before the user has typed anything.

Median: 1,663 tokens
Heaviest observed: 245,006 tokens, on a server advertising 281 tools
Endpoints above 10,000 tokens: 479
Endpoints above 20,000 tokens: 138
Method limit, stated plainly: tokens are estimated as payload bytes divided by four, because we do not run a model tokenizer. Treat these as an order of magnitude, not a precise count.

Method and limits
Read-only. initialize and tools/list, or a discovery request. No tool is invoked, no credential is used, no payment is attempted.
Endpoints behind authentication are classified, never counted as failures.
Discovery of paid x402 resources is partial by design, because /.well-known/x402 is not universal, so the paid cohort covers only endpoints that publish their paid resources.
A single week can include transient network failures. The weekly series is the signal, not any individual scan.
Reproduce

Plain Text

1
2
npx @eidonze/mcpreflight schema
npx @eidonze/mcpreflight baseline
Per-server reports and JSON: https://xka0085-byte.github.io/mcpreflight/trust/

Citation
ka, mcpreflight, "State of the MCP Registry, week of 2026-10-19", https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html

If you quote these figures, cite mcpreflight. The weekly cadence is the point: this is a time series, not a one-off audit, and the two-week x402 movement above is only visible because the same cohort is re-probed every week.

How a GET probe makes working x402 endpoints look broken

Eidon Ze — Sat, 17 Oct 2026 09:32:23 +0000

A census of x402 endpoints is only as good as the request it sends. Send the wrong one and a perfectly healthy payment server reads as dead.

We run a read-only census of the MCP registry every Monday, and we separate the x402 payment endpoints inside it from the rest. While building the drift check for that cohort, we hit a false negative class that is worth writing down, because it inflates almost every number in this space.

what we found

Take verifi.cloud. It publishes /.well-known/x402, which is the discovery document that tells an agent where its paid resources live. It lists two resources, /verify and /verify-unlock.

Probe either one with GET and you get a 404. Cannot GET /verify. If you stop there, you record a working payment service as broken.

Probe the same URL with POST and you get a clean 402, with proper x402 v2 headers. The PAYMENT-REQUIRED header decodes to a full challenge document with an accepts array listing two assets, one USDC and one EURC, each with its network, amount, payTo address and a max timeout. That is a healthy, spec-aware endpoint.

Same URL. Same second. Two answers, and only one of them is the truth.

why it happens

An x402 challenge often depends on the request body. The price can be a function of what the caller asks for, so the server refuses to quote before it sees the body, and its routing only mounts the POST handler. That is a legitimate design, not a bug.

It is also common. the402.dev publishes a directory of 16,322 endpoints and reports 7,423 of them answer only to POST. Nearly half.

So any census that probes with a single method will misclassify a large slice of this ecosystem. The failure runs in both directions. A GET only probe calls POST only servers broken. A POST only probe misses the ones that quote on GET.

what we changed

We now try GET first, and fall back to POST when GET does not produce a challenge, and we record which method actually returned the 402. When neither does, we say so instead of guessing. Endpoints with a templated path, like /tx/:hash, cannot be probed without inventing a value, so they are marked as not probed rather than scored.

That is the difference between a number and a measurement.

the part that is actually useful to an operator

A one time census tells you where you stand. It does not tell you when you break. The thing that fails silently on a payment endpoint is drift.

A refactor, a dependency bump, a new asset added to the accepts list. The endpoint still answers, the price is still quoted, and one field quietly changed shape, which is enough for an agent to stop paying. You find out when a customer tells you, or you find out on your own schedule.

So we added two commands to mcpreflight. baseline reads your paid endpoint once and writes a small json file with the challenge shape. drift re-reads it and exits 1 when that shape has moved, printing a field level diff of exactly what changed.

npx @eidonze/mcpreflight baseline https://your-api.example/paid --method=POST
npx @eidonze/mcpreflight drift https://your-api.example/paid --method=POST

Commit the baseline file, run the drift check on every push through the GitHub Action, and a broken challenge fails the build before it reaches a buyer.

The fingerprint is semantic. It compares the normalized accepts fields and the dialect, so whitespace, key order or a rotating signature in the raw response is never reported as drift.

what this is not

Read only. No wallet, no signing, no settlement, no payment, no retries. We never complete a payment, so nothing here proves that paying returns a resource. We also do not certify pricing, security or content quality.

why the method matters more than the number

Every census in this space reports a health percentage. Almost none of them publish which request they sent, which means the percentages are not comparable and the differences are not signal. We publish the method, the cohort definition and the per endpoint result, so anyone can re-derive the number instead of trusting it.

The weekly drift table is here and it updates every Monday.

x402 cohort and drift tracking: https://xka0085-byte.github.io/mcpreflight/x402-endpoint-inspector.html

Registry census: https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html

Source: https://github.com/xka0085-byte/mcpreflight

If you quote these figures, cite mcpreflight. The point of re-running the cohort weekly is that the number keeps moving, and a moving number needs a named source.

mcpreflight scanned all 293 x402 payment endpoints in the MCP registry. They pass handshakes at 74.4%, well above the rest.

Eidon Ze — Sat, 17 Oct 2026 02:56:04 +0000

mcpreflight scanned all 293 x402 payment endpoints in the MCP registry. They pass handshakes at 74.4%, well above the rest.

This is the second report from mcpreflight, a read-only checker for MCP servers and x402 endpoints. The first one covered the whole registry. This one zooms into the payment corner of it, because that corner behaves differently and nobody has the numbers.

what we measured

We took every remote endpoint in the official MCP Registry whose title, description, or URL mentions x402 or HTTP-402. That gave 293 endpoints. Then we sent each one two anonymous JSON-RPC requests over HTTP, initialize and tools/list, and validated the tool schemas that came back. We never called a tool, never signed anything, never touched a wallet.

Result. 218 of 293 pass a clean anonymous handshake. That is 74.4%. The registry-wide baseline from the same weekly scan is 48.8%. So the payment cohort is roughly 25 points healthier than average. One endpoint fails outright, and 74 give no anonymous response at all.

One note on what 74.4% measures, because it is easy to read too much into it. It is a clean anonymous MCP handshake, initialize plus tools/list. It is not a verdict on the x402 payment challenge itself. We parse the challenge document as a separate and stricter check, and that number is not in this post. So read 74.4% as endpoint reachability and protocol health, not as payment correctness.

why the gap

The gap has a mechanical explanation and it is not flattering to anyone. A payment server with a malformed challenge fails its first agent transaction, which means it fails in public, in front of a paying customer. So this cohort has a hard commercial reason to keep the handshake spec-clean that a free weather API does not have. The pressure comes from money, not from tooling maturity.

That also means the number is fragile. Once agent payment volume grows, the endpoints that pass today are exactly the ones under the most change pressure. Challenge shape drift is the failure mode to watch, and it is cheap to watch if you re-run the check every week.

what to do with this if you run an x402 endpoint

Two things, both small.

If your endpoint is in the registry and passes, there is nothing to fix. There is a public report page for it in the mcpreflight trust directory, and a status badge you can drop into a readme.

If you want to catch the deploy that quietly breaks the challenge, run the same check in CI. One read-only block on every push, no credentials involved:

- uses: xka0085-byte/mcpreflight@v1
  with:
    endpoint: https://your-api.example/paid
    mode: inspect

You can also run it by hand before you ship anything: npx @eidonze/mcpreflight inspect https://your-api.example/paid --method=POST

what this is not

Anonymous handshake only. Servers behind auth are not broken, they just do not answer strangers, and we now classify 401 plus WWW-Authenticate as AUTH_GATED instead of lumping it with dead servers. Two requests per endpoint, one point in time. PASS means we saw a well-formed challenge document, not that anyone paid successfully and not that your pricing is fair.

why this number is worth keeping fresh

Other censuses of the MCP registry exist and they report similar handshake rates. Most of them are one-time snapshots. mcpreflight re-runs the full registry every Monday and keeps the history, so the number has a trend instead of just a value. If you want the raw data or a per-server page, everything is public and open source.

Registry census: https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html

Per-server reports: https://xka0085-byte.github.io/mcpreflight/trust/

Source: https://github.com/xka0085-byte/mcpreflight

If you quote these figures, cite mcpreflight. The whole point of running it weekly is that the number keeps moving, and a moving number needs a named source.

Five read-only diagnostic CLIs for AI agents on Web3 (x402, MCP, Solana)

Eidon Ze — Sun, 27 Sep 2026 04:46:46 +0000

AI agents are starting to pay for things (x402, USDC per call on Solana and Base). That creates two failure modes nobody has good tooling for:

The endpoint answers the wrong thing. An x402 endpoint that returns 400 instead of 402, or a payment document missing payTo, breaks every agent that touches it — usually silently.
Nobody can prove what was delivered. An agent pays, gets a response, and has no independent evidence of what the seller actually delivered.

I kept running into both, so I built a suite of five read-only diagnostic CLIs — and released them all on npm this week. They share one philosophy: CLI-first, no private keys, no auto-payments, JSON output, PASS / FAIL / UNKNOWN, and every tool documents what it does not cover.

Suite index with all commands: https://xka0085-byte.github.io/evidence-tools/

The five tools

1. mcpdoctor — is your MCP/x402 endpoint discoverable?

npx @eidonze/mcpdoctor inspect https://your-endpoint/mcp --json

Parses the HTTP 402 payment document (headers and body, x402 v1 accepts[] and v2 x402.accepts) and checks the /.well-known/mcp/server.json and /.well-known/x402 discovery manifests, with a SHA-256 of the response. It does not speak the MCP protocol — no initialize, no tools/list. One real bug it caught during development: an endpoint advertising a vendor hint header with no accepts[] — which shadowed the real payment document.

2. x402-reconcile — what does an x402 endpoint demand?

npx x402-reconcile inspect https://api.example.com/paid --method=POST --json

Parses the 402 challenge: scheme (exact/base), network (CAIP-2), asset, amount, payTo, timeout — plus response latency and a SHA-256 of the raw response bytes. Verified against a real public endpoint (a notary service returning 402 / exact / USDC / amount 1000). It never signs or pays anything — settlement and delivery stay explicitly NOT_TESTED.

3. oauthdoctor — can an agent even discover your OAuth metadata?

npx oauthdoctor inspect https://mcp.example.com/mcp --json

Walks the MCP authorization discovery flow: unauthenticated request → 401 challenge → WWW-Authenticate resource_metadata → Protected Resource Metadata → Authorization Server Metadata → PKCE S256 declaration. Discovery-only by design: no login, no token exchange, no stored credentials.

4. wallet-evidence — what does one Solana RPC actually see?

npx wallet-evidence inspect <signature> --rpc=https://api.mainnet-beta.solana.com --json

Slot, block time, execution error, parsed instructions, fee — and a SHA-256 of the raw RPC response so the report is re-checkable. The interesting finding while testing: the same transaction signature was visible on one public RPC and not found on another. The tool therefore returns UNKNOWN when an RPC can't see a transaction — it never conflates that with "the transaction does not exist."

5. crosschain-incident — normalize a cross-chain incident export

npx crosschain-incident inspect --input ./message.json --json

Takes operator-supplied source/destination status JSON and produces a conservative evidence report. Missing fields stay UNKNOWN; failures become machine-readable findings. Protocol APIs (LayerZero/Hyperlane) are the roadmap — today it's an offline formatter and says so.

The honest part

Only parts of this stack have real-world validation so far, and the tools label their own coverage. Examples: x402-reconcile has parsed one real public 402 challenge but has never verified a settlement; oauthdoctor passes local positive/negative fixtures but hasn't met a public OAuth-protected MCP endpoint yet. The ReceiptRail MCP service behind the suite has its declared core (initialize, ping, tools/list) passing the official MCP conformance tests — not full-conformance, and it doesn't claim to be.

Every README has a "NOT covered" section. If a claim isn't backed by a test or a real observation, it's not in the report.

Try it

All five are one npx away, MIT licensed, zero runtime dependencies:

npx @eidonze/mcpdoctor inspect https://your-endpoint/mcp --json

The suite grew out of ReceiptRail — on-chain x402 delivery receipts on Solana (SHA-256 digest anchored to a PDA after settlement, verifiable offline with zero trust), live MCP endpoint at https://agenttoll-receipts.app.workbuddy.host/mcp, npm receiptrail-mcp.

Suite index: https://xka0085-byte.github.io/evidence-tools/

If you run an x402 endpoint and want a human inspection of the full payment-to-delivery path (not just the challenge), that's the manual service the suite grew out of: https://xka0085-byte.github.io/evidence-tools/

Your x402 endpoint is probably answering 400 instead of 402 — here's a one-command check

Eidon Ze — Wed, 23 Sep 2026 07:54:24 +0000

ReceiptRail: github.com/xka0085-byte/agenttoll · listed on Smithery and the official MCP Registry · mcpdoctor: npm · GitHub

How to Convert Tailwind HTML to Structured, Semantic CSS (Without a Full Rewrite)

Eidon Ze — Sat, 08 Aug 2026 07:40:19 +0000

How to Convert Tailwind HTML to Structured, Semantic CSS (Without a Full Rewrite)
I've been using Tailwind for about two years across a handful of projects. It's fast, it's predictable, and once the muscle memory kicks in you can style things without switching files.
But here's what I kept running into:
That component you built six months ago? The one with ⁠flex items-center justify-between p-4 bg-white rounded-lg shadow-md⁠ on the outer div, plus another half-dozen classes on each child element? When you come back to refactor it, you're reading styling before you're reading structure. And if you want to move that component into a project that doesn't use Tailwind — or hand it off to someone who doesn't know the utility vocabulary — you're stuck.
The tooling gap
I went looking for something that could take a chunk of Tailwind-styled HTML and give me back clean, semantic CSS. Not one-to-one class translation (there are a dozen tools that do ⁠px-4 → padding: 1rem⁠). I wanted something that understood the component structure — that a button inside a card should become ⁠.card-button⁠, not ⁠.element-4⁠.
What I found:
One-to-one converters — great if you just need to know what ⁠gap-4⁠ compiles to, but they output ⁠.element {}⁠ ⁠.div {}⁠ flat rules with no hierarchy
StyleLens (VSCode) — finds duplicate utility patterns and suggests refactoring into ⁠@apply⁠, but it's an editor workflow, not an export tool
Tailwind's own ⁠@apply⁠ — moves the problem from the HTML to the CSS file but doesn't change the naming problem
None of them did what I actually wanted: paste some HTML, get back component-level CSS with meaningful class names.
What I ended up building
Since I couldn't find it, I put together a minimal tool that does exactly that. The idea is simple:

Parse the HTML tree
Translate every Tailwind class to its CSS equivalent
Group declarations by component (the tree structure tells you what belongs where)
Name things based on what they are — semantic tags like ⁠h2⁠ become ⁠.card-title⁠, buttons become ⁠.card-button⁠, etc. Here's what it looks like in practice. Input: < img class="w-full h-48 object-cover" src="img.jpg" />
Card Title

Description goes here.
Get Started Output: .card { max-width: 24rem; margin-left: auto; margin-right: auto; background-color: #ffffff; border-radius: 0.75rem; box-shadow: 0 10px 15px -3px rgba(0,0,0,0.1); overflow: hidden; }

.card-image {
width: 100%;
height: 12rem;
object-fit: cover;
}

.card-body {
padding: 1.5rem;
}

.card-title {
font-size: 1.25rem;
font-weight: 700;
color: #111827;
}

.card-description {
margin-top: 0.5rem;
color: #4b5563;
}

.card-button {
margin-top: 1rem;
padding-left: 1rem;
padding-right: 1rem;
padding-top: 0.5rem;
padding-bottom: 0.5rem;
background-color: #2563eb;
color: #ffffff;
border-radius: 0.25rem;
}

.card-button:hover {
background-color: #1d4ed8;
}

What happens when 4 competing products all stumble at the same time

Eidon Ze — Sun, 02 Aug 2026 04:47:49 +0000

I've been researching the freelancer client portal space for a side project, and I stumbled into something I didn't expect.

In the last 12 months:

HoneyBook raised prices and got flooded with 1-star reviews for crashing
Fiverr shut down AND.CO entirely — tens of thousands of users had to leave
Dubsado's setup process is so complex people hire $500+ consultants
Bonsai got acquired and went radio silent on product updates

Four products, four different problems, all happening at once.

It got me thinking — if you were going to build a client portal today, what would you actually include? I've been talking to freelancers and the answer keeps coming back to like four features: project status, file sharing, invoices, messages. That's it. No CRM pipelines, no workflow automations, no "enterprise plan."

So I threw up a landing page to see if anyone cares. It's called ClientDash — one link per client, $49 one-time, no subscription.

Link: https://peppy-pegasus-d7ec4a.netlify.app/

I'm not sure if this is a real window or just a coincidence I'm reading too much into. Curious what people here think — is the client portal space actually underserved, or are freelancers just fine with Google Docs + email?

ReceiptRadar — Auto-extract every receipt from your Gmail inbox

Eidon Ze — Sat, 01 Aug 2026 11:38:46 +0000

DEV Community: Eidon Ze

State of the MCP Registry, week of 2026-10-19

How a GET probe makes working x402 endpoints look broken

what we found

why it happens

what we changed

the part that is actually useful to an operator

what this is not

why the method matters more than the number

mcpreflight scanned all 293 x402 payment endpoints in the MCP registry. They pass handshakes at 74.4%, well above the rest.

what we measured

why the gap

what to do with this if you run an x402 endpoint

what this is not

why this number is worth keeping fresh

Five read-only diagnostic CLIs for AI agents on Web3 (x402, MCP, Solana)

The five tools

1. mcpdoctor — is your MCP/x402 endpoint discoverable?

2. x402-reconcile — what does an x402 endpoint demand?

3. oauthdoctor — can an agent even discover your OAuth metadata?

4. wallet-evidence — what does one Solana RPC actually see?

5. crosschain-incident — normalize a cross-chain incident export

The honest part

Try it

Your x402 endpoint is probably answering 400 instead of 402 — here's a one-command check

How to Convert Tailwind HTML to Structured, Semantic CSS (Without a Full Rewrite)

Card Title

What happens when 4 competing products all stumble at the same time

ReceiptRadar — Auto-extract every receipt from your Gmail inbox