MCP Gateway for Developers: The Day-to-Day Workflow
An MCP gateway for developers fixes a boring problem first: the pile of per-client JSON configs, each with its own copy of your servers and its own pasted credentials. You point every client at one endpoint, manage tools in one place, and every machine sees the same catalog. The good gateways add a second thing on top, a memory layer, and that is the part that changes how your mornings feel.
If you want the concept from first principles, we wrote up [what an MCP gateway is](/blog/what-is-an-mcp-gateway). This post is about the day to day.
The four papercuts of a normal MCP setup
Config sprawl. Claude Code reads .mcp.json, Cursor has its own settings, your desktop client keeps a third copy. Adding one server means editing every file, and the files drift. The server you added in Cursor last week silently doesn't exist in Claude Code, and you find out mid-task.
Credentials, pasted again. New laptop, CI runner, a rebuilt dev container: each one wants the same API keys pasted in again, usually into plaintext config files. We've written about why [pasting API keys into agent configs](/blog/stop-pasting-api-keys) is the habit worth breaking. The short version: every copy is another place a key can leak, and rotating one means a scavenger hunt across machines.
The repo, re-read every session. Yesterday your agent worked out that this monorepo uses pnpm, that tests run through a wrapper script, and that the flaky suite is quarantined. This morning it starts blank and derives all of it again, on your token bill, before it writes a line of code.
Tool bloat. Every MCP server you connect injects its full tool catalog into context on every session. Connect GitHub, Sentry, Linear, Postgres, and a browser tool, and you might be looking at 80 tools; at a rough 350 tokens per schema, that is 28,000 tokens loaded before your first prompt. There are ways to [cut MCP token usage](/blog/reduce-mcp-token-usage) without a gateway, but a gateway gives you one place to do the cutting.
What an MCP gateway for developers actually changes
| Task | Without a gateway | With a gateway |
|---|---|---|
| Add a tool | Edit a config file per client | Add it once, every client picks it up |
| New machine | Re-paste every credential | Sign in to the gateway once |
| Switch clients | Different tool sets, different drift | Same catalog behind the same URL |
| Start a session | Agent re-derives project context | Agent recalls what it stored |
In Claude Code specifically, an MCP gateway collapses the whole thing to a single entry: one URL, one sign-in. Cursor, a desktop client, a CI agent, all the same URL. That is the real shift in the developer workflow: the MCP setup moves out of your dotfiles and into one place, and it stops mattering which machine you happen to be sitting at.
A morning with one endpoint
Here is the workflow we are building toward, the one a gateway with memory makes normal.
9:05. You open Claude Code and say "continue the auth refactor." The agent's first move is a recall call to the gateway, which hands back what it stored yesterday: the decision to keep refresh tokens server-side, the ID of the staging database, the open item about the logout edge case. No repo-wide re-read, no "let me first understand the codebase."
9:40. You need Sentry. It is already in the tool list because you connected it through the gateway last month. Nothing to edit, nothing to paste.
13:00. Over lunch you add a new MCP server from the gateway dashboard. Your next session picks it up automatically, in Claude Code and in every other client, because they all point at the same endpoint.
16:30. Before you stop, the agent checkpoints where the refactor stands. Tomorrow's session starts from that checkpoint instead of from zero.
Notice what's missing: no JSON edits, no keys in dotfiles, no ten-minute warmup where the agent re-reads what it already knew.
The memory part is what you feel by Thursday
Federation alone is a convenience. Memory is the part that compounds: a decision your agent stored on Monday is one recall call on Thursday instead of a fresh derivation, and re-deriving things is exactly where long-running agent work bleeds tokens. We went deeper on this in [why a gateway with memory beats a plain one](/blog/mcp-gateway-with-memory).
Where Tulimoa fits, honestly: [our gateway](/gateway) is one endpoint with a built-in memory layer (remember, recall, checkpoint, and friends, free on every plan). It is in early beta and not self-serve yet. What you can do today is add Tulimoa's live directory MCP server to Claude Code with a single claude mcp add command, no account needed for reads, and join the beta to get gateway access as it opens up. We are measuring real token savings from beta usage rather than quoting a made-up percentage, so you will not find one here.
Where to start
Count your MCP configs across clients and machines. If the number is bigger than one, you are doing sync work a gateway would do for you. Then count the tools your agent loads per session; if the catalog dwarfs what a typical task actually calls, your context window is paying rent for tools that never run. Those two counts are the whole business case, and they take five minutes against your own setup.