[FEATURE] Add git-backed source for MCP stdio servers (with pinned refs + explicit install step)

Update Jan 18: I have since found out that this might belong [here, not sure; I've started working on a prototype]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Today, MCP “stdio” servers in Claude Code must be configured as local executables (e.g., python/node + a local path). This makes it hard to distribute a custom MCP server across a team (or even across my own machines), because every user must manually:

• find the repo
• git clone it
• run setup steps / install deps
• keep it updated
• then point mcpServers to a local file path

This is especially painful for MCP servers whose purpose is to operate on the user’s local filesystem (e.g., processing local project files). Using a remote MCP transport (HTTP/SSE) isn’t a practical substitute for these “local-first” servers.

In practice, this friction blocks adoption: people can’t just “use this MCP server” by pasting config; they have to become part-time installers/upgraders.

Proposed Solution

Add a first-class way for an MCP server config entry to be backed by a git repository (or similar “source”), and let Claude Code manage install/update safely.

Critical part of the proposal: the git-backed source should support an explicit “setup/install step” (a setup file / installer script) that Claude Code runs after clone and before launching the server. This is the missing piece that removes the need for manual onboarding steps.

Example shape (illustrative):

{
  "mcpServers": {
    "ai-agents-journal": {
      "type": "stdio",
      "source": {
        "type": "git",
        "repo": "https://github.com/<org>/<repo>.git",
        "ref": "<tag-or-commit-sha>",
        "subdir": "<optional>"
      },
      "install": {
        "command": "bash",
        "args": ["./scripts/install.sh"]
      },
      "command": "python3",
      "args": ["fastmcp_server.py"],
      "env": {}
    }
  }
}

Key UX / safety requirements:

• Require pinning to a tag or commit SHA by default (opt-in “track branch”).
• Install happens into a Claude-managed cache directory (per-user) with clear visibility of what is executed.
• First-time install prompts the user with explicit provenance (repo URL + ref) and what command(s) will run.
• Update policy (never / manual / auto) with a clear “check for updates” command.
• The “install” step should default to running an interpreted script (e.g., bash/python/node) rather than an opaque binary for security/auditability, with an explicit opt-in escape hatch if binaries are desired, so the command is human-auditable in config and in-repo, and can be gated by confirmation prompts.
• Optional org policy / user setting:
• allowlist source.repo domains/orgs
• forbid install.command outside {bash, sh, python, node} unless explicitly allowed

Non-goals:

• Not an MCP spec change; this is Claude Code-specific “installer/launcher” behavior.
• Not an auto-execute of arbitrary repo code without user confirmation.
• Not a marketplace replacement (though similar mechanics may be reusable).

Alternative Solutions

• Manual git clone + manual install steps + point mcpServers at a local path. Works, but doesn’t scale across machines/users and is easy to drift.
• Package the server so users can run it via pipx/uvx (or npx for JS). This helps, but it’s still more onerous than necessary when the only real need is “get the code + run an install script if required”, and pipx/uvx/npx/npm are Python/JS-centric whereas a git-backed MCP install should work for any language/runtime.
• Run the server remotely (HTTP/SSE). Not practical for servers whose primary job is to manipulate local files on the user’s machine.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

Example scenario:

1. I maintain a custom MCP server in a git repo that runs Python scripts locally and reads/writes local project files.
2. I want teammates (or myself on a second machine) to use it in Claude Code.
3. Today I have to write onboarding docs: clone repo, run setup, manage venv/deps, keep updated, then configure mcpServers with a local file path.
4. With “git-backed MCP server config”, a user could paste a single config entry and Claude Code would:

• clone the repo at a pinned ref
• run a defined installer (or standard packaging install)
• start the stdio server with the correct entrypoint

1. This removes a recurring source of setup failures and version drift, and makes MCP server sharing actually frictionless.

Additional Context

Related/relevant existing issues about git-based installs/updates and MCP config scope (these suggest Claude Code already interacts with git for distribution and has adjacent config/scoping requests):

https://github.com/anthropics/claude-code/issues/374
https://github.com/anthropics/claude-code/issues/11856
https://github.com/anthropics/claude-code/issues/16866
https://github.com/anthropics/claude-code/issues/17293
https://github.com/anthropics/claude-code/issues/14485
https://github.com/anthropics/claude-code/issues/18517
https://github.com/anthropics/claude-code/issues/12164
https://github.com/anthropics/claude-code/issues/16107

Several marketplace/plugin issues indicate Claude Code already performs git clone/fetch/update in some flows; this feature would reuse that machinery for MCP server distribution, with explicit pinning + consent.

Security notes:

• A git-backed installer must be explicit about what code runs, where it comes from, and how it updates (pinning + prompts). The goal here is to make a workflow users already do manually safer and more ergonomic, not to silently execute arbitrary remote code.
• One security-oriented design goal: prefer install commands that invoke readable/interpreted scripts (bash/python/node) over opaque binaries by default, so users can audit what will run; allow binaries only via explicit opt-in.