Claude Code kennt dein Repository sehr gut. Vom Rest des Projekts weiß es nichts: das Ticket, an dem du arbeitest, die Spec, die den Endpoint erklärt, der Request, mit dem du ihn testest, der Server, auf den er ausgeliefert wird. Also kopierst du etwas in den Chat. Ticket-Text in den Chat. Einen Token in den Chat. Einmal sogar ein Datenbankpasswort in den Chat. Spätestens bei Letzterem fangen die meisten an, nach einem besseren Weg zu suchen.
In diesem Beitrag geht es um genau diesen besseren Weg: einem Coding-Agent live Projektkontext über MCP zu geben, das Model Context Protocol, das Claude Code, Codex, Cursor und Claude Desktop alle sprechen, und dabei eine harte Grenze um Secrets zu ziehen. Wir bauen Apiboo, eine Desktop-App mit eingebautem MCP-Server, und die Beispiele nutzen ihn; die Designfragen gelten aber für jeden MCP-Server, den du anbindest.
Warum CLAUDE.md nicht reicht
Eine CLAUDE.md- oder AGENTS.md-Datei ist der richtige Ort für Regeln: wie du die Tests startest, welchen Branch du nutzt, was nie angefasst wird. Für Zustand ist sie der falsche Ort. Welche Aufgabe gerade läuft, was blockiert ist, welcher Release-Termin sich verschoben hat, was seit Dienstag in der Spec steht: Das alles ändert sich täglich, und eine Datei im Repository ist am Tag nach dem Schreiben schon veraltet. Kontext muss live gelesen werden, dort, wo das Team ihn pflegt.
Der übliche nächste Schritt ist ein MCP-Server pro Tool: einer für den Ticket-Tracker, einer fürs Wiki, einer für den API-Client. Jeder sieht nur ein Silo und handelt mit allem, was sein API-Key darf, und das ist oft alles, was der Besitzer des Keys darf. Drei Server, drei Keys, kein gemeinsames Bild und keine zentrale Stelle, an der du festlegst, was der Agent anfassen darf und was nicht.
Live-Projektkontext über einen lokalen Server
Apiboos MCP-Server läuft auf deinem eigenen Rechner unter 127.0.0.1:8762 und ist von keinem anderen Rechner aus erreichbar. Damit kann ein Agent deinen Dokumentenbaum und deine Seiten lesen (neueste zuerst), deine Boards mit Status, Priorität und Kommentaren jeder Aufgabe, deinen Kalender für einen Zeitraum und deine Collections: Ordner, Requests, Environments und woher die Authentifizierung eines Requests stammt. Die Graph-Berechtigung zeigt, wie alles zusammenhängt, und graph_project liefert ein ganzes Projekt mit allem, was einen Link entfernt liegt. So sieht der Agent, welche Dokumente, Aufgaben und Requests zusammengehören, bevor er irgendetwas anfasst.
Mit Schreibrechten kann er Dokumente anlegen und ändern, Aufgaben hinzufügen, verschieben und kommentieren, Termine erstellen sowie Requests bauen oder importieren. Agent notes geben ihm ein Gedächtnis: ein Ordner in deinen Dokumenten, den er zu Sitzungsbeginn liest und am Ende ergänzt, mit eigenem Berechtigungsschalter. Alles, was er schreibt, erscheint sofort in Apiboo, an denselben Stellen wie deine eigene Arbeit.
Die Secrets-Grenze
Die interessante Designentscheidung ist nicht, was der Agent bekommt, sondern was er nie bekommen kann. In Apiboo hat der Server keine Tools für:
- Den Vault und alles darin, gespeicherte Passwörter und API-Keys.
- Die Werte von Environment- und Workspace-Variablen: Sie kommen als "hidden" zurück.
- Request-Authentifizierung, Header-Werte außer harmlosen wie Content-Type, Body-Werte und jeden Teil einer Response.
- Datenbank-, FTP- und SSH-Zugangsdaten, deine Account-Tokens und abgefangene Mails.
- Bilder in Dokumenten und Aufgaben: Der Agent sieht "Image: name" und nie den Schlüssel, der sie öffnet.
Berechtigungen pro Bereich und eine Karte für jeden Befehl
Jeder Bereich hat einen Lese- und einen Schreibschalter, anfangs alle aus; ein Client sieht die Tools, die du nicht freigegeben hast, nicht einmal. Das Löschen von allem und das Ausführen von Befehlen auf Servern braucht einen eigenen Destructive-Schalter, den Allow all nie einschaltet. Ändert ein Agent Text, den ein Mensch getippt haben könnte, muss er die Revision mitschicken, die er gelesen hat; hast du in der Zwischenzeit etwas geändert, wird der Schreibzugriff abgelehnt und der Agent liest erneut, sodass deine Änderung nie stillschweigend überschrieben wird. Rate-Limits begrenzen ihn auf 240 Lesezugriffe, 60 Schreibzugriffe und 10 destruktive Aufrufe pro Minute.
Server sind die eine bewusste Ausnahme, die du selbst machst. Setzt du unter Terminal einen Haken bei einer SSH-Verbindung, kann der Agent auf ihr per Namen einen Befehl vorschlagen. Jeder einzelne Befehl und jeder Dateischreibzugriff wartet darauf, dass du in Apiboo auf Approve klickst, in einer Karte, die den echten Host und den vollständigen Befehl zeigt; der Agent sieht immer nur den Namen des Servers, Passwort und Schlüssel bleiben in Apiboo.
Einrichtung für Claude Code
Erzeuge unter Settings → MCP server einen Token (er wird nur einmal angezeigt; Apiboo speichert nur einen Hash) und schalte den Server ein. Dann, einmalig, in einem Terminal: claude mcp add --scope user --transport http apiboo http://127.0.0.1:8762/mcp --header "Authorization: Bearer <your token>". Starte eine neue Claude-Code-Sitzung, schalte mindestens einen Lese-Schalter ein, und die Tools erscheinen. Meldet die Sitzung Connected mit 0 Tools, liegt es fast immer an einer ausgeschalteten Berechtigung oder an einer Sitzung, die vor einer Änderung gestartet wurde.
Agents, die du aus einem Apiboo-Terminal-Pane startest, brauchen nichts davon: Ist im Terminalprofil Attach Apiboo MCP eingeschaltet, bekommen Claude Code und Codex einen temporären Token mit genau deinen aktuellen Berechtigungen, der mit dem Pane endet.
Claude Desktop, Cursor, Codex und der Rest
- Claude Desktop (sowie Claude im Web und auf dem Handy) erreicht MCP-Server aus Anthropics Cloud und kann 127.0.0.1 nicht direkt öffnen. Deshalb installiert Apiboo einen kleinen signierten Helper auf deinem Rechner; kopiere das Konfigurations-Snippet in claude_desktop_config.json und starte Claude Desktop neu.
- Cursor, Zed und jeder andere Client, der sich per HTTP verbindet, brauchen zwei Einstellungen: die URL http://127.0.0.1:8762/mcp und den Header Authorization: Bearer <your token>, in den MCP-Einstellungen des jeweiligen Clients.
- Codex verbindet sich von allein aus einem Apiboo-Terminal-Pane oder per HTTP wie die Clients oben. Cursors CLI liest Server nur aus seiner eigenen mcp.json, braucht also den HTTP-Eintrag statt Attach.
- Wenn du den Token neu erzeugst, sperrst du jeden Client aus, der noch den alten hat; beim Abmelden von Apiboo werden Token und Berechtigungen gelöscht und der Server gestoppt.
Was sich in der Praxis ändert
- Du hörst auf, Kontext hineinzukopieren. Der Agent liest Karte, Spec und Request selbst.
- Du hörst auf, Secrets hineinzukopieren. Ein Request, den der Agent schreibt, muss eine Variable verwenden und dich bitten, sie zu füllen.
- Das Board ist endlich aktuell, weil der Agent die Karte aktualisiert, wenn er fertig ist.
- Der Agent macht weiterhin Fehler. Er macht sie nur mit dem richtigen Kontext und an Stellen, die du sehen und rückgängig machen kannst.
Weiterlesen
Die vollständige Referenz findest du unter apiboo.com/docs/security-ai/mcp-server, die Sicht des Agents unter apiboo.com/docs/security-ai/mcp-agents. Wenn deine Docs und Aufgaben auch als Dateien lesbar sein sollen, lies apiboo.com/blog/api-collections-in-git.
Probier es mit deiner eigenen Arbeit aus
Öffne Settings → MCP server, erzeuge einen Token, schalte Documents read und Boards read ein und führe die oben genannte Zeile claude mcp add aus. Frag in einer neuen Claude-Code-Sitzung, was auf deinem Board gerade in Arbeit ist.
Lade Apiboo für Windows, macOS oder Linux unter apiboo.com/download herunter. Der Einstieg ist kostenlos, ohne Karte und ohne Account: Jedes Tool läuft auf deinem eigenen Rechner, und du meldest dich nur an, wenn du Sync oder ein Team willst.