Microsoft ads API MCP server: what it does and what it doesn't

Microsoft shipped an official Advertising MCP server in 2026, and most performance marketers still don't know what it can and can't see. If you run paid search on Bing or the Microsoft Audience Network and you're wiring AI agents into your ad stack, the gap between what Microsoft ships and what you actually need matters.

What the official Microsoft Advertising MCP server is

Microsoft's Advertising MCP Server entered open pilot in June 2026 and got full setup documentation on July 22, 2026. It connects Copilot Studio, GitHub Copilot in VS Code, ChatGPT, and Claude to your Microsoft Advertising account data using Azure Active Directory (AAD) OAuth. The server endpoint is a single URL with a toolset parameter, and the entire authentication flow runs through an AAD application registration rather than a simple API key.

This matters for anyone comparing it to how other ad platforms have approached MCP. Meta, TikTok, and Snap have all shipped or piloted MCP-style integrations at different speeds, and each one picked a different auth model. Microsoft picked the heaviest one: full AAD app registration, client secret rotation, and OAuth scopes scoped specifically to msads.manage.

What it can actually do

Per Microsoft's own use-case documentation, the supported scenarios are narrow and reporting-focused: account performance summaries, campaign/ad group/asset group/ad/keyword/audience analysis, entity discovery and lookup, anomaly and threshold detection, exportable reporting outputs, and cross-platform comparison between Microsoft Advertising and Google Ads.

In plain terms: you can ask an AI assistant natural-language questions about your own account's performance and get structured answers back, without opening the Bing Ads UI or building a custom report. That is genuinely useful for time-strapped in-house teams who don't want to maintain a reporting pipeline just to answer why CPCs spiked last Tuesday.

What it does not do, at least in the OpenBeta toolset available today, is let you create or modify campaigns through natural language. This is a read and insights layer, not a management layer.

The account-scope wall: no competitor visibility

Here is the constraint that matters most if you do competitive research: every version of the Microsoft Advertising MCP server, official or third-party, only authenticates into an account you already control. There is no equivalent of Meta's Ad Library or TikTok's Creative Center behind any Microsoft Ads MCP integration, because Microsoft doesn't operate a public ad-transparency archive for search ads the way social platforms do for their feeds.

That means MCP access to Microsoft Advertising solves an internal reporting problem, not a competitive intelligence problem. If your actual question is what a competitor is bidding on, or how their search ad copy changed this quarter, the official MCP server has nothing to offer, because it was never built to answer that question. Our breakdown of the Amazon ads API MCP server hits the same wall for a different reason: Amazon's ad APIs are account-scoped too, and neither platform runs a public archive of competitor ad creative or spend.

Setting it up: AAD, az CLI, and OAuth scopes

Getting the official server running takes more steps than a typical API key setup. You install the Azure CLI, sign in with az login, then create an AAD application registration scoped to both organizational and personal Microsoft accounts using az ad app create with sign-in-audience set to AzureADandPersonalMicrosoftAccount. From there you retrieve the client ID, generate a client secret, and configure your AI client of choice, whether that's Copilot Studio, VS Code, ChatGPT, or Claude, with the OAuth authorization and token URLs Microsoft publishes in its setup guide.

The required OAuth scope is ads.microsoft.com/msads.manage plus offline_access, which is worth flagging: that's the same scope used for full account management in the legacy SOAP and REST APIs, even though the MCP toolset itself is currently read-focused. Get your security team to sign off before rollout, since the permission grant is broader than the current feature set actually uses.

One deadline worth building into any 2026 integration plan: Microsoft has confirmed that starting October 1, 2026, all new Advertising API features and enhancements ship through the REST API only, with the legacy SOAP API being wound down. Any MCP tooling built on top of the older SOAP endpoints will need a REST migration before that date.

The third-party alternative: mcp-bing-ads and the write-access gap

Because the official server is read-only for now, a third-party project has stepped into the gap. mcp-bing-ads, maintained by developer mharnett, is an open-source npm package offering 10 tools for campaign, ad group, and keyword management, including bid automation, budget updates, and negative keyword management across both shared lists and campaign-level lists.

It ships read-only by default and requires an explicit environment variable, BING_ADS_MCP_WRITE set to true, to enable mutating actions, a sensible default given how easy it is to let an agent make an unreviewed bid change. Setup still requires an Azure AD app registration and a developer token, so the authentication overhead is comparable to the official server, but the tool surface is different: this one is built for people who want an agent to actually change campaign settings, not just read reports.

If your team already has an agent workflow for Google Ads and wants Bing parity, this is currently the more mature option for anything beyond reporting. Budget time for the OAuth setup either way, since neither path is a five-minute integration.

Where this fits in a real ad intelligence stack

Put the two Microsoft options next to each other and a pattern emerges that repeats across every ad platform we've covered: official platform MCP servers optimize for account-scoped reporting and, eventually, account-scoped management. They are built by the platform, for the platform's own advertisers, to reduce support load and UI friction. None of them are built to answer questions about the broader competitive landscape, because that was never their job.

That's the same conclusion our piece on the YouTube ads API MCP server reached: official platform tooling covers your account, not the market around it. If your workflow needs both, internal reporting via the platform's own MCP tools plus visibility into what competitors are running, you end up stitching together two different systems rather than expecting one to do both jobs.

Teams running multi-agent workflows increasingly split this cleanly: one agent handles account-scoped reporting and optimization through the platform's own MCP server, and a separate agent or tool handles cross-platform competitive monitoring. We covered this pattern in more depth in our guide to building a multi-agent ad intelligence workflow, including how to route data between the two without duplicating effort.

How this compares to other platforms' MCP rollouts

Microsoft is not first to ship ad-platform MCP tooling, and it is not last. Meta's ad tooling has moved toward broader API access for AI agents over the past year. TikTok's Creative Center exposes creative-level data through its own API surface. Snap has piloted agent access at a smaller scale. Each vendor is racing to give AI assistants a foothold inside its own walled garden, which is a rational move for platform growth, but it produces a fragmented landscape for anyone trying to build one unified agent workflow across five or six ad platforms at once.

The practical consequence is that a team running Microsoft, Google, Meta, and TikTok ads simultaneously now needs to integrate four separate MCP servers, each with its own auth model, its own toolset, and its own scope of what data it will and won't expose. Microsoft's AAD OAuth flow alone is heavier than what most of the social platforms require, which raises the setup cost for smaller teams without a dedicated ops or security engineer.

Reddit is the latest platform rumored to be evaluating a similar MCP integration for its ads business, following the same account-scoped reporting pattern the others have settled on. If that pattern holds, expect the same limitation: useful for your own numbers, blind to everyone else's.

What a self-hosted or third-party layer adds

Given the account-scope limitation baked into every platform-native MCP server, the tools that matter most for competitive research live outside the official ecosystem entirely. That includes ad library scrapers, cross-platform aggregation layers, and purpose-built competitive intelligence platforms that pull public ad data rather than authenticated account data.

The distinction is worth internalizing before you build an agent workflow: platform MCP servers answer questions about your own account performance. Competitive intelligence tools answer questions about the market. Neither substitutes for the other, and conflating them leads teams to expect visibility that the platform-native tooling was never designed to provide.

This is also why the OAuth scope question raised earlier matters operationally, not just for security review. A tool that requests full account management scope but only ships reporting features today is a tool your team should re-audit permissions on every quarter, not just at initial setup, since the feature set is likely to expand under the same grant.

Practical rollout checklist

Before connecting the official Microsoft Advertising MCP server to a production AI workflow, walk through four checks. First, confirm which AI client you're standardizing on, since Copilot Studio, VS Code, ChatGPT, and Claude each have slightly different connector setup steps in Microsoft's guide. Second, scope the AAD app registration narrowly and rotate the client secret on a fixed schedule rather than leaving it static indefinitely.

Third, treat the msads.manage scope as a management-level grant even though today's toolset is read-only, and revisit that assumption every time Microsoft ships a use-case update. Fourth, if your team also needs write access for bid or budget changes, evaluate mcp-bing-ads specifically for that gap rather than waiting on the official roadmap, since Microsoft has not published a timeline for expanding the OpenBeta toolset to include write operations.

None of these steps require the API MCP server itself; they're organizational hygiene that applies to any AAD-based integration, and skipping them is the most common way teams end up with over-permissioned agent access sitting unused for months.

Budget roughly a half-day for the full setup on a first pass, including AAD registration, client secret storage, and testing the connector against a live account. Teams that have already built AAD app registrations for other Microsoft 365 integrations will move faster, since the registration step itself is identical regardless of which Microsoft API you're eventually calling.

Choosing the right tool for your stack

If your goal is faster internal reporting on your own Microsoft Advertising account, the official MCP server is worth piloting now. It's free, Microsoft-maintained, and works with the AI clients most teams already use. If you need an agent to make bid or budget changes on Bing Ads today, mcp-bing-ads currently covers that gap, with the caveat that it's a smaller open-source project rather than a platform-backed one.

If your goal is competitive intelligence, neither tool helps. That requires a different category of tool entirely, one built to observe the market rather than just report on your own account. Match the tool to the question you're actually asking, not the platform you happen to be advertising on.

The fastest way to know which category you need: ask whether your next question is about your own account's numbers or about a competitor's. Account questions belong to the platform's own MCP server. Market questions belong somewhere else, and no amount of AAD scope will change that.

Frequently asked questions