Paid search is one of the clearest wins for AI agents. Microsoft Advertising alone is a multi-billion-dollar ad platform, and the work that keeps it performing, pulling reports, drafting ad variants, mining search term data, managing negative keywords, is precisely the kind of structured, repetitive knowledge work that LLMs now handle well.
The problem until recently was the plumbing. You either wired Microsoft’s REST API directly into a custom app, or you duct-taped together Zapier and ChatGPT prompts. Neither scaled.
MCP changes that. With a Microsoft Ads MCP server, you build the integration once, and every MCP-aware agent, Claude Code, Claude Desktop, ChatGPT, Cursor, your custom n8n workflows, gets governed access to the account. This post walks through what that looks like in 2026, what you can reasonably automate, and where the real guardrails need to be.
What an MCP server gives you for Microsoft Ads
The Microsoft Advertising API (officially the Bing Ads API, branded as Microsoft Advertising API v13 at the time of writing) exposes roughly 200+ operations across:
- Customer management (accounts, users, permissions)
- Campaign management (campaigns, ad groups, ads, keywords)
- Bulk operations (uploads, downloads)
- Reporting (~40 report types)
- Ad insight and planning
- Customer billing and invoicing
Without MCP, every one of those operations has to be:
- Wrapped in API-specific code.
- Exposed to each AI tool individually (once per model or app).
- Secured against credential leakage, one integration at a time.
With an MCP server in front, you wrap each operation once as a typed tool. Then:
- Claude, ChatGPT, Gemini, and any other MCP-aware client see the same tools with the same schema.
- OAuth, rate limiting, and audit live in one place.
- Agency setups with multiple clients can use the same server with tenant isolation.
- Changes to the Microsoft API are absorbed once, in the MCP server, not across every agent.
This is the same portable-integration-layer argument that applies to MCP in general, it just lands particularly cleanly in a domain where operations are well-structured and agents add clear value.
The state of Microsoft Ads MCP servers in 2026
Here is the honest landscape as of April 2026.
Official / first-party
There is no official Microsoft Ads MCP server yet. Microsoft has been aggressive on MCP elsewhere (Azure, Microsoft 365 Copilot, GitHub), but has not released one for Microsoft Advertising specifically. Given the direction of travel, I would be surprised if this was still true by end of 2026, but today: no.
Community / open source
Several community servers exist on GitHub in varying states. Quality varies wildly. Before adopting any of them:
- Check when the last commit was (anything older than 3 months is a yellow flag given API changes).
- Read the auth implementation carefully (if it expects a raw API key in the config file, reject it).
- Confirm it handles Microsoft’s OAuth 2.0 flow properly (including refresh tokens).
- Look for rate limit handling (Microsoft Ads has tight daily quotas per app).
Custom
Most production deployments I have seen use a custom MCP server wrapping the Microsoft Advertising API. This is not because the work is exotic, it is because every organisation’s consent / approval / audit pattern is slightly different, and those patterns are exactly what you want encoded in the MCP layer.
What to build into a Microsoft Ads MCP server
Here is the reference toolset we ship for production Microsoft Ads MCP servers. Designed to be useful without being dangerous.
Read tools (safe, no approval gates)
list_accounts, return all accounts the authenticated user can see.list_campaigns(account_id, status?), list campaigns with status filter.get_campaign(campaign_id), full campaign detail including settings and budget.list_ad_groups(campaign_id), ad groups inside a campaign.list_keywords(ad_group_id), keywords with match types and bids.list_ads(ad_group_id), all ads in an ad group.get_performance_report(date_range, granularity, account_ids, campaign_ids?), clicks, impressions, spend, conversions.get_search_terms_report(date_range, campaign_ids), mine for negative keywords.get_keyword_performance(date_range, ad_group_ids), keyword-level KPIs.get_geographic_report(date_range, account_ids), geo performance.
Suggestion / draft tools (safe, produce output for review)
suggest_negative_keywords(date_range, campaign_id, spend_threshold), LLM-assisted analysis that returns a ranked list of recommended negative keywords with reasoning. Does not apply them.suggest_ad_copy_variants(ad_group_id, count, style?), generate ad copy variants. Returns text for a human to approve.suggest_bid_adjustments(ad_group_id, strategy), return recommended bid adjustments with reasoning.suggest_budget_reallocation(account_id), analyse spend vs. performance across campaigns and recommend budget moves.
Write tools (gated behind approval or hard caps)
apply_negative_keywords(campaign_id, keywords[]), rate-limited, hard cap of 50 per call, logged.update_keyword_bids(ad_group_id, bid_map, max_change_pct=20), enforce a max-change-per-keyword percentage in the server itself.pause_ad(ad_id)/enable_ad(ad_id), low-risk write.pause_keyword(keyword_id)/enable_keyword(keyword_id), low-risk write.
Deliberately NOT exposed as tools
These we handle only through human-driven flows, never as agent tools:
- Launching new campaigns or ad groups.
- Moving budget between campaigns at the account level.
- Pausing a campaign above a spend threshold.
- Any customer / billing operation.
- Adding or removing users / permissions.
The rule: anything that can silently lose money or change account security stays out of the tool list, period.
Building the MCP server: the 10-step path
Here is how we build a production Microsoft Ads MCP server for an engagement.
1. Set up a Microsoft Advertising developer app
Register a developer app via the Microsoft Advertising developer portal. Generate a Developer Token. Configure OAuth 2.0 redirect URIs.
2. Pick your server framework
Most production MCP servers we ship are in TypeScript on Node or Python on FastAPI, using the official MCP SDK. Both are fine. Pick whatever your team ships best.
3. Implement the OAuth flow
Microsoft’s OAuth 2.0 flow has some quirks. You want:
- Interactive flow for initial account authorisation.
- Refresh token storage (encrypted, at rest).
- Automatic refresh before expiry.
- A clear error path when refresh fails.
Handle the multi-account case, one authenticated user can manage many accounts, and the MCP tools need to know which one to operate on.
4. Wrap the API endpoints as typed tools
For each tool in the reference list above:
- Define a strict JSON schema for inputs.
- Validate inputs before hitting the Microsoft API.
- Translate Microsoft’s response shapes into LLM-friendly JSON (strip unnecessary fields, rename camelCase where helpful, always return ISO dates).
- Return errors as structured responses, not exceptions.
5. Add rate limiting
Microsoft Advertising has daily quotas per developer token. If an agent blows through them, everyone using that token is blocked. Rate limit aggressively in the MCP server:
- Per-tool rate limits (e.g., reports: 60/hour).
- Per-account quotas.
- Back off gracefully when you approach Microsoft’s quota.
6. Add audit logging
Log every tool invocation with:
- Tool name, inputs, outputs (or output hash for large payloads).
- Client identifier (which agent called it).
- Outcome (success, rate limit, API error).
- Latency.
Ship to a structured log aggregator. This is what you reach for when a customer asks “why did my bid change last Tuesday”.
7. Implement the approval gate pattern for writes
For gated write operations, the MCP tool call should:
- Generate a pending-operation ID.
- Write the pending operation to a durable store.
- Notify a human via Slack / email / dashboard.
- Wait for explicit approval (polling or webhook) before executing.
- Log the approval and the final write.
This is a slightly heavier pattern than a simple tool call but it is what keeps paid-advertising automation from becoming a liability.
8. Add tenant isolation (if multi-client)
For agency setups, the MCP server needs to enforce that a given API client can only see the accounts they are authorised for. Bake tenancy into every tool, do not rely on the agent to respect a “current account” context.
9. Deploy with proper ops discipline
- Containerised deployment, TLS-fronted, on your infrastructure.
- Secrets in a vault, not in env files.
- Monitoring on error rates and latency.
- Health checks.
- A runbook for rotating the Developer Token.
10. Document the tools and failure modes
Write a short doc per tool explaining: what it does, what inputs it expects, what it returns, what the failure modes look like, what its rate limit is, and when to use it vs. another tool. Attach this to the MCP server so agents discover it via list_tools.
What you actually gain, in practice
Here is what a team running a Microsoft Ads MCP server through Claude (via n8n workflows or directly via Claude Code) ships in month one:
- Weekly performance summaries generated automatically across all managed accounts, highlighting the top 3 movers positive and negative, with a plain-English explanation of why.
- Monday-morning negative keyword recommendations based on the previous week’s search-term reports, agent analyses, human approves the list in a single click.
- Ad copy variant generation on demand, agent produces 10 variants aligned to the product page, marketer picks 2–3 to test.
- Budget pacing alerts, early warning when a campaign is tracking to overspend, with a recommended adjustment.
- Anomaly detection, flagging unusual CPC spikes, conversion drops, geo-performance outliers.
None of these replace a paid-search specialist. All of them remove 5–10 hours per week of low-leverage work per account managed. At agency scale (10+ accounts per PM), the ROI is immediate and obvious.
Where this goes in the next 12 months
Three trends worth betting on:
1. Microsoft ships a first-party MCP server
Given how aggressively Microsoft is adopting MCP across GitHub, Azure, and M365, a first-party Microsoft Ads MCP server in 2026 seems more likely than not. When it lands, it will probably be the default for read operations. Custom servers will still have a role for the gated-write patterns and audit workflows your internal audit team signs off on.
2. Agency management tooling collapses into MCP
The market for “AI for paid search” is crowded, dozens of point solutions, each with its own UI and model. Once MCP is the standard tool interface, most of these will either pivot to being MCP servers (exposing their specialised analysis as tools to whichever agent the user prefers) or become thin UIs on top of a Microsoft-first-party MCP server. The specialist layer moves up; the integration layer commoditises.
3. The approval-gate pattern standardises
Today every team implements write-gating differently. Expect a 2026-2027 convergence on a standard pattern (likely: pending-operation ID + approval webhook + audit trail), probably driven by regulated industries where audit is non-negotiable. If you are building now, design for that pattern; retrofitting is painful.
The bottom line
If you manage Microsoft Advertising spend seriously and are not yet experimenting with an MCP server, you are leaving time and performance on the table. Start with a read-only server, point a Claude Code session at it, spend a week asking hard questions about your accounts, and see where the value lands for you. Then decide which writes are worth gating and building.
If you want this done for you, custom MCP server build, integrated with your existing reporting and approval flows, that is exactly the kind of engagement we run as part of MCP server development. Typical build is 3–4 weeks for a single-tenant server, 6–8 weeks for an agency-tenancy setup with approval gates and audit.