Understanding Workspaces
Workspaces are the organizational boundary in MCPBundles. Everything you do — MCP servers, credentials, A2A agents, tool executions — lives inside a workspace. The workspace determines who can see and use your resources.
Personal vs Team Workspaces
Every user gets a personal workspace on signup. When you invite someone, your workspace becomes a team workspace. There's no explicit toggle — the workspace evolves naturally based on membership.
| Personal Workspace | Team Workspace | |
|---|---|---|
| Members | Just you | 2 or more |
| MCP servers | Only you can see and use them | All members see and use all MCP servers |
| Credentials | Private to you | Usable by all members; viewable/editable by owner only |
| A2A Agents | Private to you | Visible to all members |
| History | Only your executions | All members' executions with attribution |
| Studio threads | Private | Private (always personal, even in team workspaces) |
When to use each
Personal workspace — Your private space. Personal API keys, experimental MCP servers, side-project A2A agents. Nothing here is visible to anyone else.
Team workspace — Your team's shared environment. Connect HubSpot once and everyone can use it. Create an A2A agent and the whole team can see it running. One person sets up an MCP server and it works for everyone — zero setup for new members.
What's shared in a team workspace
When your workspace has 2+ members, everything is shared by default:
MCP servers
When any member enables an MCP server, it's enabled for the workspace. All members can see it, open it in Studio, and use its tools. No per-user "enable" step — if it's on, it's on for everyone.
Credentials
When you connect a credential (OAuth or API key) in a team workspace, all members can use it — but only the person who created it can view or edit it. Alice connects HubSpot → Bob opens the HubSpot MCP server → all tools work immediately using Alice's credential. Zero setup for Bob.
Bob can see that a HubSpot credential exists and who added it, but he cannot see the API key values or modify the credential. The credential card shows "Added by Alice" so it's clear who owns it.
Each MCP server+provider combination has exactly one credential binding. If the team needs a different HubSpot instance for a different use case, they create a separate MCP server.
A2A Agents
All workspace A2A agents are visible to all members. You can see other members' agent configurations and run history. Only the creator (or an Admin) can edit or delete an agent.
Tool executions
All tool executions are visible with user attribution — you can see who ran what and when.
AI API keys
AI keys (for Studio and A2A agent execution) are workspace-level. Any member's OpenAI key can power any workspace A2A agent or Studio session.
What stays private
Some things remain personal even in team workspaces:
| Resource | Why private |
|---|---|
| Studio threads | Chat history is personal — your AI conversations are yours. Like Slack DMs vs channels. |
| MCPBundles API keys | Machine auth tokens for API access. Personal security credentials. |
| Proxy connections | Per-device proxy state. |
The workspace boundary
The workspace is the privacy boundary. If you put something in a team workspace, it belongs to the workspace. If you don't want to share something, put it in your personal workspace.
This is the same model as:
- Don't put personal files in the company Google Drive
- Don't post personal messages in the company Slack channel
- The container determines the audience
The workspace switcher (next to the logo) is always available. Switch to your personal workspace for private credentials, switch back to the team workspace for shared work.
Inviting a team member
To invite someone to your workspace:
- Open Dashboard → Settings → Team (or the workspace member panel).
- Enter their email and choose a role (Member, Admin, or Owner).
- Send the invite — they accept from the email link and land in your workspace.
First invite — the transition moment
When you invite the first member to a workspace, it transitions from personal to team. The invite flow shows a clear warning:
Inviting a member makes this a team workspace. All MCP servers, credentials, and A2A agents in this workspace will be shared with all members.
This is the only gate. After that, everything in the workspace is shared — no confirmation modals on every action.
Roles and permissions
Workspace roles control what you can change, not what you can see. In a team workspace, all members see the same data.
| Action | Member | Admin | Owner |
|---|---|---|---|
| View all workspace resources | Yes | Yes | Yes |
| Enable an MCP server | Yes | Yes | Yes |
| Connect a credential | Yes | Yes | Yes |
| Edit/delete own credential | Yes | Yes | Yes |
| Create an A2A agent | Yes | Yes | Yes |
| Disable an MCP server | No | Yes | Yes |
| Edit/delete another member's MCP server | No | Yes | Yes |
| Edit/delete another member's A2A agent | No | Yes | Yes |
| View another member's credential values | No | No | No |
| Edit another member's credential | No | No | No |
| Disconnect another member's credential | No | Yes | Yes |
| Manage workspace members | No | Yes | Yes |
| Manage billing | No | Yes | Yes |
| Transfer ownership | No | No | Yes |
Additive vs destructive
The permission model is simple: additive actions are open, destructive actions are restricted.
- Any member can enable an MCP server, connect a credential, or create an A2A agent — these add capability to the workspace
- Only Admins+ can disable MCP servers, disconnect credentials, or delete other members' resources — these remove capability and could break things for the team
New member onboarding
When someone joins a team workspace, everything works immediately:
- They see all enabled MCP servers on the MCP servers page
- They open any MCP server in Studio — all tools work using workspace credentials
- They see all workspace A2A agents and their run history
- They see all workspace tool executions with user attribution
No setup required. No "connect your own credentials" step. The workspace's credentials are already working — new members can use them without seeing the secret values.
Cross-workspace isolation
Workspaces are completely isolated from each other. If you're a member of both "Acme Sales" and "Acme Engineering":
- Credentials in "Acme Sales" are invisible from "Acme Engineering"
- MCP servers enabled in one workspace don't appear in another
- A2A agents and history are workspace-specific
The workspace switcher lets you move between workspaces. Each one is its own self-contained environment.
When a member leaves
When someone is removed from a team workspace:
- Any credentials they connected are flagged as "orphaned"
- Workspace admins are notified with details on which providers are affected
- The credentials continue working (OAuth tokens don't expire immediately)
- Admins can reconnect the credentials under an active member's account
This is proactive — the platform warns you before tokens silently expire and break tools for the team.