Why We Don't Use Ad Platform MCPs

The Model Context Protocol is an open standard Anthropic published in November 2024. It solves a real problem. Before MCP, connecting an AI model to an external service required custom integration code for every tool. MCP standardizes that. A server exposes tools. The AI calls them. The ecosystem wins.

It works. Today there are MCP servers for Slack, GitHub, Linear, Stripe, Notion, Postgres, and hundreds of others. Claude, Cursor, and Windsurf all support the protocol natively. The right use case for MCP is exactly what the ecosystem built it for: connecting AI agents to external services where the protocol boundary makes sense.

Developers are building MCP servers for ad platforms. The instinct makes sense: you want your AI agent to operate Google Ads or TikTok campaigns, MCP is the standard, so build a server.

One real example: @cesteral/tiktok-mcp, version 1.2.0, published under Apache-2.0. It ships 21 tools covering campaigns, ad groups, ads, creatives, audiences, and pixels. It is a direct wrapper around the TikTok Ads API, exposing raw API parameters as tool arguments.

Some articles reference @anthropic/tiktok-ads-mcp. That package does not exist on npm. It returns a 404. The perception that official, production-ready ad platform MCPs exist is ahead of the reality.

What actually exists are generic API wrappers. CRUD access: create, read, update, delete. Raw API surface. That is the complete feature set. In production, it is not enough.

A raw API wrapper and a production ad management system are different things. The difference is not small.

1. Billing Safety and Credit Accounting

Different operations have different costs. A read call to fetch campaign stats is cheap. Launching a full campaign with creative upload, audience build, and ad group configuration is expensive. That difference needs to be modeled explicitly.

In Synter, every script carries a credit cost. Read operations cost 2 credits. Write operations cost 5 credits. A full campaign launch costs 200 credits. These reflect actual API load, compute per operation, and the relative risk of each action. Before execution, Synter checks the balance. If insufficient, the call fails closed.

A generic MCP wrapper has no concept of this. It calls the API. The API responds. Nothing is tracked. At scale, with multiple customers and agents running concurrently, that is no billing system.

2. Credential Isolation Across Customers

Every customer has their own ad platform credentials, connected via OAuth. When an AI agent runs a script for a customer, the correct credentials are injected for that customer. One customer's agent cannot touch another customer's ad account.

A generic MCP server assumes a single credential set, designed for one user connecting their own account. That is right for a developer tool. It is wrong for a platform serving hundreds of customers whose agents run concurrently. You cannot retrofit multi-tenant credential isolation onto a single-tenant tool. The credential model has to be built into every layer from the start.

3. Domain-Specific Logic and Platform Rules

TikTok's Ads API has rules. Not edge cases. Core rules that determine whether an ad can be created at all.

An ad requires an identity type before creation. That identity type must match the creative format. Bid type must be compatible with the campaign objective. Pixel association must be verified before conversion events can be registered. Creative specifications have hard limits on resolution, duration, and aspect ratio that vary by placement.

Synter's TikTok scripts encode these rules before the API call happens. The call either succeeds on the first try or fails with a specific, actionable error, not a raw API error that the AI agent has to interpret and retry. A generic wrapper exposes the parameters. It does not know which combinations are valid. The agent learns through failure. In production, failure means real money and real customer accounts.

Synter encodes 37 distinct TikTok operations covering the full campaign lifecycle. Each reflects what the API actually requires in production, not what the documentation says it requires.

4. Safety Gates and Approval Flows

An AI agent operating ad campaigns has real consequences. A wrong geo target sends budget to the wrong country. A spend cap misconfiguration burns through budget in hours. A creative that violates platform policy gets an account flagged.

Synter runs every write operation through a safety classifier before execution. It screens against geo policy. Certain countries require explicit opt-in before any targeting reaches them. Spend caps are enforced at the script level. Operations requiring customer approval are blocked until that approval is recorded.

The tool registry is fail-closed. Every registered script is in an allowlist. Call an unregistered script and it throws UNKNOWN_TOOL and blocks execution. You do not want AI agents discovering novel ways to call ad platform APIs in production.

A generic MCP gives the agent full API access. No allowlist. No classifier. No approval gate. For a developer connecting their own test account: fine. For a platform operating real campaigns against real budgets for real customers: not acceptable.

5. Asset Management and Cross-Tool Coordination

Ad creative is not text. Images, videos, audio files. These assets need to be uploaded, stored, referenced across tools, and passed to the API at the correct point in the workflow.

Synter has a shared asset store. Assets are stored with signed URLs and artifact IDs. When an agent generates a video creative, it gets back an artifact ID. When it creates an ad, it passes that ID. The script resolves it to the signed URL, validates the asset against the creative spec, and uploads it to the platform. The agent never handles raw file bytes. It handles references.

Creative workflows are multi-step: generate, validate, upload, associate, create. Without a shared asset store, each step returns the full asset to the agent to pass forward. That is not how production systems move binary data. A generic MCP leaves this problem unsolved.

MCPs are the right tool for one specific problem: your agent needs to reach a service it doesn't have direct access to. A Notion workspace. A Slack channel. A Stripe account. The MCP server provides the protocol boundary.

Synter talks directly to TikTok, Meta, Google Ads, LinkedIn, Reddit, X Ads, Microsoft Ads, Pinterest, Snap, and Spotify. Direct API. No middleware. No sync delays.

Adding a third-party TikTok MCP would create a second uncoordinated path to the same API. Path one: Synter's tooling. Credentialed per customer, registered in the allowlist, gated by the safety classifier, tracked for billing, domain-aware. Path two: the MCP. None of those things.

An agent with access to both paths uses one sometimes and the other sometimes. The billing system misses operations. The safety classifier doesn't see calls going through the MCP. That is not a theoretical risk. It is the natural result of two parallel paths to the same resource.

Synter is an MCP server. The @synterai/mcp-server package exposes Synter's tooling to customers' Claude agents. When a customer's agent connects, it calls Synter tools. Synter's tools call the ad platforms. Every call goes through the full stack: credential resolution, safety gate, billing check, domain validation, asset management. None of that is bypassed.

The right layer for the protocol boundary: the agent reaches Synter through MCP. Synter reaches the ad platforms directly.

The MCP ecosystem is not where the hard problems are. The hard problems are domain knowledge, credential isolation, safety enforcement, and asset coordination. Those do not have off-the-shelf solutions.

The pattern that works: your agent connects to your system via MCP. Your system connects to ad platforms via direct API. Your system owns the safety gates, the credential model, the domain logic, and the billing accountability. The agent is the interface. Your platform is the operator.

The pattern that does not work: your agent connects to a generic ad platform MCP. The MCP calls the API. Nothing in between. That architecture moves fast in development and breaks in production.

The protocol boundary matters. Put it in the right place.