|
| 1 | +--- |
| 2 | +title: Workspaces — Folder-Based Routing |
| 3 | +description: Map a project folder to the exact toolset it should get. McpMux routes each workspace to its own Space and FeatureSet automatically, so every AI app sees the right tools for the folder it has open. |
| 4 | +--- |
| 5 | + |
| 6 | +Workspaces map a **project folder** to the exact toolset it should get. When an AI app opens that folder, McpMux hands it the Space and FeatureSet you mapped — and nothing else. |
| 7 | + |
| 8 | +## Why Workspaces |
| 9 | + |
| 10 | +[Spaces](/docs/spaces/) isolate *contexts*; Workspaces decide which context a session actually gets — automatically, per folder. |
| 11 | + |
| 12 | +Your AI app (Cursor, VS Code, Windsurf, Claude Code) tells McpMux which folder it's working in — its MCP **root**. McpMux uses that to route each folder to its own toolset: |
| 13 | + |
| 14 | +- Open your **backend repo** and the AI sees your database, cloud, and deploy tools. |
| 15 | +- Open a **docs folder** and it sees only search and filesystem. |
| 16 | +- Open an **untrusted project** and it gets a read-only set — or nothing. |
| 17 | + |
| 18 | +Map a folder once and every future session from that exact path resolves automatically. Matching is **per-folder and exact**, so nothing leaks across projects. |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +## How a request resolves |
| 23 | + |
| 24 | +When an AI app makes a request, McpMux resolves the toolset in order: |
| 25 | + |
| 26 | +1. The app reports its **workspace root** (the folder it has open). |
| 27 | +2. McpMux looks for a **Workspace mapping** for that exact path. |
| 28 | +3. The mapping points at a **Space** (which servers + credentials) and a **FeatureSet** (which tools, prompts, and resources from those servers). |
| 29 | +4. The FeatureSet's included features **are** the effective toolset the session resolves to. |
| 30 | + |
| 31 | +Because routing is driven by the reported folder, it is decided **per session, not per app** — the same app gets different tools depending on which project it has open. |
| 32 | + |
| 33 | +## Creating a mapping |
| 34 | + |
| 35 | +Open the **Workspaces** tab and click **Add mapping**: |
| 36 | + |
| 37 | +- **Workspace folder** — browse for a folder or paste an absolute path. Accepts `/unix`, `C:\windows`, and `file://` forms. |
| 38 | +- **Space** — the profile whose servers and credentials this folder draws from. |
| 39 | +- **FeatureSet** — the curated bundle of tools this folder is allowed to use. Pick one, or combine several into a single effective set. |
| 40 | + |
| 41 | +Unmapped folders receive no tools until you map them — an explicit, fail-closed default so a new project never silently inherits another's access. |
| 42 | + |
| 43 | +## Let the AI map it for you |
| 44 | + |
| 45 | +You don't have to open the Workspaces tab at all. With [Tool Optimization](/docs/tool-optimization/), an assistant can compose a FeatureSet and pin the current folder to it from chat: |
| 46 | + |
| 47 | +> *"@mux build a minimal toolset for this Next.js repo and pin it to this folder."* |
| 48 | +
|
| 49 | +The pin is a Workspace mapping — it sticks for every future session from that path. Changes are gated behind a one-click approval that names the exact Space. |
| 50 | + |
| 51 | +## Next steps |
| 52 | + |
| 53 | +- [Spaces](/docs/spaces/) — the isolated contexts a Workspace routes to |
| 54 | +- [FeatureSets](/docs/feature-sets/) — the curated toolsets a Workspace grants |
| 55 | +- [Tool Optimization](/docs/tool-optimization/) — let the AI map folders for itself |
| 56 | +- [Clients](/docs/clients/) — how connected apps report the folder that drives routing |
0 commit comments