You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,8 +14,8 @@
14
14
15
15
### Documentation
16
16
17
-
- simplify the setup story around three cases: default rootless setup, single-project fallback, and explicit `project` retries
18
-
- clarify that issue #63 fixed the architecture and workspace-aware workflow, but issue #2 is not fully solved when the client does not provide enough project context
17
+
- simplify the setup story around a roots-first contract: roots-capable multi-project sessions, single-project fallback, and explicit `project` retries
18
+
- clarify that issue #63 fixed the architecture and workspace-aware workflow, but issue #2 is still only partially solved when the client does not provide roots or active-project context
19
19
- remove the repo-local `init` / marker-file story from the public setup guidance
Copy file name to clipboardExpand all lines: docs/capabilities.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -105,6 +105,7 @@ Behavior matrix:
105
105
Rules:
106
106
107
107
- If the client provides workspace context, that becomes the trusted workspace boundary for the session. In practice this usually comes from MCP roots.
108
+
- Treat seamless multi-project routing as evidence-backed only for roots-capable hosts. Without roots, explicit fallback is still required.
108
109
- If the server still cannot tell which project to use, a bootstrap path or explicit absolute `project` path remains the fallback.
109
110
-`project` is the canonical explicit selector when routing is ambiguous.
110
111
-`project` may point at a project path, file path, `file://` URI, or relative subproject path.
Copy-pasteable templates: [`templates/mcp/stdio/.mcp.json`](../templates/mcp/stdio/.mcp.json) and [`templates/mcp/http/.mcp.json`](../templates/mcp/http/.mcp.json).
20
20
21
+
## Project routing contract
22
+
23
+
Automatic multi-project routing is evidence-backed only when the MCP host announces workspace roots. Treat that as the primary path.
24
+
25
+
If the host does not send roots, or still cannot tell which project is active, use one of the explicit fallbacks instead:
26
+
27
+
- start the server with a single bootstrap path
28
+
- set `CODEBASE_ROOT`
29
+
- retry tool calls with `project`
30
+
31
+
If multiple projects are available and no active project can be inferred safely, the server returns `selection_required` instead of guessing.
32
+
21
33
## Claude Code
22
34
23
35
```bash
@@ -197,9 +209,9 @@ Check these three flows:
197
209
198
210
1.**Single project** — call `search_codebase` or `metadata`. Routing is automatic.
199
211
200
-
2.**Multiple projects, one server entry** — open two repos or a monorepo. Call `codebase://context`. Expected: workspace overview, then automatic routing once a project is active.
212
+
2.**Multiple projects on a roots-capable host** — open two repos or a monorepo. Call `codebase://context`. Expected: workspace overview, then automatic routing once a project is active.
201
213
202
-
3.**Ambiguous selection** — start without a bootstrap path, call `search_codebase`. Expected: `selection_required`. Retry with `project` set to `apps/dashboard` or `/repos/customer-portal`.
214
+
3.**Ambiguous or no-roots selection** — start without a bootstrap path, call `search_codebase`. Expected: `selection_required`. Retry with `project` set to `apps/dashboard` or `/repos/customer-portal`.
0 commit comments