One MCP Endpoint for Claude: Connect All Your Tools at Once
Short answer: instead of adding ten MCP servers to Claude one by one, you add a single gateway endpoint. Claude treats it like any remote MCP server (one URL, one OAuth consent), and behind that connection sit all your tools, namespaced in one catalog that updates itself when your connections change. Ten setups become one, on every machine and surface where you use Claude.
This is a client-specific walkthrough of a pattern we cover in general in [what an MCP gateway is](/blog/what-is-an-mcp-gateway). Honesty first: Tulimoa (our gateway) is in early beta with no public self-serve signup yet, so read the Tulimoa specifics as what beta users do today, and the pattern as what any gateway endpoint gives you.
The two ways Claude connects to tools
The default way: one entry per MCP server. In Claude Code, a claude mcp add per server; in Claude's app settings, a connector per tool. Each entry brings its own auth flow, and each machine or surface repeats the list. Three servers: fine. Ten servers across a laptop, a desktop, and the web app: thirty entries, drifting apart quietly. The papercuts are familiar enough that we wrote them up in [the developer workflow post](/blog/mcp-gateway-for-developers).
The gateway way: one entry, total. A gateway endpoint is itself a remote MCP server from Claude's perspective (that equivalence is the whole trick, explained in [MCP gateway vs MCP server](/blog/mcp-gateway-vs-mcp-server)), so Claude needs no special support. You add one URL, approve one OAuth consent, and the gateway's merged catalog appears: github__create_issue, crm__search_contacts, tulimoa__recall, side by side.
What connecting looks like
In Claude Code: one command with the gateway's URL as a remote HTTP server, for example: claude mcp add --transport http gateway https://gateway.tulimoa.com/mcp. The first session triggers the OAuth sign-in, and after that the full namespaced tool list is available in every project.
In Claude's apps (web and desktop): add the same URL as a custom connector in settings, approve the consent screen, done. Same catalog, same memory, no terminal involved; if settings menus are more your speed than CLIs, the [non-developer walkthrough](/blog/mcp-for-non-developers) covers that path in detail.
Because every surface points at the same endpoint, the annoying question "which machine has which tools" stops existing. You configured the gateway once; Claude, everywhere, sees the result.
What actually improves
One consent instead of ten auth flows. Individual tool sign-ins happen once, at the gateway, where credentials live in an encrypted vault. Claude itself holds a single connection. Rotating or revoking a tool happens centrally and never touches your Claude config.
A tool list that updates itself. Connect a new tool in the gateway dashboard at lunch; your afternoon Claude session simply has it. MCP's list-changed mechanism means the catalog refreshes without you editing anything. Disconnect a tool and it vanishes from every surface at once.
Less catalog bloat, one place to manage it. Ten direct servers dump ten full schema catalogs into every session. A gateway is the single point where what-gets-loaded can be controlled, which is the structural answer to [the context tax](/blog/the-context-tax).
Memory that follows you between sessions. This one is specific to a gateway with a memory layer: the same remember, recall, and checkpoint tools appear in Claude Code and in the Claude apps, backed by one store. The decision you stored from the desktop app on Monday is one recall away in Claude Code on Thursday. That cross-surface continuity is something no per-client memory feature gives you, and it is [the part we think matters most](/blog/mcp-gateway-with-memory).
Try the pattern today, without the beta
Since our gateway is not self-serve yet, here is the honest on-ramp. Tulimoa's public directory server is live for anyone and needs no account for reads: claude mcp add --transport http tulimoa https://mcp.tulimoa.com/mcp gives Claude live search over the [agent-ready tool directory](/discover), which doubles as a two-minute demo of how a remote MCP connection feels in Claude. The [gateway page](/gateway) is where beta access opens up, and everything in this post describes what beta users run today.
One practical tip whichever endpoint you connect: after adding it, ask Claude "what tools do you have now?" Reading the namespaced list once makes the whole mental model click, and it doubles as a check that the connection works.
Frequently asked questions
Does Claude support MCP gateways natively?
Nothing special is needed, which is the point: a gateway presents itself as a standard remote MCP server, and Claude connects to those in Claude Code (claude mcp add) and via custom connectors in the apps. If your Claude can add a remote MCP server, it can use a gateway.
Do I lose tool permissions granularity by using one endpoint?
No. Claude still shows and confirms individual tool calls, and the gateway adds its own layer: per-connection scopes, revocation, and an audit trail of every routed call. You gain a second control point rather than losing one.
Does this work with other MCP clients too?
Yes, and that is half the appeal. The same endpoint works in any MCP-speaking client, so Claude, an IDE, and a custom agent all see the same tools and, with a memory-equipped gateway, the same memory.