DEV Community: Eidon Ze

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