From e02154b0f3cba8637430a4068681d9746c0dd8f8 Mon Sep 17 00:00:00 2001 From: Joshua Buss Date: Mon, 3 Aug 2026 12:36:05 -0700 Subject: [PATCH] docs: writes honour the per-call workspace override usage.md still said writes ignore the workspace argument and always target the connection's own workspace. That stopped being true in #8: mcp.go applies scopeOverride to every non-registry tool, so create_doc, update_doc, retag_doc, soft_delete_doc, restore_doc, hard_delete_doc, create_folio and add_folio_file all place the write in the named workspace. Verified against a running v1.4.3 by creating, soft-deleting, restoring and hard-deleting a probe document in another workspace from a default-pinned connection: it resolved there throughout and returned not found in default. Also notes the two registry tools that legitimately ignore it, and keeps the recommendation to pin a connection for sustained work. --- web/usage.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/web/usage.md b/web/usage.md index 804e5e6..b046f91 100644 --- a/web/usage.md +++ b/web/usage.md @@ -98,9 +98,16 @@ tags and search results in other workspaces are invisible to you, and slugs only have to be unique within yours. `list_workspaces` shows what exists; `create_workspace` registers one, but does not move you into it. -To read elsewhere without reconnecting, pass `workspace` to any read tool — -`list_docs {"q":"...","workspace":"other"}`. Writes ignore it and always target -your own workspace, and it is refused if your token is confined to one. +To act elsewhere without reconnecting, pass `workspace` to any tool — +`list_docs {"q":"...","workspace":"other"}`. Since #8 this applies to **writes +too**: `create_doc`, `update_doc`, `retag_doc`, `soft_delete_doc`, `restore_doc`, +`hard_delete_doc`, `create_folio` and `add_folio_file` all honour it and place +the write in the named workspace. It is refused if your token is confined to one, +and it is ignored by `list_workspaces` and `create_workspace`, which act on the +registry rather than inside a workspace. + +Pinning a connection with `X-Workspace` is still the better default for sustained +work somewhere — it makes placement structural instead of per-call. If a store looks unexpectedly empty, you are probably pointed at the wrong workspace rather than at an empty tracker.