Your own MCP server vs a pre-built marketing MCP hub

If you're evaluating how to connect AI to your marketing data, the first fork looks deceptively simple: spin up your own MCP server, or point your AI at a pre-built hub. Both are real options, and both have an honest place. This guide is the build-vs-buy decision for that fork — the companion to the build-vs-buy marketing harness guide.

The short version: build the connector, buy the hub. Running one MCP server for one tool is a reasonable project. Building and maintaining a hub that stays healthy across dozens of marketing tools is a different job entirely — and it's the job most marketing teams don't actually want to hire for.

What an MCP server actually has to do

The Model Context Protocol itself is simple: a server exposes tools, an AI client calls them. The work is everything around that. Before you decide to build, it's worth listing what a real, production-grade connector has to carry. Most of this is invisible until it isn't:

• Auth. Every marketing platform has its own OAuth flow, scopes, consent screens and token format. Google access tokens live for about an hour and need refreshing. Meta and LinkedIn tokens last longer but still expire. Each one is its own integration to design, test and maintain.
• Approvals and consent. A hub that can both read and write your accounts has to decide who approves a write, how consent is granted, and what can never happen without a human. That's a policy layer, not a code one.
• Drift. Marketing APIs change. Meta retires API versions every six months or so. Google deprecates endpoints. If nobody is tracking that, a connector silently stops working — often weeks after the change.
• Measurement. The point of connecting your data is to know whether the change worked. That requires the connector to feed a consistent, comparable stream into whatever measures it — a ledger, a report, a verdict.

None of this is in the MCP spec. All of it is in the job.

When building your own server is the right call

Doing it yourself is genuinely the right answer in a few specific cases:

• One tool, one connector. If you need AI to reach a single platform and your team already has the engineering capacity, a single well-scoped MCP server is a tractable project. This is the case where "build the connector" is just true.
• Proprietary or unsupported platforms. If your stack includes a niche platform, an internal system, or a channel no managed hub supports, building is your only option.
• Custom transformation. If you need to join, enrich or filter your marketing data with internal systems before it reaches the AI, a self-hosted server gives you full control over that pipeline.
• Strict data residency or compliance. If your data can't leave a specific region or cloud environment, a self-hosted deployment may be the only compliant answer.

Build one of those and you're done. Build five, and each one is now a system you own: auth to refresh, versioning to track, uptime to watch.

When the multiplication problem kicks in

The honest name for this is the multiplication problem. One tool is fine. Three tools means three OAuth flows, three version trackers, three things that can break on an API sunset. The curve is not linear, because each new connector doesn't just add a server — it adds the full job of keeping that server alive and honest.

This is where a pre-built marketing MCP hub earns its keep. Cogny's catalog is ~70 marketing integrations — Search Console, Google Ads, Meta Ads, GA4, LinkedIn Ads, TikTok Ads, Shopify, HubSpot, and more. Each one connects through OAuth, refreshes its own tokens, tracks its own API versions, and sits behind the same approvals and measurement layer. That is the hub: one thing that does the maintenance job across all of them, so you don't have to.

Read more about what that hub looks like in the build-vs-buy marketing harness guide.

Three things a hub gets right that a solo server usually doesn't

If you're weighing build vs buy, these are the three places the difference shows up in practice.

1. Auth that stays alive

A hub's real work is token lifecycle. OAuth access tokens expire — Google's in about an hour, Meta's and LinkedIn's in weeks to months. A connector that doesn't refresh them silently fails your AI, and the failure is quiet because the AI just gets an error where it expected data. A maintained hub refreshes every token automatically. You connect once and it keeps working.

2. A consent and approval policy, not just a permission

Connecting AI to your accounts means deciding what can be written, by whom, and only after what. A hub that spans your whole stack puts that policy in one place: read-only by default, writes gated by explicit approval. You can see how this works in the authorize flow. A solo server, by contrast, tends to start as a blank permission set you have to reason through yourself — and every extra server multiplies the surface you have to police.

3. Drift you don't have to chase

Every marketing API changes on its own schedule. A hub tracks the ~70 integrations in its catalog and ships updates when a vendor sundowns a version. You might see one broken connector after a Meta or Google change, but you won't see seven. That's the maintenance job folded in, rather than on you.

Where measurement fits

None of this matters much if you can't tell whether what your AI did actually worked. That's the piece that turns a connector into a growth loop. When the tool is a hub tied to a measurement layer, every change you make through it flows into the same ledger and comes back with a verdict — including the "didn't work" and "inconclusive" ones. A single-tool server you build yourself usually stops at "can query the data"; the measurement is another system you'd have to build and wire in.

The honest summary

• Build your own when you need one connector for one tool, you're on an unsupported platform, you need custom data transformation, or you face strict data-residency requirements.
• Buy the hub when your stack spans multiple marketing tools and you'd rather not run the auth, consent, drift and measurement job across all of them.
• Use both. Nothing stops you from pointing your AI at a pre-built hub for the tools it covers and your own server for everything else. MCP is an open standard; clients handle multiple servers happily.

Cogny is the pre-built hub in this story: ~70 integrations behind one MCP endpoint, OAuth handled per platform, read-only by default, and every change measured with a verdict. If that's the job you'd rather not build yourself, start free.