fetch MCP tool cannot target non-default project (no project_id parameter)

[groksrc]

Summary

The fetch MCP tool's schema only takes id. There is no project_id / project parameter, so it always resolves the permalink against the default project. When a permalink references a note in any other project (including in the same workspace, or in an org workspace), the tool returns "Note Not Found" plus unrelated suggestions from the default project.

Reproduction

Two projects with overlapping namespace exist:

• Personal/getting-started
• drew-cain/getting-started (organization)

A note is created in drew-cain/getting-started:

• permalink: getting-started/notes/org-endpoint-smoke-test
• project_id: 755a4414-1c2a-4c5a-8504-ee743a1b8b92

fetch(id="getting-started/notes/org-endpoint-smoke-test")
→
{
  "title": "Org Endpoint Smoke Test",
  "text": "# Note Not Found in main: \"getting-started/notes/org-endpoint-smoke-test\" ...",
  "metadata": {"error": "Document not found"}
}

The "related notes" returned are from a completely different project (open-ghl-mcp/...) — i.e. fetch defaulted to main regardless of the permalink prefix.

Other read tools (read_note, read_content, view_note) accept project_id and work correctly.

Expected

fetch should accept a project_id (and/or project) parameter matching the rest of the tool surface, and use it to resolve the permalink. Without that, fetch is unusable for any project other than the user's default.

[claude]

Claude finished @groksrc's task in 2m 37s —— View job • claude/issue-782-20260503-0116 • Create PR ➔

---

Analysis & Implementation Plan

• Gather context and analyze the issue
• Find and read the fetch tool implementation (src/basic_memory/mcp/tools/chatgpt_tools.py:162)
• Check how read_note implements project_id — it accepts project and project_id, passes to get_project_client()
• Add labels for triage (bug)
• Implement fix: add project and project_id parameters to fetch tool, pass to read_note
• Add test: test_fetch_forwards_project_parameters verifies params are forwarded correctly
• Commit and push changes

---

Fix Summary

Root cause: fetch in chatgpt_tools.py called read_note(identifier=id, context=context) without forwarding any project routing — so it always resolved against the default project.

Change: Added project: Optional[str] = None and project_id: Optional[str] = None to fetch's signature and forwarded them to read_note, matching the interface of read_note, read_content, and view_note.

Files changed:

• src/basic_memory/mcp/tools/chatgpt_tools.py — added project/project_id params, forwarded to read_note
• tests/mcp/tools/test_chatgpt_tools.py — added test_fetch_forwards_project_parameters

Triage: Bug · Medium priority · MCP tool component · Simple fix

[groksrc]

Took a closer look — adding project/project_id to fetch isn't the right fix, even though it's the most direct read of the issue title.

Why: OpenAI's compatibility schema for fetch is strict — fetch(id: str) -> FetchResult, single param. See openai/sample-deep-research-mcp and the Building MCP servers for ChatGPT docs. The whole reason chatgpt_tools.py exists as a separate adapter (vs. just exposing read_note) is to mirror that exact shape — its module docstring even calls this out. ChatGPT will never call fetch with project_id; it only ever passes back an id it got from search. So a wider schema only helps humans typing into MCP clients directly (which is the repro in this issue, but not the production path).

Real root cause is in search, not fetch. _format_search_results_for_chatgpt (chatgpt_tools.py:47-52) returns id = permalink — a bare permalink with no project disambiguation. When two projects have overlapping namespaces (the repro: Personal/getting-started and drew-cain/getting-started), the IDs collide and fetch resolves against the default project.

Proposed fix: make search return project-qualified IDs (e.g. memory://<project>/<permalink> or <project_id>:<permalink>) and have fetch parse the project out of id before delegating to read_note. ChatGPT keeps working unchanged; cross-project routing Just Works; the strict OpenAI schema is preserved.

This is almost certainly the same root cause as #783 (workspace-disambiguated permalinks, teams blocker) — likely worth fixing together.

Closing the claude/issue-782-20260503-0116 branch since the param-forwarding approach there isn't the direction we want.

[groksrc]

Related thought tracked in #786: if we exposed a settings (or session/set_active_project) MCP tool, the LLM could establish project/workspace context out-of-band — so even tools with strict input schemas like fetch(id: str) could route to the right project without violating OpenAI's compatibility contract. That's a complement to the project-qualified-ID fix proposed above, not a replacement: qualified IDs handle the per-call case, settings handle the conversational-context case.

[phernandez]

I think if we make the permalink fix to include the workspace it would solve this issue, right, @groksrc ?

[groksrc]

Yes it will, let's close this once we ship that feature.