mcp-current-repo

⚠️ Superseded. SEP-2577 deprecated MCP Roots — the mechanism this repo uses to carry project identity — citing vague semantics and overlap with tool parameters and server configuration. The successor is mcp-project-context, which carries the same identity through tool-parameter injection instead (the surface the SEP itself named as the alternative). Kept here as a record of the Roots-based approach and why it didn't hold up.

Give an MCP server "current-project" focus — so it stops doing the "list every repo and guess" dance — without giving it filesystem access.

The host already knows what project you're in. The protocol can carry that. The server never needs to touch your disk.

A working proof of the path @SamMorrowDrums suggested on github/github-mcp-server#1683:

"I have often considered allowing for a repo-specific version… I think the host application would need to do it with a roots-like MCP protocol support. We don't have local folder access so unlike GH we cannot access files to determine current repo directly."

The problem (#1683 / #1308)

Ask a GitHub-connected agent to "show this project's issues" and it wanders: list_repositories → enumerate every repo → guess the current one → maybe ask you. Slow, scattered, and it burns context the model needs for the actual task.

Related MCP server: epik-gh

The fix

current repo            HOST (MCP client)               SERVER
(derived by the   ──▶ puts it in a root  ──roots/list──▶ reads the root,
 host)                                      (protocol)    auto-scopes the tool
                                                          — never reads a file

The host has the project context; it passes the repo identity over MCP roots; the server auto-scopes every tool. No exploration phase, no filesystem access on the server.

Before / after (actual output of npm run demo)

BEFORE — plain workspace root, no project context
· no owner/repo in the call → requesting roots/list from the host…
· host returned 1 root(s): workspace
⛔ No project scope available.
   A real agent now does the 'search-first-then-locate' dance:
   → list_repositories (enumerate every repo) → guess the current one → maybe ask the user.

AFTER  — host carries the current repo via the root name
· no owner/repo in the call → requesting roots/list from the host…
· host returned 1 root(s): faf:repo=github.com/octocat/Hello-World
✅ Scoped to octocat/Hello-World  (no fs, no exploration)
   No exploration phase. The server read NO files.

The finding worth knowing (a 20-min spike)

The MCP TypeScript SDK currently hard-enforces file:// on root URIs:

// @modelcontextprotocol/sdk — types.js
RootSchema = z.object({
  uri: z.string().startsWith('file://'),  // "This *must* start with file:// for now."
  ...
})

So you cannot pass https://github.com/owner/repo as a root URI today — it's rejected. This demo therefore carries the repo identity in the root name. That points at a small, concrete ask for the spec/SDK: relax the roots URI constraint (a typed repo:// / project-context root), so identity doesn't have to ride in a free-text name.

What a server would add (minimal)

1. On a tool call without owner/repo, call roots/list (the SDK already supports this).

2. Read the project root the host provides.

3. Use it as the default scope. Done — no exploration, no fs access.

Where the current repo comes from

The host has to derive the repo somehow. This demo reads a project.faf — a typed, portable context file you own (IANA-registered as application/vnd.faf+yaml) — which already carries the project's identity in one field. It's a clean source because the file is the scope and travels with the repo.

But the mechanism is source-agnostic: derive the repo from .git, an env var, an IDE workspace setting — whatever the host knows. The roots path is the same; project.faf is just one tidy way to feed it.

Run it

npm install
npm run demo

MIT. A stub for discussion, not a fork.