Workspace and teamspace context

Identify the connected workspace

Start with api_getWorkspaceInfo. It identifies the authenticated user and credential-bound workspace. Use api_getWorkspace when you need more workspace metadata.

Your connection determines the workspace you can access. Supplying a teamspace ID does not switch to another organization’s workspace or grant new permissions. A key pinned to a teamspace cannot be moved to another teamspace by overriding space_id; conflicting scope is rejected. See API key scoping.

Select a teamspace

1. Call api_listTeamspaces.
2. Match the requested teamspace name to a returned numeric ID.
3. Include that space_id on every related tool call.
4. Check that newly created resources belong to the intended destination.

Use the Acme teamspace for this campaign. Resolve its ID first, then keep all drafts, generated assets, and project items in that teamspace.

MCP has no saved active teamspace shared across calls. Omitting space_id uses the credential’s default context. Naming a teamspace in a previous conversation does not change that default.

Keep context through a workflow

Use the same teamspace for discovery, creation, follow-up reads, and manual polling. The connector also forwards the call’s context through its own polling and follow-up operations.

When switching clients or starting a new conversation, resolve the destination again. For agency work, include both the client name and teamspace in your brief.

Resolve resource IDs

List or search before acting on a named resource. Social accounts, brand kits, projects, task boards, and workflow runs use different identifiers. Keep the IDs returned by each tool; a title or an unrelated object’s ID is not a substitute.

If an item is unexpectedly missing, check context and access before creating a replacement. A not-found response can mean the connection is looking in the wrong teamspace.