One Gateway, Not Fifty Servers
The default way to wire AI agents into a marketing stack is one MCP server per platform. The real design question is where the credentials live and who writes the audit line.
Recently we demoed our unified MCP setup to the head of analytics at a consumer brand. The demo ran clean. The benefits did not land.
The objection was fair, and it is one every strong data leader should raise: a competent analyst can connect an AI agent to any single ad platform directly. Find the MCP server, paste an API key, ten minutes of work. True. For one expert, one platform, one task, the direct path is the right call. Nothing about a gateway beats it, and I will not pretend otherwise.
We were answering a different question than the one we were asked. The analyst was evaluating from the seat of a single power user, where the direct connection wins. The gateway is built for a different seat: the organization around that user. Every agent, every platform, every teammate, offboarding, audit, a year of key rotation nobody remembers to do. Same platform, two different problems. Neither view is wrong; they are answers to different questions.
The gap in that demo was ours: we showed tools, when the product is a boundary. This essay is the explanation we owed the room.
What “connect it yourself” becomes at company scale
Take the motion that wins for one expert and run it across a marketing organization. Ad platforms, CRM, web analytics, e-commerce backend, spreadsheets, the warehouse, internal SaaS. Every platform gets its own MCP server. Every employee authorizes every platform separately. Every agent process holds every token, usually in a local config file.
This breaks in four predictable ways.
Credential sprawl. Three agents times five platforms is fifteen long-lived tokens sitting in laptop configs. Nobody rotates them. Offboarding becomes archaeology: which machines still hold keys, for which platforms, under whose identity?
Context bloat. Fifty MCP servers times a dozen tools each is hundreds of tool schemas injected into every model call. The model pays for all of them on every request, and it picks tools worse. More servers make the agent slower, costlier, and less accurate at the same time.
No shared governance. Permissions, audit, and data isolation get re-implemented per server. Or skipped per server. Your security team is asked to review N integrations built N different ways by N different authors.
Coverage gaps. Most platforms still have no MCP server at all. The long tail never will. Whatever you standardize on, half your stack is not invited.
Each of these is annoying alone. Together they have a compounding property: the more useful you try to make your agents, the worse all four get.
A partial workflow rounds down to zero
There is a fifth problem underneath the four, and it is the one that actually kills the value.
An agent that can read your ad data but cannot act on it, schedule the follow-up, or apply your business rules does not deliver 80 percent of the value. It delivers roughly none. The mechanism is simple: if a human still has to sit in every loop, you have not removed the loop. You have added a very articulate reporting layer on top of it.
Completeness is binary at the level that matters. Either the workflow runs end to end under governance you trust, or a person is still the runtime. That is why stitching together whichever MCP servers happen to exist produces demos, not systems. The gaps are not 20 percent of the value. They are the value.
The membrane
A cell does not solve transport by letting every molecule negotiate with every organelle. It has a membrane. Selective channels, one boundary, and one chemistry that decides what gets in, what gets out, and what gets logged.
So we built the opposite of the default path: one MCP gateway in front of the whole platform, and every agent, ours and yours, goes through it.
The shape is easy to state. One endpoint, protected by OAuth: one grant per client, whether that client is Claude, Cursor, a custom framework, or our own built-in agent. Revocable centrally. The tool surface stays deliberately small: a compact set of general tools, with platform-specific capability resolved at request time instead of fifty servers’ worth of schemas preloaded into every call.
Behind that one surface sit four planes:
Data. Connectors extract on schedule into normalized, cross-channel, analytics-ready tables. Managed ClickHouse by default, or the Snowflake, BigQuery, or MS SQL you already run. An agent asking for blended CPA across Meta, Google, and TikTok runs one SQL query where the data lives, not thirty paginated API crawls through its own context window.
Actions. The same connections power direct API execution. The agent sends a request that names the platform and the operation but carries no platform credentials. The gateway authenticates the session, scopes it to the workspace, writes the audit line, injects the stored credentials server-side, and returns the result. Data comes back to the agent. Credentials never do.
Automations. Interactive Q&A is the demo; standing behavior is the value. Agents author monitors, scheduled reports, and trigger-to-action rules through the same gateway. Each automation runs as the identity that created it, pinned to its workspace, quota-limited, audit-logged, and it can be set to propose instead of act: the run ends in a plan a human approves before anything executes.
Knowledge. Two layers. A pre-built marketing knowledge base ships with the platform, so agents are competent in the domain on day one. On top of it, each workspace grows its own private graph: your definitions, your rules, your decisions, consolidated from real sessions over time. Every connected agent reads both through the same gateway.
And for the long tail: point the agent at any platform with a public API and documentation, and it builds the integration itself. Authentication, endpoints, report types, delivered as a first-class connection with the same brokering and the same audit. MCP coverage of the platform stops being your problem.
The unit of isolation for all of it is the workspace. Connections, storage, knowledge, and audit all scope to it. Nothing crosses that boundary silently; sharing a connection to another workspace is an explicit act by its owner, never a side effect.
The honest trade
Centralizing access concentrates risk. I would rather say that plainly than have a security reviewer say it for me.
One gateway is a single point of compromise, and we treat it that way: hardened, audited, deliberately boring. The alternative is not zero risk. The alternative is fifty ad hoc boundaries, each holding live credentials, each reviewed by nobody, each hoping for the best. I will take one membrane under continuous scrutiny over fifty hopeful holes in the hull.
The question I ask now
Since that demo, I changed the question I open with. Not “what tools does your agent have.” Two different questions: where do the platform credentials live, and who wrote the audit line when the agent acted?
If the answer involves a laptop and a shrug, that is the iceberg. Tool catalogs are the part above the waterline. Identity, tenancy, brokering, and audit are the mass below it, and that is where agent infrastructure actually sinks or floats.