The default way to connect AI agents to a marketing stack is to find or write an MCP server for each platform, wire each one into each person's agent, and paste in an API key. It takes about ten minutes for the first platform, which is exactly why it is the default. It also breaks in four predictable ways once more than one person is doing it, and the fourth one is fatal: most platforms have no MCP server at all and the long tail never will. We built the opposite thing. One gateway in front of everything, one OAuth grant per client, and platform credentials that never leave the server side. This is the architecture, where the credentials actually live, and the trade we accepted by centralizing.
I wrote the shorter, more personal version of this argument in One Gateway, Not Fifty Servers. This is the engineering account.
Key Takeaways
- One MCP server per platform breaks four ways at organizational scale: credential sprawl, context bloat, no shared governance, and coverage gaps for platforms nobody built a server for.
- A partial workflow rounds down to zero. An agent that reads your ad data but cannot act on it does not deliver most of the value, it delivers close to none, because a human is still in every loop.
- The gateway exposes one OAuth-protected endpoint with a compact general tool surface, resolving platform-specific capability at request time instead of preloading hundreds of tool schemas.
- The core mechanism is credential brokering: the agent sends a request naming a platform and operation but carrying no platform credentials. The gateway injects stored credentials server-side and never returns them to the client.
- The workspace is the unit of isolation. Connections, credentials, storage, knowledge, and audit all scope to it, and nothing crosses that boundary implicitly.
- Centralizing concentrates risk, and that is a real trade. One hardened, audited boundary against fifty ad hoc ones that each hope for the best.
The Default Path Breaks in Four Predictable Ways
A marketing organization's context lives in ad platforms, CRM, web analytics, ecommerce backends, spreadsheets, warehouses, and internal SaaS. Wiring an agent to each one separately fails in four specific ways, and they compound rather than add.
Credential sprawl. Every agent process ends up holding long-lived tokens for every platform, usually in a local config file on a laptop. Every employee re-authorizes every platform separately. Offboarding and rotation become guesswork, because nobody has a list of which tokens exist and where.
Context bloat. Fifty MCP servers with a dozen tools each means hundreds of tool schemas injected into every model call. Models get slower, more expensive, and measurably worse at picking the right tool. You pay for the whole catalog on every request whether or not you use it.
No shared governance. Permissions, audit, and data isolation get reimplemented per server, or skipped. Your security team is asked to review N integrations built N different ways, by N different authors, with N different ideas about where a secret should live.
Coverage gaps. Most platforms still have no MCP server, and the long tail never will. This is the one that does not get better with effort, because it is not your effort that is missing.
These are all organizational problems, which is why they are invisible in a single-user demo. Connecting one agent to one platform directly is genuinely simpler than standing up a gateway, and anyone who objects that a direct connection is easier is correct at that scale. The gateway answers a different question: what happens when it is forty people, five hundred platforms, and someone has to answer for who did what.
A Partial Workflow Rounds Down to Zero
Underneath those four sits a fifth problem that gets discussed less, and it is the one that decides whether any of this is worth building.
An agent that can read your ad data but cannot act on it, cannot schedule the follow-up, and does not know your business rules is not delivering eighty percent of the value. It is delivering close to none, because a human still has to be in every loop. The last mile is not a nice-to-have on top of retrieval, it is the part that removes the human from the critical path, and without it you have built a very expensive way to generate a suggestion.
That is why the gateway had to cover data, actions, standing automations, and business context together rather than shipping the easy plane first. Fragments do not compose into a workflow on their own.
One Gateway, Four Planes
Improvado exposes a single MCP endpoint. Any MCP-compatible client, whether Claude, Cursor, a custom agent framework, or our own built-in agent, authenticates to it over OAuth: one grant per client, revocable centrally, instead of one credential per platform per person.
The surface stays small deliberately. Rather than preloading fifty servers' worth of schemas, the gateway exposes a compact set of general tools, query the warehouse, invoke a platform operation, run an automation, retrieve knowledge, and resolves platform-specific capability at request time. Everything arrives through that one surface, organized into four planes.
The data plane is the classic pipeline: connect a source, choose report types, extraction runs on schedule into warehouse storage. What matters for agents is what that storage is. Not raw API JSON, but normalized cross-channel tables governed by naming conventions and data-governance rules you control. An agent asking for blended CPA across Meta, Google, and TikTok last quarter runs one SQL query rather than thirty paginated API crawls, and it runs over any volume, because the query executes in the warehouse instead of the model's context window. The warehouse is pluggable: teams already running Snowflake, BigQuery, or MS SQL Server do not re-platform to get agent access, and managed ClickHouse is the default we operate rather than a requirement we impose.
The action plane turns the same connections into direct API execution, and it is where the interesting engineering is. It gets its own section below.
The automation plane covers standing behavior rather than one-shot answers: reverse ETL, monitors, trigger-then-action rules, and propose-then-approve flows where the agent drafts and a human commits.
The knowledge plane has two layers. A pre-built marketing knowledge base that is useful on day one, and your own workspace graph, which accumulates from sessions over time. The second layer is the one that compounds, and it is the reason two organizations running the same models do not get the same results after a year.
There is also an integration factory behind all of this: when a platform has an API but no connector, the agent can build one. That is what keeps the coverage gap from being permanent.
Where the Credentials Live
If you take one mechanism from this article, take this one. It is the difference between the two architectures, and everything else follows from it.
The agent, already authenticated to the gateway, sends a request that names a platform and an operation and carries no platform credentials at all. The gateway authenticates the session, scopes it to the workspace, and writes the audit line. The connection store resolves that workspace's connection for the target platform and injects the stored credentials server-side. The platform API executes the operation, with pagination and platform quirks absorbed by the proxy. The result returns to the agent. The credentials do not.
The trace is identical regardless of platform: the identity travels, the credentials stay put. Stored credentials are never returned to the client, never enter a model context, and never land in a laptop config file.
That single mechanism closes several cases at once. Platforms with no MCP server become agent-accessible the moment a connector exists, and nobody has to write or host a server for them. Platforms that do have an MCP server are still simpler through the gateway, because one shared connection for a whole workspace beats every employee separately wiring and trusting another vendor's server with another vendor's token handling. And the security review collapses from N community servers of unknown provenance to one vendor, one endpoint, one audit trail.
This is also the honest answer to the question worth asking of any agent architecture, including ours: 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 part of the iceberg below the waterline. We think about this the same way we think about AI agent security generally, where the controls that hold are the ones enforced outside the model.
Tenancy: What a Workspace Contains
A workspace is our unit of isolation. Connections, credentials, storage, knowledge, and audit all scope to it, and nothing crosses that boundary implicitly.
Sharing inside a workspace is deliberate. A connection can stay private to whoever created it, be shared with specific teammates, or be made visible to the whole workspace. Handing a connection to another workspace is possible, but only as an explicit act by someone who owns it. Nothing crosses a workspace boundary silently, in either direction.
The practical effect is the thing administrators actually care about: joiners get capability on day one without a setup ritual, and leavers lose it centrally rather than through a hunt for which laptops hold which tokens.
Identity also follows the work. Interactive sessions act under the user's own identity and permissions. Scheduled automations run as their creator, pinned to that creator's workspace and quota-limited. Either way, every call lands in the same audit log.
The Trade We Accepted
Centralizing access concentrates risk. That is a real objection and it deserves a real answer rather than a deflection.
One gateway is one point of compromise. Fifty scattered servers are fifty points of compromise, but they fail differently: each one is smaller, and the blast radius of any single failure is narrower. Anyone who raises this is pointing at something true.
We took the trade deliberately, on the view that one hardened, audited, continuously reviewed boundary is safer in practice than fifty ad hoc ones that each hope for the best, most of which were never reviewed by anyone and several of which are running code from an author nobody at your company has evaluated. The concentrated risk is visible, which means it can be defended, monitored, and audited. Distributed risk of this kind is mostly invisible, which is a different property from being small.
That view obligates us rather than reassuring you. It is why the boundary, identity, tenancy, brokering, and audit, is where the durable engineering goes, and why tool count is table stakes rather than the product. The gateway is a policy product, not a tool catalog.
What Is Not Built Yet
A note on where the line currently sits, because architecture posts have a habit of describing the roadmap in the present tense.
Access control on shared connections today is deterministic role-based control enforced in code, plus the workspace boundary and the sharing model described above. What is not shipped yet, and is on the roadmap rather than in production, is the richer policy layer: plain-language rules attached to a shared connection and evaluated at the gateway, of the form "may list objects but not read individual records" or "may create campaigns but never change budgets," with deny-by-default semantics giving granularity the underlying platforms never offered. Most SaaS platforms have coarse permission models, often just admin or viewer, decided years before anyone imagined an autonomous client, and closing that gap one hop before the platform is where this is heading.
Also on the roadmap: pre-declared least-privilege scopes for automations, and publishing more of the evaluation harness we use to test the gateway against real consumer agents rather than only our own tooling.
If you are evaluating agent infrastructure, this is worth asking of every vendor, including us: which parts of the architecture diagram are running in production today, and which are next quarter. The answer tells you more than the diagram does.
Talk to an Improvado expert about what runs in production today and what is on the roadmap.
If you are earlier in the decision and still comparing individual servers, we ranked the best MCP servers for marketing data by measured search demand, and what an MCP server is and how it works covers the fundamentals. The argument for owning this layer at all is the same one behind marketing data integrations being the real AI moat.
Frequently Asked Questions
Why use one MCP gateway instead of one MCP server per platform?
Because the per-platform path breaks four ways once more than one person uses it. Credentials sprawl into laptop config files with no rotation story, hundreds of tool schemas bloat every model call, governance gets reimplemented or skipped per server, and most platforms have no MCP server at all. A single gateway gives one OAuth grant per client, a compact tool surface with capability resolved at request time, one audit trail, and coverage that does not depend on someone else having written a server.
Do platform credentials ever reach the agent?
No. The agent holds one revocable gateway session and nothing else. When it requests an operation, it 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, resolves the stored connection, and injects the credentials server-side. Results return to the agent; stored credentials never do, so they never enter a model context or a local config file.
What is MCP context bloat and why does it matter?
Every connected MCP server injects its tool schemas into the model's context on each call. Stack fifty servers with a dozen tools each and you are sending hundreds of schemas on every request, which makes calls slower, more expensive, and less accurate because the model has more near-identical options to choose between. A gateway avoids this by exposing a small set of general tools and resolving the platform-specific detail at request time rather than preloading the whole catalog.
Do we have to move to your warehouse?
No. Managed ClickHouse is the default we operate, not a requirement. Teams already running Snowflake, BigQuery, or MS SQL Server keep their warehouse, and the agent's SQL executes where the data already lives. The reason queries run in a warehouse at all is that it is the only way to ask questions over large volumes without pulling the data through the model's context window.
How is data isolated between teams and customers?
The workspace is the unit of isolation. Connections, credentials, storage, knowledge, and audit all scope to a workspace, and nothing crosses that boundary implicitly. Within a workspace, a connection can stay private to its creator, be shared with specific teammates, or be visible workspace-wide. Sharing a connection with a different workspace is possible only as an explicit act by an owner. Interactive sessions run under the user's identity; scheduled automations run as their creator, workspace-pinned and quota-limited.
Is a single gateway not a single point of compromise?
Yes, and it is a fair objection. The counter-argument is not that the risk disappears but that it changes shape: one hardened, audited, continuously reviewed boundary against fifty ad hoc integrations that were mostly never reviewed and often run third-party code nobody at your company evaluated. Concentrated risk is visible, so it can be monitored and defended. Distributed risk of that kind is mostly invisible, which is not the same thing as being smaller. It is a deliberate trade, not a free win.
What about platforms that have no MCP server?
They stop being your problem. If a connector exists, the platform is reachable through the action plane immediately, with no server to write or host. If no connector exists but the platform has an API, the agent can build the integration. This is the failure mode with no effort-based fix in the per-server model, since it depends on someone else having decided to build and maintain a server for a platform you happen to use.
