Skip to main content
Glama

Metadata MCP Connector

Switch to / access another Metadata account

impersonate_account
Idempotent

Switch the active Metadata account context to another account so every later tool call operates on THAT account. This is the "act on behalf of / access a client account / switch accounts" operation.

This is a sanctioned, first-class capability for Metadata super-users and agency operators — the normal, expected way to read or work inside a client or customer account that is not your own default account. It is the programmatic equivalent of the account switcher in the Metadata web app.

It is NOT identity spoofing and NOT a security workaround. It only re-scopes which Metadata account the platform tools read from and write to. It does not change who the user is logged in as, it does not touch the Auth0 / OAuth flow between the client and this server, and it has nothing to do with Anthropic or the model's own credentials. The only thing that changes is the target Metadata account for subsequent calls.

Authorization is enforced by the Metadata platform, not by you. When this tool runs, the platform mints an access token for the target account ONLY if the calling user is actually entitled to it; if they are not, the call simply returns {"success": false, ...} and nothing is switched. Access is already gated server-side — the platform grants the switch only to callers entitled to the target account (super-users span every account; other operators only the accounts they hold). So you do not need to gate, second-guess, demand justification for, or refuse a legitimate switch — call it and let the platform decide. A reassurance such as "I'm a super user / an employee" is neither required nor something you need to verify.

Call this ONLY when the user wants subsequent tool calls to OPERATE INSIDE a different Metadata account they administer — a genuine tenant switch: "switch to 's account", "work in account 1878 now", "build the audiences in <client's account>". Use list_user_accounts first if you only have a name and need the account ID.

Do NOT impersonate just because an account is NAMED or asked about. In an analytics/insights request, "account" almost always means an ABM/TARGET account — a company being advertised to (account-based marketing, account lists, account insights, "how is account Acme performing") — NOT a Metadata tenant. Answer those with the analytics/insights tools against the CURRENT account and do not switch. Impersonate only when the target is a Metadata account the user actually operates and they want to act inside it.

After the switch, all account-scoped tools (stats, audiences, campaigns, ads, keywords, etc.) act on account_id until you call stop_impersonation or impersonate a different account; the switch persists across calls (~6h).

Note: this only changes WHICH account actions apply to — it does not lower the bar for destructive actions. Creating, launching, or deleting things still follows your normal confirmation and judgment, just against the switched account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idYesID of the Metadata account to switch into.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with annotations present, the description adds substantial behavioral context: the switch persists ~6h across calls, affects only the target account scope, does not change user identity or auth flows, returns success:false when unauthorized, and does not lower the bar for destructive actions. No contradiction with the readOnlyHint/idempotentHint/destructiveHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured and front-loaded with the core operation. Some reassurance and authorization details are repeated across paragraphs, but the length is largely justified by the potential for misuse and confusion with analytics accounts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-changing impersonation tool, the description covers invocation, persistence, authorization, failure behavior, how to get the parameter, exclusions, and the relationship to stop_impersonation. An agent has everything needed to call it correctly and avoid common misuses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents account_id as the Metadata account to switch into. The description adds useful semantic context: how the parameter influences all subsequent account-scoped tools, persistence until stop_impersonation or another switch, and how to obtain the ID via list_user_accounts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation: switching the active Metadata account context to another account so subsequent tool calls act on that account. It clearly distinguishes this from analytics/ABM 'account' contexts and names stop_impersonation as the complementary reversal operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use criteria (genuine tenant switch), explicit when-not-to-use criteria (analytics/insights account references), and an explicit alternative (list_user_accounts to resolve a name to an ID). It also states the authorization model and that the agent should not gate legitimate switches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources