Adsroid MCP is built on a single architectural principle: one endpoint handles everything. One URL, one authentication mechanism, and one tool schema, regardless of how many platforms, accounts, or projects you manage. This article explains how that works under the hood and why it matters in practice.
The single endpoint model
Most integrations are designed per platform. A Google Ads plugin connects to Google Ads. A Meta integration connects to Meta. If you run campaigns across multiple platforms, you end up with multiple integrations, multiple authentications, and multiple contexts to manage, including inside your AI conversations.
Adsroid MCP takes a different approach. The MCP server sits as an abstraction layer between the AI assistant and every advertising platform. All tool calls, regardless of the target platform or account, pass through the same endpoint:
https://mcp.adsroid.com/mcpFrom the AI’s perspective, there is no platform boundary to navigate. It works with a unified set of tools, uses a single API key, and receives consistently structured responses, whether the underlying call went to Google Ads, Meta, or any other connected platform.
As new platforms are added to the server, they become available immediately through the same endpoint, with no change required on the client side.
How requests are routed
Every tool call made by the AI includes an adsroid_project_id parameter. This is the identifier of the project configured in your Adsroid workspace, it contains all the information needed to route the request correctly: which ad platform to target, which account to authenticate against, and which credentials to use.
The routing flow works as follows:
- The AI sends a tool call to the MCP endpoint, including the
adsroid_project_idand the tool-specific parameters. - The MCP server validates the request against your API key.
- The server resolves the
adsroid_project_idto identify the target platform, account, and credentials. - The appropriate tool is executed against the platform’s API in real time.
- The result is returned to the AI in a consistent format.
This means you can manage multiple ad accounts, on different platforms, within the same conversation, simply by referencing different project IDs. The endpoint never changes. The authentication never changes. Only the target of the call does.
The project model
A project in Adsroid is the link between a workspace and an ad account. It stores the platform type, the account identifier, and the authentication credentials required to make API calls on that account’s behalf.
When you connect Adsroid MCP to Claude, your API key gives the AI access to all projects in your workspace. This means:
- A freelancer or consultant can manage all client accounts from a single connection
- An agency can give each client their own project while maintaining one centralised MCP integration
- A business running campaigns across multiple platforms can address all of them in the same session
There is no limit on the number of projects a workspace can contain, and no need to reconnect or re-authenticate when switching between them.
The tool architecture
Adsroid MCP exposes its capabilities as a flat list of named tools. Each tool maps to a specific operation on a specific resource type. Tools are grouped into four functional categories, though the grouping is conceptual, all tools are available through the same endpoint.
Analytics tools are read-only. They query live data from the ad platform and return structured results. They never modify any account element.
Manager tools are write operations on existing elements — updating statuses, adjusting budgets, modifying keywords, managing extensions. These tools are designed with a confirmation step built into the AI’s behaviour: the assistant will always present what it intends to do before executing a Manager tool.
Builder tools handle the creation of new elements from scratch. Like Manager tools, they require explicit user approval before any change is applied.
Experiment tools cover the full A/B testing lifecycle, spanning both read and write operations, and are designed as a self-contained workflow within the broader tool set.
The request lifecycle
The following describes what happens, end to end, when you ask Claude a question that requires a tool call.
Step 1 — Intent resolution. Claude reads your message and determines which tool or sequence of tools is needed. It constructs the full parameter set for each call.
Step 2 — Tool dispatch. Claude sends the tool call to the MCP server. The server receives the request, extracts the API key from the headers, and verifies it.
Step 3 — Project resolution. The server reads the adsroid_project_id from the tool parameters and retrieves the associated platform credentials from the Adsroid database.
Step 4 — Platform API call. The server executes the tool against the target platform’s API, Google Ads, Meta, or another connected platform, using the resolved credentials. This call happens in real time, with no caching or intermediate storage.
Step 5 — Response. The platform API returns its response. The MCP server normalises it and passes it back to Claude. Claude interprets the result and continues the conversation.
The entire cycle, from Claude sending a tool call to receiving the result, typically completes in under two seconds.
Zero data retention
No data transits through Adsroid’s infrastructure beyond what is strictly necessary to authenticate and route the request. Platform API responses are passed through in real time and never stored, logged, or cached at the MCP server level.
Your account data, campaign structures, performance metrics, audience lists, keyword sets, exists only in the ad platform’s own systems and in Claude’s active conversation context. It is not written to any Adsroid database at any point.
