Windsor.ai MCP server: what it answers and what it cannot execute

The Windsor.ai MCP server, often searched as Windsor AI MCP, lets an AI client such as Claude ask questions over the data Windsor.ai has already connected: Meta Ads, Google Ads, a CRM, a store, any of its 350+ sources. It is built for analysis. What it cannot do, by design, is execute anything: Windsor.ai does not pause campaigns, change budgets or create ads, and its MCP inherits that boundary. This article lays out what an ETL MCP answers well, where it stops, and how it compares with an ads MCP that reads live from the platforms and can act with guards. I built Vazante, one of those, so the comparison is opinionated, and I say where Windsor wins.

What an MCP server does for a marketer

MCP is the Model Context Protocol, an open standard that lets a model call outside tools. A server publishes a list of tools; the model, acting as the client, picks one and calls it with the parameters the conversation implies. When you ask Claude "spend by campaign last week", the model chooses a tool that can answer, the server runs the query and returns rows, and Claude writes the answer in plain English. If the term is new, what is MCP for marketers covers it in five minutes.

The rule that matters for everything below: the model can only do what the tools expose. A server without a "pause campaign" tool cannot pause a campaign, however nicely you ask. The tool list is the permission list.

What the Windsor AI MCP can answer

Windsor.ai describes its MCP as a way to analyze the data you have connected in Windsor with AI. Read that as an analysis layer on top of the pipe. Three things follow from it.

Breadth is the strength. Windsor.ai's catalog is the point of the product: 350+ sources, from ad platforms to CRMs to e-commerce stores. If those sources are connected in your Windsor account, an MCP over them can, in principle, answer questions that cross platforms: ad spend next to a metric that lives outside the ad accounts. An ads-only connector cannot do that, because it never sees the CRM.

The answers come from the pipe. An ETL MCP reads what Windsor has pulled. That is the same data feeding your Looker Studio or BigQuery destination, so the number Claude gives you and the number on the dashboard come from one place, which is good for consistency. How fresh that number is depends on how Windsor refreshes the source; as of September 2026, Windsor's plans described daily sync on Basic and daily or hourly on Standard for destination tasks. Check windsor.ai/pricing for the current terms and ask them how the MCP's freshness relates to those syncs before you rely on it for "today".

Setup and plan details are theirs to state. I am not going to list Windsor's tool names, limits or which plans include the MCP, because I have not verified them and they change. Windsor's own documentation is the source; treat any third-party list of its tools, including one from a blog, as stale until checked.

For a team with a warehouse and a dozen sources, that combination is valuable. Ask "how did paid spend track against pipeline last quarter?" and, if both feeds are connected, the MCP has the rows to answer.

What it cannot execute

Windsor.ai is an ETL. It moves data from sources to destinations. It does not run actions on ad platforms: no pausing, no reactivating, no budget changes, no campaign or ad creation. This is structural. A pipe is read-only on purpose, and a pipe that could write to your ad accounts would be a liability, not a feature.

So the workflow with an ETL MCP ends at the answer. You ask which campaign's cost per lead doubled, Claude tells you, and then you open Ads Manager and pause it yourself. For a BI team, that is exactly right; analysts do not pause campaigns. For a media buyer whose job is deciding what to pause at nine in the morning, that last step is the whole job, and the MCP did not touch it.

The Windsor.ai alternatives article sorts teams by whether they need a pipe at all. The short version for this page: if reading across many sources is the value, an ETL MCP fits. If acting on paid media is the value, you need a different kind of server.

Two kinds of ads MCP

There are two shapes of MCP server a marketer will meet, and they are not interchangeable.

An ETL MCP sits on top of a data pipe. It answers over whatever the pipe collected, across every connected source. Broad, consistent with your dashboards, and read-only.

An operational ads MCP sits directly on the ad platform APIs. It answers over Meta, Google and similar accounts, live, and it may expose write tools. Narrow, current, and able to act. Meta Ads MCP server: build your own or use a hosted one covers the trade-offs of running one yourself.

Vazante is the second kind. It is a Brazilian product built for Meta, Google and TikTok Ads, with the interface available in English and a native MCP connector for Claude and ChatGPT. Its read tools query the Meta and Google APIs at the moment you ask; its write tools, on Meta and Google, stay off until you switch them on, and then run behind a cap per action, a confirmation in the chat and an audit log. TikTok Ads is read-only. Pricing starts from US$ 23 a month on the annual plan, billed in your own currency, and there is a 7-day trial of the Basic plan with no card.

Side by side, axis by axis

Read the freshness row carefully, because it is the one people get wrong in both directions. An ETL MCP is not stale by nature; it is as fresh as the pipe. An operational MCP is not "better" by nature; it is live but narrow. Pick the axis that matches the question you ask most often.

Questions to ask before connecting either

Run this list against any MCP server you point Claude at, ETL or operational.

• Where does the data come from, and how fresh is it? "From the pipe, synced nightly" and "from the API, right now" are both fine answers. Not knowing which one you have is the problem.
• Which accounts can it see? You should be able to choose account by account and shrink the list later.
• Can it write? If no, you know the workflow ends at the answer. If yes, the next four questions matter.
• Is writing off by default? Reading a report and pausing a campaign are different powers.
• Is there a cap per action? A ceiling turns a misunderstanding into a refusal instead of an invoice.
• Does it confirm before acting? Every change to a live campaign should be shown in the chat and wait for a yes.
• Is every change logged, refused attempts included? With author, origin and before-and-after state.
• What happens when it cannot answer? The right behaviour is to say the field is not available. A server that lets the model improvise is worse than no server.

For an ETL MCP, the first two matter most. For an operational MCP, all eight.

Which one for which team

A BI team with a warehouse. Windsor.ai feeds it, and the Windsor.ai MCP lets an analyst ask across sources without writing a query. Vazante adds nothing to that stack unless the paid-media team wants to act from the chat.

An agency with account managers in Ads Manager every morning. The daily questions are narrow (spend, CPL, ROAS, which ad set to pause) and the answer leads to an action. An operational MCP fits. If the agency also delivers a cross-source dashboard, the two connectors can coexist in Claude.

A freelancer with four to twelve paid accounts. No warehouse, no CRM feed. An ETL MCP would be answering over a pipe that exists only to feed the MCP. Go straight to the operational kind, start read-only for a week, and turn writing on once the numbers hold up against Ads Manager.

Where to start

If your questions cross a CRM, a store and ad platforms, connect the Windsor.ai MCP and confirm freshness with Windsor before you trust it for today's numbers. If your questions are "what do I pause and what do I fund", start a Vazante trial, connect one account, add the connector and ask something you already know the answer to. The Windsor.ai alternative page has the wider comparison, plans are on pricing, and AI for media buyers is what changes in the job once the report can answer back and act.