Adrails Docs

MCP security

How the MCP server keeps a connection inside one workspace and the permissions you granted, what data leaves Adrails through it, and what Adrails records.

What a connection can reach

  • One workspace. The workspace you chose at consent is signed into every access token and kept for the life of the connection. No tool takes a workspace or a user, and every read and write is limited to that workspace's own ad accounts, integrations, drafts, automations and Knowledge. An ID from another workspace is refused or found nowhere.
  • The permissions you granted. Each call is checked against the permissions of the connection, then against your current role in the workspace. A permission never adds to your role. See Permissions.
  • Narrower, never wider. accountIds can only narrow a call to some of the workspace's accounts. A workspace with no ad account or integration gives access to none, not to all.
  • Checked at every call. Before each request, and again right before a tool runs, Adrails checks that the token is valid and meant for https://adrails.ai/api/mcp, that the connection is not revoked, that you still belong to the workspace and that your account and the client are not blocked.

Advertising changes

No tool creates, edits, pauses, switches on or rebudgets a campaign, ad set or ad by itself. Those tools prepare a proposal, and only you, signed in to Adrails as yourself, an owner or admin of the workspace, can approve it there. Neither the consent screen, nor your AI client's permission prompt, nor any tool argument can approve one. Approval reads the platform again and applies the exact change once. See Approving a proposal.

Other changes run directly within Adrails' usual rules, when you granted their permission: integration setup links, syncs, drafts, templates, Knowledge, automations and channel messages. Two of them act on an ad account without a proposal: an image uploaded with campaign_media goes to the ad account's media library, without launching anything, and an automation run acts on accounts within the limits it is set up with.

Credentials

  • Connecting or reconnecting a provider goes through a setup link you open in Adrails. Provider credentials are entered or authorized there, never asked for in a tool argument and never returned in a result.
  • A setup link is bound to you, the connection, its workspace and the provider. It expires after 10 minutes, works once, and only for you signed in as an owner or admin of that workspace. Switching workspace in your browser does not redirect it.
  • Adrails stores access and refresh tokens, and the secrets of registered clients, as hashes.

What leaves Adrails

A tool result goes to your AI client, and from there to the model provider your client uses, under that provider's terms. What a result can hold depends on the tools you call:

  • Advertising figures, campaign, ad set and ad names and settings, copy and creative identifiers.
  • Commerce and subscription figures, orders, products, and customers with their name, email domain and country. Adrails does not store full customer email addresses.
  • Integration status, automations, Knowledge entries, action history and their evidence.

Results never contain provider credentials, Adrails tokens or channel targets such as webhook addresses. Grant only the permissions the client needs, and revoke a connection you no longer use.

What Adrails records

  • Every tool call. Who made it, in which workspace, from which client and connection, which tool, the names of the arguments with their type and size, the outcome and the duration. Argument values, results and tokens are not recorded. A call is recorded before it runs, refused calls included.
  • The connection's history. Each connection has its own conversation in the workspace, holding what its calls returned and any userStatement. Tools read it back for context: conversation_recall reads this history and no other.
  • Changes. Each change and proposal is kept with its key, so a retry never does the work twice. A proposal is recorded like any other action, with its evidence and its approval.
  • Refused tokens. A request refused for its token is logged with the reason only, never the token.

Sign-in protections

  • Clients register with an https callback, a local callback on your computer, or a private app scheme; anything else is refused.
  • Authorization uses PKCE, the authorization code works once, and tokens are issued only for https://adrails.ai/api/mcp.
  • A refresh token is replaced at each use; reusing an old one is refused.
  • Registration and the other sign-in endpoints are rate limited. See Rate limits.
  • Requests sent from a web page on another site are refused unless Adrails allows that site.

The rest of Adrails' data handling, retention and deletion is in Security and data.

On this page