create_memory_project MCP tool cannot target a non-default workspace

[groksrc]

Summary

The create_memory_project MCP tool always creates projects in the default workspace (Personal). There is no parameter to target a specific workspace (organization/teams), and a path-prefix workaround is silently dropped.

Reproduction

Account has access to two workspaces (visible via list_workspaces):

• Personal — type=personal, default
• drew cain — type=organization

1. No workspace parameter exists

The create_memory_project schema only accepts project_name, project_path, set_default, output_format. No workspace_slug / tenant_id / workspace_id.

create_memory_project(project_name="org-cloud-test", project_path="/org-cloud-test")
→ landed in Personal workspace

2. Path-prefix workaround silently dropped

create_memory_project(project_name="org-path-test", project_path="drew-cain/org-path-test")
→ response: "Path: /org-path-test"   (drew-cain/ prefix stripped)
→ landed in Personal workspace

Expected

Either:

1. Add a workspace_slug (or tenant_id / workspace_id) parameter to create_memory_project so MCP clients can target an organization workspace.
2. Or, at minimum, reject creation with an error when there's no way to target the intended workspace, and document that org-workspace creation must go through the bm CLI or web UI.

The current behavior is the worst case — the path prefix is silently accepted and discarded, masking the limitation.

Environment

• MCP server: Basic Memory Cloud - Dev
• Discovered while exercising the cloud MCP tool surface from Claude Code.

[claude]

Claude finished @groksrc's task in 2m 34s —— View job

---

Issue Triage

• Gather context and analyze issue
• Read relevant MCP tool code
• Check for duplicate issues
• Add appropriate labels
• Provide triage summary

---

Analysis

Classification: Bug + Enhancement (cloud/MCP)

This issue has two distinct problems:

1. Bug: Silent path-prefix stripping (the worse problem)
The create_memory_project tool strips workspace path prefixes without any error or warning. Looking at the implementation in src/basic_memory/mcp/tools/project_management.py (lines 366-489), the path goes through normalize_project_path() before hitting the API, which strips the prefix. The user receives Path: /org-path-test back with no indication their drew-cain/ prefix was silently discarded. This is a clear bug — the tool should either honor the prefix or reject it with a clear error.

2. Enhancement: No workspace targeting parameter
The create_memory_project schema accepts only project_name, project_path, set_default, and output_format. There is no workspace_slug, workspace_id, or tenant_id parameter. The CloudProjectCreateRequest schema in src/basic_memory/schemas/cloud.py (lines 37-46) similarly has no workspace field. Adding this requires:

• A new parameter on the MCP tool
• Updating CloudProjectCreateRequest schema
• Routing the workspace ID via X-Workspace-ID header in the cloud client during project creation

Priority: Medium

• Affects users with org/team workspaces (growing use case)
• No data loss, but silently misbehaves (which erodes trust)
• CLI workaround exists: basic-memory project add or the web UI

Complexity: Medium

• The cloud client already has workspace routing infrastructure (X-Workspace-ID header in async_client.py line 100-101)
• But project creation needs to pass workspace context during the create call, which is a different flow from per-project routing of existing projects

Labels applied: bug, enhancement, cloud

No duplicates found in the issue tracker.

---

Suggested Fix Path

The minimal fix should address the bug first: if a path contains a /-prefixed workspace segment that gets stripped, raise an informative error rather than silently dropping it. A doc comment or error message should note that workspace targeting must go through the CLI or web UI until the feature is added.

The fuller fix would add a workspace_slug parameter to the MCP tool, propagate it through the CloudProjectCreateRequest, and inject it as X-Workspace-ID in the cloud client during the create request.