feat(mcp): expose space param on memory_search#17
Merged
Conversation
The omem server's `/v1/memories/search` endpoint already accepts a
`space` query param that filters which spaces to search across
(comma-separated IDs, a single ID, or `all`). The MCP plugin's
`memory_search` tool didn't expose it, so callers had no way to scope
a query to specific spaces from a tool call.
This adds `space?: string` to:
- the `memory_search` tool's input schema
- `searchMemories()` in client.ts (passes through to URL params)
Why this matters: the natural use case is per-session scoping (e.g.
"this Claude instance defaults to my homelab space") plus per-query
overrides ("for this specific question, also look in the synchresis
space because the answer's there"). Both work through the same
parameter — set as a session default by the caller, or pass per-call.
No breaking change — the param is optional and omitting it preserves
the existing "search all accessible spaces" behavior.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Contributor
|
Merged — thanks! Clean addition, makes per-query space scoping actually usable from MCP clients. 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The omem server's
/v1/memories/searchendpoint already accepts aspacequery param that filters which spaces to search across (comma-separated IDs, a single ID, orall). The MCP plugin'smemory_searchtool didn't expose it, so callers had no way to scope a query to specific spaces from a tool call.This adds
space?: stringto:memory_searchtool's input schemasearchMemories()inclient.ts(passes through to URL params)Why this matters
The natural use case is per-session scoping (e.g. "this Claude instance defaults to my homelab space") combined with per-query overrides ("for this specific question, also look in the synchresis space because the answer's there"). Both work through the same parameter — set as a session default by the caller, or pass per-call.
Without it, an agent can't take a hint like "the ELINA notes are in the synchresis space" and run a targeted cross-space query — it'd have to fall back to the default (which may or may not include that space, depending on the user's role and membership).
The server side is already wired (
api/handlers/memory.rs:332does the comma-split +'all'handling). This is just plumbing the client surface to match.Compat
Context
Part of evaluating omem for a team rollout at Synchresis (the MSP I work at). The spaces feature is the foundation we'd use to separate canonical org content from personal scratch content; per-query space scoping is what makes the conversational UX work ("this question is about $TOPIC which lives in $SPACE") rather than forcing users to bounce between sessions or maintain mental scope.
🤖 Generated with Claude Code