One workspace, one ad account

A workspace is bound to exactly one Meta ad account. Every tool and every endpoint reads and writes that account, so there is no projectId or account id to pass anywhere. The REST paths are /api/v1/launches, not /api/v1/accounts/{id}/launches.

What reaches a workspaceCopy Anchor Link

A key's scope and approval grant are its own. They are never its minter's in-app authority. A key also stops working the moment its minter leaves the workspace.

Which account am I on?Copy Anchor Link

Call meta_get_workspace first, and before any write. It returns the workspace, your role, adAccountId (the Meta ad account every call hits, or null if none is connected), the user the session acts as, and the principal: human over OAuth, agent for an rsk_ key. REST has the same read at GET /api/v1/workspace.

More than one workspaceCopy Anchor Link

If you belong to several workspaces, an OAuth session can list and move between them:

• meta_list_workspaces lists the workspaces you are a member of, with active marking the one this session is on.
• meta_switch_workspace moves your MCP sessions to another one. Every later call reads and writes that workspace's ad account. It is the same switch as the web app's workspace picker, minus the browser's own choice, so a browser still on another workspace moves MCP back when a page loads there. The result says to pick it in the app too.

An rsk_ key is pinned. The switch is refused for a key, and the list shows it only its own workspace. REST has no switch at all.

Who can do what in the appCopy Anchor Link

Roles come from the shared members kit. In this app:

• An admin connects the Meta account, renames the workspace, manages the roster and creates or revokes API keys.
• Any member can launch, sync and activate in the app.
• Over MCP and REST, the ability to approve comes from the credential, not the member's role. See Paused is the draft.