Appearance

What is bundlemcp? ​

bundlemcp is a self-hostable MCP bundling gateway. It sits between the MCP clients your users run (claude.ai, ChatGPT, Claude Code, your own agents) and the MCP servers you operate, and does one thing well: it bundles MCP servers and exposes the bundles the way each consuming client needs them.

Upstream MCP servers

Streamable HTTP, probed and cached

weather
forecastcurrent
notes
searchcreate
crm
lookupupdate

One bundle

Prefixed, curated, renamed

assistant
  • weather__forecast
  • weather__current
  • notes__search
  • add_notewas notes__create
  • crm__lookup
  • crm__updatedisabled

Endpoints per client

Same tools, three contracts

/assistant/mcp
claude.ai · OAuth 2.1
profile: oauth_only
/assistant-gpt/mcp
ChatGPT · OAuth 2.1
profile: write_as_read, tools re-annotated read-only
/assistant-ci/mcp
scripts & agents · API key
profile: default, 120 calls/min per key
  • An upstream server (or upstream for short) is an MCP server reachable over Streamable HTTP. The gateway probes it, discovers its tools, and keeps that tool list cached.
  • A bundle composes any number of servers into one virtual MCP server. Tools are prefixed with the server name so they never collide, and you can hide or rename tools per bundle.
  • An endpoint is a public URL that serves one bundle. A bundle can have many endpoints, each with its own authentication modes, client profile and rate limits.

Where it sits ​

The gateway is one system with five neighbours: the people who operate it, the MCP clients that call it, the servers it aggregates, the identity provider that authenticates humans, and, optionally, an application layer that bills for calls and registers servers through the API.

Loading diagram…

Drag to pan. Click an element to open the fullscreen browser, where you can zoom and navigate between views.

Who it is for ​

  • Teams that run several MCP servers and want to hand their users a single connector instead of five.
  • Operators who need OAuth for claude.ai without building an authorization server. bundlemcp ships one, and federates human login to whatever OIDC provider you already have.
  • Platform builders who need a bundling core with a real management API, a metering hook for billing, and identity propagation to upstream servers.

What it is not ​

  • Not an MCP server marketplace, not an identity provider, not a billing system. Those belong to an application layer built on top.
  • Not a transport bridge. Upstreams must speak Streamable HTTP. stdio servers run behind a small sidecar, see stdio servers behind a sidecar.
  • Not multi-tenant. A deployment is one shared workspace where every admin sees and manages everything.

Why a gateway at all ​

Connecting a client directly to each MCP server works until you have more than a couple of servers, more than one kind of client, or more than one user. Then you need a place to:

  • decide which tools each client sees, and under which names;
  • give claude.ai the OAuth discovery surface it requires, while a cron job uses an API key against the same tools;
  • work around client quirks, such as your client refusing write tools, without changing the servers;
  • know who called what, from an audit log and a metering hook that your own billing can build on;
  • pass the caller's identity to upstream servers that keep per-user state.

bundlemcp centralises all of that, and keeps its own state out of process memory so that restarts and additional replicas never break a session.

For a detailed breakdown of how bundlemcp differs from tool frameworks, see bundlemcp vs. FastMCP.

Where to go next ​

  • Quickstart brings up the full stack with Docker Compose in a few minutes.
  • Core concepts explains servers, bundles, endpoints and profiles in more depth.
  • Authentication explains how people, MCP clients and scripts sign in, what administrators and users can do, and which identity a call carries at each step.
  • Production deployment covers public URLs, reverse proxies, upgrades and backups.

bundlemcp