Understanding Workspaces
Workspaces are the organizational boundary in MCPBundles. Everything you do — bundles, credentials, 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 |
| Bundles | Only you can see and use them | All members see and use all bundles |
| Credentials | Private to you | Usable by all members; viewable/editable by owner only |
| 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 bundles, side-project 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 agent and the whole team can see it running. One person sets up a bundle 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:
Bundles
When any member enables a bundle, it's enabled for the workspace. All members can see the bundle, 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 bundle → 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 bundle+provider combination has exactly one credential binding. If the team needs a different HubSpot instance for a different use case, they create a separate bundle.
Agents
All workspace 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 agent execution) are workspace-level. Any member's OpenAI key can power any workspace 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.
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 bundles, credentials, and 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 a bundle | Yes | Yes | Yes |
| Connect a credential | Yes | Yes | Yes |
| Edit/delete own credential | Yes | Yes | Yes |
| Create an agent | Yes | Yes | Yes |
| Disable a bundle | No | Yes | Yes |
| Edit/delete another member's bundle | No | Yes | Yes |
| Edit/delete another member's 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 a bundle, connect a credential, or create an agent — these add capability to the workspace
- Only Admins+ can disable bundles, 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 bundles on the Bundles page
- They open any bundle in Studio — all tools work using workspace credentials
- They see all workspace 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"
- Bundles enabled in one workspace don't appear in another
- 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.