Skip to main content
Every read and write through MCP is scoped to exactly one workspace: the user’s personal account, or one organization they belong to.

​
Why this exists

A Ringee user often has both a personal account and membership in one or more organizations. Contacts, calls, sessions and leads live in one of those scopes — never both. Without an explicit active workspace, an assistant asked to “find my contacts” cannot know which set to search.

​
The active workspace

The MCP connection starts in the workspace encoded in your URL: From there the assistant can move freely:
Switching takes effect for subsequent requests. It is persisted server-side, so it survives across sessions and clients until it is changed again.

​
Typical exchange

switch_workspace accepts an organization id or an exact, case-insensitive organization name, so the assistant can pass what the user actually said. Pass personal to return to the personal account.
The id is resolved against the user’s real memberships. An id the user does not belong to is rejected — an assistant cannot switch into a workspace the user has no access to.

​
What scoping affects

​
Organization roles

Ringee organizations have roles (admin, member, freelancer) that gate parts of the product. MCP goes through the same service layer as the dashboard, so those rules apply identically — an action the user cannot perform in the UI fails over MCP too.

​
Duplicate contacts across workspaces

Phone-number uniqueness is enforced within a workspace, not across them. The same person can exist as a contact in your personal account and in an organization; they are separate records with separate call histories.
If an assistant reports “contact already exists” for a number you cannot find, check the active workspace first — you are probably looking at a different one.

​
Next steps

Tool reference

list_workspaces and switch_workspace parameters

Safety

Confirmation rules for sensitive actions