Auch auf: English, Español, Português, 日本語, Français, 한국어, 简体中文, Italiano, हिन्दी · Alle Anleitungen auf Deutsch

Offenlegung: Wir entwickeln Carbon Forge bei 100monkeys.ai, lesen Sie dies also als Bericht des Herstellers. Einer unserer KI-Agenten hat diese Anleitung entworfen, und das Unternehmen hat sie geprüft; diese deutsche Ausgabe ist eine Übersetzung der englischen Originalanleitung. Die Carbon-Forge-Schritte zitieren die öffentliche Doku, auf Englisch mit der Übersetzung daneben; die Konfiguration jedes Clients ist aus dessen eigener Dokumentation kopiert und daneben verlinkt. Der letzte Abschnitt listet auf, was die Doku nicht beantwortet.

Was Sie bauen

Ein Workspace, mehrere Clients, je ein Token. Der Carbon-Forge-Server spricht Streamable HTTP, "binds every call to a workspace via a bearer token" (bindet jeden Aufruf über ein Bearer-Token an einen Workspace), und "tools honor the cap exactly as a human session does: there is no agent-only privilege" (Tools halten die Obergrenze genau wie eine menschliche Sitzung ein: Es gibt kein Privileg nur für Agenten) (MCP overview). Jeder Client, der einen HTTP-Header senden kann, kann sich verbinden. Claude Code hat eine eigene Anleitung: Claude Code per MCP mit Carbon Forge verbinden.

Schritt 1. Ein Token pro Client erzeugen

Melden Sie sich unter carbonforge.dev/login an, öffnen Sie die Einstellungen, wählen Sie API tokens, den Workspace, eine Rollenobergrenze und einen Tool-Scope, und "name the token after the agent or environment that will hold it" (benennen Sie das Token nach dem Agenten oder der Umgebung, die es halten wird) (MCP tokens). Ein Token pro Client heißt: Das Audit-Log, das "every tool call ... under the token identity" (jeden Tool-Aufruf unter der Token-Identität) festhält, sagt Ihnen, welches Tool was getan hat, und Sie können eines widerrufen, ohne die anderen anzufassen.

Wählen Sie Scopes nach Aufgabe (MCP token scopes): Basic LLM memory für einen Assistenten, der Notizen führt, Read-only memory oder SCM reader für einen, der nur liest, SCM agent für einen, der Code auf Lanes schreibt. Die Doku rät: "Default to the narrowest preset that still covers what the client needs." (Nehmen Sie standardmäßig das engste Preset, das noch abdeckt, was der Client braucht.)

Schritt 2. Jedes Token in einer Umgebungsvariablen halten

Das Geheimnis "is shown once, then only the prefix." (wird einmal angezeigt, danach nur noch das Präfix.) Beide Clients unten können es aus der Umgebung lesen, sodass es nie in einer Konfigurationsdatei landet, die in einem Commit endet:

export CARBON_FORGE_TOKEN=‹token for this client›

Schritt 3. Cursor konfigurieren

Cursor liest MCP-Server aus mcp.json: ~/.cursor/mcp.json für alle Projekte oder .cursor/mcp.json in einem Projekt. Ein entfernter Server nimmt url und headers, und Cursor löst ${env:NAME} in beiden auf (MCP-Doku von Cursor):

{
  "mcpServers": {
    "carbon-forge": {
      "url": "https://carbonforge.dev/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:CARBON_FORGE_TOKEN}"
      }
    }
  }
}

Schritt 4. Codex konfigurieren

Codex speichert MCP-Server in ~/.codex/config.toml oder in .codex/config.toml in einem vertrauenswürdigen Projekt. Ein Streamable-HTTP-Server nimmt url, und bearer_token_env_var nennt den "environment variable name for a bearer token to send in Authorization" (Namen der Umgebungsvariablen für ein Bearer-Token, das in Authorization gesendet wird) (MCP-Doku von Codex):

[mcp_servers.carbon_forge]
url = "https://carbonforge.dev/api/mcp"
bearer_token_env_var = "CARBON_FORGE_TOKEN"

Schritt 5. Jeden anderen MCP-Client konfigurieren

Für Claude Desktop sagt die Carbon-Forge-Doku: "add an MCP server entry pointing at the instance URL with the token in the Authorization header." (fügen Sie einen MCP-Server-Eintrag hinzu, der auf die Instanz-URL zeigt, mit dem Token im Authorization-Header.) Für IDE-Plugins: "point the plugin at the same MCP endpoint; Streamable HTTP works over plain HTTPS." (richten Sie das Plugin auf denselben MCP-Endpunkt; Streamable HTTP funktioniert über einfaches HTTPS.) Welches Dateiformat der Client auch nutzt, dies sind die drei einzutragenden Werte:

Endpoint:  https://carbonforge.dev/api/mcp
Transport: Streamable HTTP
Header:    Authorization: Bearer ‹token for this client›

Schritt 6. Jeden Client mit cortex.ground prüfen

Lassen Sie jeden Client cortex.ground aufrufen. Es liefert "the calling identity, what the bearer can do, what is reachable" (die aufrufende Identität, was der Bearer darf, was erreichbar ist) (cortex.ground). Vergleichen Sie die Antworten: Jeder Client sollte denselben Workspace und die Fähigkeiten zeigen, die sein Scope erlaubt. Ein Client mit falschem Token wird abgewiesen; laut Doku wird ein ungültiges Token "refused outright rather than quietly treated as anonymous" (sofort abgelehnt, statt stillschweigend als anonym behandelt).

Schritt 7. Den Workspace bei jedem Aufruf nennen

Jedes Token merkt sich seinen eigenen aktuellen Workspace, also "every agent has its own active workspace and they do not collide" (hat jeder Agent seinen eigenen aktiven Workspace, und sie kommen sich nicht in die Quere) (MCP token scopes). Das heißt auch, dass zwei Clients still auf verschiedene Workspaces zeigen können. Weisen Sie jeden Agenten an, bei jedem Aufruf workspace zu übergeben; die Tools akzeptieren es, und der Zeiger bewegt sich nie.

Schritt 8. Jedem schreibenden Agenten eine eigene Lane geben

Gemeinsame Notizen sind Seiten; gemeinsamer Code ist, wo Clients kollidieren. In Carbon Forge öffnet ein Agent eine Lane statt zu klonen: "A lane costs nothing to open and holds no copy, so one per task, or one per agent, is the expected use" (eine Lane kostet beim Öffnen nichts und enthält keine Kopie, also ist eine pro Aufgabe oder pro Agent der vorgesehene Gebrauch) (Working in lanes). Carbon Forge führt Text nie selbst zusammen; ein Patch, der nicht mehr passt, kommt als benannter Konflikt zurück, und eine Landung ist ein Changeset, alles oder nichts. Der Agent von Cursor und Codex können am selben Trunk arbeiten, ohne stillen Merge zwischen ihnen.

Was die Doku nicht beantwortet

Keine clientspezifische Konfiguration. Die Carbon-Forge-Doku nennt Claude Desktop und IDE-Plugins in je einem Satz und gibt keine Datei für Cursor oder Codex an; die Ausschnitte oben stammen aus der Doku von Cursor und Codex.
Der Endpunkt für eine Instanz auf eigenem Host oder eigener Domain wird nicht genannt; https://carbonforge.dev/api/mcp ist der, den die Doku nennt.
How MCP works zeigt einen curl-Aufruf an /mcp, während die Seite zum anonymen Zugriff /api/mcp nutzt.
Ob Tokens von selbst ablaufen, wird nicht gesagt; wie man eines widerruft, schon.
OAuth-Anmeldung für MCP-Clients wird nicht erwähnt; die dokumentierte Methode ist ein Bearer-Token.

Cursor, Codex und jeden MCP-Client mit einem Carbon-Forge-Workspace verbinden