onemcp

onemcp is a portal for Model Context Protocol servers. Instead of wiring every MCP server into every AI client separately, you group your servers behind a single portal endpoint, and your client connects to that one endpoint to reach all of them. The problem it solves shows up fast for anyone building with MCP today. Each server you add means more connection config to copy between clients, more credentials scattered around, and a pile of tool definitions loaded into the model's context whether it needs them or not. Multiply that by every client you use, a desktop app here, an IDE there, a couple of custom agents, and MCP configuration becomes its own small ops burden. The portal model collapses it, since servers get added once at the portal and every connected client inherits the full set.

The context problem is the one onemcp attacks most directly. A typical MCP setup exposes every tool definition from every server upfront, and with a stack like GitHub, Slack, Postgres, Linear, Notion, Jira, Stripe, and Sentry connected at once, those definitions eat a serious share of the context window before the conversation even starts. Every one of those definitions costs tokens on every single request, whether or not the task at hand touches Stripe or Sentry at all. onemcp replaces that with three meta-tools, search, describe, and execute. The agent searches for tools relevant to the task at hand, requests the detailed specification only for the ones it actually needs, then executes. The site puts the resulting system prompt reduction at roughly 90 percent, which is the difference between an agent that spends its context on your problem and one that spends it reading a tool catalog. It also scales differently. Adding a twentieth server to a conventional setup makes the upfront context cost worse, while adding it to a portal changes almost nothing until an agent actually searches for and uses one of its tools.

Authentication is handled at the portal rather than in each client. onemcp does native upstream OAuth, so credentials stay host-side instead of being pasted into every client config. Auth is also scoped per portal, meaning the same server can carry different credentials in different portals, which is how you keep a personal portal and a work portal from sharing a GitHub identity. Portals can be imported and exported, and there is request logging and debugging so you can see what your agents are actually calling instead of inferring it from behavior. For anyone who has debugged an agent by staring at its output and guessing which tool call went sideways, having the actual request log is a real quality-of-life jump.

There is also a Cloudflare Code Mode integration, which lets agents script their tool calls rather than issuing them one at a time. The site is upfront that the MCP portal pattern was pioneered by Cloudflare, and onemcp positions itself as that pattern made available without an enterprise arrangement. You spin up a portal in minutes at app.onemcp.dev, add your servers, and point your clients at the portal. Code Mode is worth a second look for heavier workflows, since letting an agent write a small script that chains several tool calls is often faster and cheaper than a long back-and-forth of individual invocations.

It fits AI developers and agent builders who have crossed the threshold where MCP stops being one or two servers and starts being a stack. If you run a handful of MCP servers across multiple clients, or you build agents whose tool lists keep growing, the portal model turns an N-times-M configuration problem into a single connection per client. Teams get the additional benefit of one place where server access and credentials are managed rather than living in individual developer configs. The import and export support helps here too, because a working portal definition can be shared or versioned rather than reconstructed by hand every time.

Access is simply free. There is no pricing page, no paid tier, and no trial clock, just the hosted app and a buy-me-a-coffee link if you want to support it. The tradeoff for that posture is the usual one for free developer tools, you are depending on a small project rather than a vendor with an SLA, and the site does not publish who is behind it or whether the code is open source. For what it costs, though, consolidating your MCP sprawl behind one endpoint and reclaiming most of your system prompt is an easy experiment to run. Since clients talk to the portal over standard MCP, backing out is as simple as pointing them at your servers directly again.