canonical-vault-mcp-server

Read-only MCP-Server, der das GitHub-Repo canonical-vault für jeden MCP-Client bereitstellt — GitHub Copilot, Claude oder alles andere, das Streamable HTTP MCP spricht.

Fünf Tools, alle schreibgeschützt, alle beschränkt auf kushkillerjsixx66/canonical-vault:

In diesem Server gibt es absichtlich keine Schreib-Tools — nichts hier kann committen, pushen oder das Vault verändern.

1. Auf Vercel bereitstellen

npm install -g vercel   # if you don't have it
cd canonical-vault-mcp-server
vercel login
vercel

Übernimm die Standardeinstellungen (Vercel erkennt api/mcp.ts automatisch als Node-Serverless-Funktion). Nach vercel --prod erhältst du eine URL wie:

https://canonical-vault-mcp-server.vercel.app

Dein MCP-Endpunkt ist:

https://canonical-vault-mcp-server.vercel.app/api/mcp

Umgebungsvariablen (festlegen im Vercel-Dashboard → Settings → Environment Variables)

Nach dem Hinzufügen der Umgebungsvariablen erneut bereitstellen (vercel --prod), damit die Funktion sie übernimmt.

Related MCP server: github-mcp-tool

2. GitHub Copilot damit verbinden

Copilot (in VS Code und im Copilot-Coding-Agent) liest die MCP-Server-Konfiguration aus .vscode/mcp.json in deinem Workspace oder aus den globalen MCP-Einstellungen von VS Code. Füge Folgendes hinzu:

{
  "servers": {
    "canonical-vault": {
      "type": "http",
      "url": "https://canonical-vault-mcp-server.vercel.app/api/mcp"
    }
  }
}

Dann in VS Code: Command Palette → „MCP: List Servers“ → canonical-vault → Start. Copilot Chat erkennt die fünf vault_*-Tools automatisch und kann sie im Agent-Modus aufrufen.

Für den Remote-Coding-Agent von Copilot (nicht lokal in VS Code) kann dieselbe URL unter den MCP-Server-Einstellungen deiner Organisation auf github.com registriert werden, wo auch immer die Agent-MCP-Konfiguration von Copilot für deinen Plan liegt — dieser Teil liegt auf der Seite von GitHub, nicht auf der dieses Servers.

3. Lokales Testen (vor der Bereitstellung)

npm install
npm run build
npx @modelcontextprotocol/inspector node dist/index.js

Dies öffnet die MCP-Inspector-Oberfläche, auf der du jedes Tool manuell gegen das Live-Repo aufrufen kannst, bevor du Copilot daran anbindest.

Um den HTTP-Pfad lokal statt über stdio zu testen:

npm install -g vercel
vercel dev
# endpoint: http://localhost:3000/api/mcp

Anmerkungen zu Designentscheidungen

• Zustandsloser Transport pro Anfrage: api/mcp.ts erstellt bei jedem POST einen neuen McpServer + StreamableHTTPServerTransport. Dies ist das korrekte Muster für Serverless — Vercel-Funktionen behalten keinen Speicher zwischen Aufrufen, es gibt also keine Sitzung, die aufrechterhalten werden muss, und es vermeidet Kollisionen von Anfrage-IDs, wenn zwei Aufrufer gleichzeitig den Endpunkt treffen.

• Herkunft = Commit-Verlauf, kein maßgeschneidertes Konzept — vault_get_file_history ist wörtlich GET /commits?path=..., was die ehrlichste Abbildung von „Herkunft“ auf das ist, was die GitHub-API tatsächlich bietet. Wenn das Konzept der Herkunftskette deines Vaults (Governance/Vault-Pipeline) etwas Spezifischeres benötigt — z. B. das Lesen einer Herkunfts-Manifestdatei, die im Repo liegt —, ist es besser, vault_get_file direkt auf dieses Manifest zu richten, anstatt die Git-Historie neu zu implementieren.

• Von Natur aus schreibgeschützt, gemäß deiner Antwort — dieser Server kann nicht in canonical-vault schreiben. Wenn du später möchtest, dass Copilot committet (z. B. über einen PR), ist das ein separater Satz von Schreib-Tools mit echter Überprüfung destruktiver Aktionen, nicht etwas, das man stillschweigend anhängt.

• Einschränkung bei der Suche: Die Code-Suche-API von GitHub indexiert nur den Standard-Branch und hat eine eigene Indexierungsverzögerung — eine Datei, die vor Sekunden committet wurde, erscheint möglicherweise noch nicht in vault_search_files. vault_get_file und vault_list_directory spiegeln immer den Live-Baum wider.