X Ads MCP Server to Manage Campaigns from Chat

An MCP server turns an ad platform's API into typed tools an AI assistant can call. Connect one to Claude or ChatGPT and "pause every X line item whose CPC is above $2 in the last 14 days" becomes something the assistant can check, propose, and, once you approve, execute. This page covers PaidSync's X Ads surface in full: the 14 tools, exactly what they do and do not do, how the approval gates work, and how it compares with the X MCP options on most current lists.

It is written for both audiences. Marketers who want to manage X campaigns day-to-day from a chat window, and agent builders who want to know exactly what the protocol surface looks like before wiring it into a workflow. Each section is labeled.

What an X Ads MCP server does (and what PaidSync's does not)

Three things, in practice. It reads, so the assistant can pull spend, CPC, and engagement without you exporting from Ads Manager. It manages, so existing campaigns and line items can be paused, enabled, re-budgeted, and updated through conversation. And it gates, so nothing the AI proposes runs until a human confirms it.

The honest bit up front: PaidSync's X tool set is manage-only. It does not create new campaigns, does not create line items, does not upload creative, and does not manage tailored audiences as tools of its own. For those, you use X Ads Manager. PaidSync's role starts the moment a campaign is live and takes daily management, optimization, and reporting off your plate. This is different from the Google, Meta, LinkedIn, and TikTok surfaces, where PaidSync also builds from scratch; see the capability matrix on the full MCP server page.

All 14 X Ads tools by category

PaidSync's live server exposes 14 X tools (server total 460+ across 14 platforms). The table names all of them; the live catalog is also discoverable from any session via paidsync_context with include_tools:['x'].

Three of these carry most of the operational work. update_x_campaign_budget re-paces spend without opening X Ads Manager, update_x_campaign edits name, status, and campaign-level settings, and update_x_line_item handles line-item settings including bidding and targeting fields exposed by the X Ads API. Combined with get_x_performance and the list_* readers, a Monday-morning pacing and pausing pass runs entirely in chat.

Manage X Ads from a chat window

The practical shape of a week on PaidSync's X stack looks like this. Monday morning you ask "what changed in the last 7 days on X Ads, by campaign, and where is CPC drifting". The assistant pulls it from get_x_performance and answers in plain numbers. You spot two line items pacing over budget on stale creative, ask for a pause on the worst offender and a 30% budget cut on the other, review the drafted changes, and confirm. Later you ask for a status report on live campaigns; the assistant lists them from list_x_campaigns.

Because the same server carries Google Ads (136 tools), Meta Ads (69 tools), LinkedIn (25 tools), TikTok (13 tools), GA4 (28 tools), and GTM (37 tools), the follow-up question "did the X cut shift volume to Meta shopping and did GA4 see the difference" is answered in the same session, not in another tab. That cross-platform session is the practical difference between a X connector and a paid-media server.

Trust is procedural, not promissory. Nothing applies without your confirmation, previews show the exact planned change first, and destructive operations require a second explicit confirmation. Sessions can be revoked at any time.

The protocol surface behind the 14 tools

PaidSync is one MCP endpoint covering 14 platforms; details on the MCP server page. To keep client context small, tools/list returns a lean starter set. The full catalog is discovered at runtime through paidsync_context, which returns the active account, connected platforms, and the grouped tool catalog (include_tools:['x'] returns the exact X tool names), and executed through paidsync_exec. That two-call pattern means an agent can enumerate and invoke all 14 X tools without a 460-tool schema payload sitting in every conversation.

Safety is enforced server-side. Writes are approval-gated, most mutation tools accept dry_run for a no-op preview, and destructive operations require confirm_destructive. For discovery and verification, the domain publishes OAuth authorization-server and protected-resource metadata (RFC 8414 and RFC 9728), an MCP server card, agent-auth.json, security.txt, and a Content-Signal directive.

PaidSync vs X's own MCP server

X shipped a hosted MCP server at api.x.com/mcp on June 30, 2026. It exposes the X API an agent already knows: searching posts, reading content, looking up users, analyzing conversations and trends, all under your own developer credentials. The community servers on current X MCP lists sit in the same place, wrapping the v2 API for posting and reading. None of that is the Ads API. Campaigns, line items, promoted posts, budgets and spend live on a separate product surface, and that is the surface PaidSync connects.

So the two are complements, not rivals. Use X's server when the agent should read the timeline or publish. Use PaidSync when the agent should manage what you are paying for.

What this does not do

Stated plainly, because scoping a tool accurately beats overselling it.

• No new X campaigns or line items. Build them in X Ads Manager, then hand to PaidSync.
• No creative uploads. Promoted posts and video creative are made in X.
• No catalog feed management. Product catalogs are managed in X today.
• One object per task. Updating 10 line items is 10 confirmed tasks.
• No unattended spend. Every write waits for your confirmation.

Roadmap decisions on X coverage track customer demand. If a capability above is central to your workflow, tell us at the demo booking page.

Pricing

Every plan includes all 14 platforms and there is no per-account or per-platform charge. Every tool call counts as one task. Full detail at paidsync.ai/pricing.

Frequently asked questions