What changed
FACT (per source): a GitHub audit tool (mcp-spec-check) reports only 1 of 4,356 reachable MCP servers is ready for a 2026-07-28 MCP spec cutover. FACT (per source): Cloudflare launched a Monetization Gateway that lets a builder put arbitrary resources — including MCP tools — behind a metered, agent-payable x402 gateway.
Why now
HYPOTHESIS: a hard-dated spec break plus a newly available machine-to-machine paywall means a solo dev could, for a ~3-week window around the deadline, run a translating proxy and charge agent operators for toolchain continuity. The timing is the entire thesis — and it is also the entire risk.
Converging signals
Two CAPABILITY signals meeting (dev audit tool + platform payment rail). Note: this is capability×capability, NOT pain×capability or a mandate. There is no complaint thread, no job posting, and no forced-buyer here — the 'deadline' is a voluntary open-source spec, not a regulation.
Customer pain
HYPOTHESIS only. The claim that agents 'break' on the cutover is unverified and is the load-bearing assumption. Spec changes in maturing protocols are frequently backward-compatible, negotiated via version handshake, or absorbed by SDK updates on the client side — in which case there is zero pain and zero product.
Who pays
Claimed: AI-agent platforms/companies operating agents against many third-party MCP servers. In reality these are exactly the sophisticated buyers most able to pin a server version, self-host a shim, or wait for the SDK — they are unlikely to route production traffic through an unknown solo dev's proxy and pay per request.
Solved today
If a break actually occurs: the client SDK updates, the agent pins the old protocol version, the server owner updates (the audit tool exists precisely to nudge this), or the agent drops the dead tool. All are cheaper and lower-risk than trusting a third-party MITM proxy.
Why current solutions are bad
Weakly: coordinating hundreds of server owners is slow. But that argues for the audit/dashboard product, not for a paid inline proxy that inserts a solo dev into the critical path of an agent's tool calls.
Proposed product
A bidirectional translating proxy (new-spec inbound / legacy-spec outbound) on Cloudflare Workers, x402-metered per request, seeded with a public directory of still-non-compliant popular servers to manufacture urgency.
MVP version
Diff the 2026-07-28 spec vs current; if — and only if — the diff contains genuinely breaking, non-backward-compatible changes to high-traffic message types, build a translator for those types and put it behind the x402 gateway.
30-day build
KILL-TEST FIRST: read the actual spec diff before writing any code. If backward-compatible or client-auto-handled, stop — the idea is dead. If (and only if) a real break exists, prototype the translation for the top 2-3 message types.
60-day build
Publish the free non-compliance directory as a lead magnet; instrument which servers actually break real agents; try to get a single agent operator to route non-critical traffic through the proxy.
90-day revenue plan
Attempt per-request billing from any operator willing to pay for continuity in the deadline window. Realistically revenue evaporates the moment SDKs/servers update — this is a days-to-weeks window, not a durable business.
Distribution path
HN/Show HN off the audit-tool community, the free directory, MCP developer Discords. No enterprise procurement path, but also no proven demand channel.
Pricing hypothesis
Per-request micro-fee via x402 stablecoin settlement. Fatal problem: to justify per-request pricing you must sit in the hot path of every tool call, which sophisticated operators will refuse for latency, security, and reliability reasons.
Technical difficulty
Moderate-to-high: a correct, low-latency, secure bidirectional protocol translator that must not corrupt tool calls or leak credentials, maintained against a moving spec.
Legal / regulatory risk
Low legally, but MITM'ing another party's tool traffic and credentials raises trust and security-liability concerns that make buyers wary.
Platform dependency
HIGH and unusual: total dependence on both the MCP spec's exact break AND Cloudflare's x402 gateway. If the spec is compatible OR clients update, the product has no reason to exist.
Founder fit
POOR. This is outside every founder strength (industrial ops, public records, government-portal filing, recycling). It is not a public-money or forced-filer play despite the 'deadline' framing — a voluntary protocol spec is not a regulation and there is no compelled buyer. No demand evidence supports it.
Breakout potential
Low and time-decaying. Even in the best case it is a bridge that becomes obsolete the week servers/SDKs catch up. The only durable asset is the free compliance directory — which is a content/lead product, not this proxy.
Final recommendation
PASS / near-kill. Do not build the proxy. At most, run the free kill-test (read the spec diff) and, if any real break exists, ship only the free non-compliance DIRECTORY as a low-effort lead/content asset — never the inline paid proxy. Redirect effort to the founder's proven public-money / forced-filer shape where demand is structural.
Next action
Spend 30 minutes reading the actual 2026-07-28 MCP spec diff against current. If the breaking changes are backward-compatible or client-auto-handled (the likely case), formally kill this. Do not write proxy code before that check passes.