The biggest blocker to MCP adoption isn't the protocol — it's the server. Every API you want Claude or Codex to talk to needs a purpose-built MCP wrapper. Write a server, define the tools, handle auth, ship it. The long tail of useful APIs — Jira, PagerDuty, your internal billing system — stays dark because nobody bothered to wrap it.
MCP-Proxy (Show HN today from GitHub user crhuber) closes that gap in one shot. Point it at any REST API, optionally give it an OpenAPI spec, and it generates MCP tools on the fly. No code changes. No new server to maintain. The proxy translates MCP tool calls into REST requests and maps responses back. Zero-code MCP for anything that speaks HTTP.
The architecture is elegantly simple:
flowchart LR
A[Claude / Codex / Agent] -- MCP --> B[mcp-proxy]
B -- REST --> C[Any HTTP API]
C -- JSON --> B
B -- MCP Result --> A
The timing makes this interesting. MCP is winning the protocol war — GitHub Copilot adopted it, OpenAI added it, the MCP spec just reached maturity. What's been missing is the surface area: you need a critical mass of servers before agents can do anything useful. MCP-Proxy solves the chicken-and-egg problem by saying "the entire existing web of REST APIs is your surface area."
Anthropic's implicit thesis with MCP was that every tool should be one MCP server away. MCP-Proxy makes that literally true — no barrier higher than a URL and optionally a spec file. Expect to see this pattern get absorbed into every MCP client within a quarter.