How Agencies Run Every Client Stack Through One MCP Gateway

An MCP gateway for agencies solves a problem in-house teams never meet: the same agent has to work across many client stacks without mixing them up. You connect each client's tools once, run the work through one endpoint, and take the access back the day the engagement ends.

That last part matters more than it sounds. Agencies onboard and offboard constantly, and every offboarding is a security event.

Many clients, many stacks, the same five tasks

Agency work is repetitive across clients and fragmented across tools. The monthly report is the same job whether the client runs HubSpot or Pipedrive. Campaign setup is the same job whichever workspace the ad account lives in. What changes per client is the stack, the credentials, and the context: naming conventions, account IDs, what was agreed on the kickoff call.

Run the numbers on a mid-sized book of business. Ten clients with five connected tools each is 50 credentials. Without a gateway, those 50 keys live in prompt files, env files, and a shared doc somebody made in a hurry. Every new client adds five more. Every departure means finding five keys and hoping you found every copy.

A gateway collapses that. Each client's tools connect once, by OAuth or an API key that goes into a vault, and the agent talks to a single endpoint. The raw keys never ride along in a prompt, and AI agents doing client work stop being a credential distribution mechanism.

What an MCP gateway for agencies actually has to do

Four requirements, in the order they bite:

• A boundary per client. Connections grouped by engagement, tools namespaced so the agent cannot confuse one client's CRM with another's. One endpoint must not mean one undifferentiated pile of tools.
• Revocable access. When an engagement ends, you revoke that client's connections in one place. No key rotation across five services, no archaeology in old config files.
• An audit trail. When a client asks what the agent changed in their CRM last Tuesday, "we think nothing" is not an answer. A per-call log is. We wrote up [why an audit trail is the first thing to demand from any agent setup](/blog/ai-agent-audit-trail).
• Memory that respects the boundary. Client context should survive between sessions, and it should never bleed from one client into another.

The first three solve the security half of agency work. The fourth solves the economics.

The re-learning tax, multiplied by your client count

An agent with no persistent memory starts every client session from zero: which workspace is this, which account IDs matter, what format does this client want the report in, what did we decide last month about attribution. It re-fetches and re-derives all of it, and you pay tokens for every repeat.

An in-house team pays that tax once, for one stack. An agency pays it per client, per session. Twelve clients with one session a week each is roughly 48 cold starts a month before any billable work happens.

That is the quiet cost of agency automation: MCP gives the agent hands, but without memory it has amnesia about every client it serves. A [memory layer](/blog/memory-layer-for-ai-agents) changes the shape of the session. The agent recalls the client's IDs, conventions, and standing decisions instead of re-establishing them, and the work starts at the actual task. We won't put a number on the savings, we're measuring real figures in our beta rather than inventing one, but the mechanic is plain: fewer repeats, fewer tokens billed.

Where Tulimoa fits, and where it doesn't yet

Full disclosure: Tulimoa is our product, an MCP gateway in early beta. Here is the honest fit.

What's built: one endpoint that federates your connected MCP servers behind a single namespaced tools list, an encrypted per-secret credential vault, connections you can revoke at any time, an audit trail for every call, and a memory layer (remember, recall, checkpoint, set_goal) that is free on every plan. We're an EU company, built in Germany, hosted in the EU.

What's not there yet: the gateway is not self-serve today, there is no public sign-up flow, you join the beta through the dashboard. And every plan currently allows one connected agent, with more coming. If your agency wants one agent per account manager tomorrow, we're not that yet, and we'd rather tell you now.

One thing that is live today and free: [the agency partner program](/for-agencies). If you set up MCP tooling for clients, you can submit their tools to the Tulimoa directory on their behalf, and the client claims the listing afterwards. Listing is free, and the partner program costs nothing during the beta.

Where to start

Step 1: Inventory your credentials. Count clients times connected tools. The number is usually higher than anyone in the room guessed.

Step 2: Pick the client with the messiest stack and route only that engagement through a gateway first. The [Gateway page](/gateway) shows how connections, revocation, and memory fit together.

Step 3: Write the offboarding checklist before you need it. If revoking a departing client's access takes more than one screen, the setup failed the test.

If you run solo rather than with a team, the same problem has a different shape: fewer clients, but you are also the entire security department. We covered that in [the consultant version of this post](/blog/mcp-gateway-for-consultants).