Wie MCP einem KI-Agenten hilft
Kontext, Gedächtnis über Sitzungen hinweg und sichere Änderungen: was ein Agent aus deinem Workspace bekommt.
Ein KI-Coding-Agent wie Claude Code oder Codex kennt deinen Code. Wofür der Code da ist, weiß er nicht: die Spec in deinen Dokumenten, den Task, der sagt, was blockiert ist, das Release-Datum, die Requests, mit denen du testest. Mit dem MCP-Server von Apiboo verbunden, kann er all das lesen, sich fürs nächste Mal merken, was er gelernt hat, und Änderungen machen, die du siehst und prüfen kannst, innerhalb der Berechtigungen, die du setzt.
Kontext: was der Agent lesen kann
| Aus | Der Agent erfährt | Berechtigung |
|---|---|---|
| Documents | Deine Specs, Notizen und Entscheidungen. Dokumente werden auch als Ressourcen mit ihrer letzten Änderung angeboten, damit der Agent die neuesten zuerst liest. | Documents, read |
| Boards | Was in Arbeit ist, was blockiert ist und in welcher Reihenfolge | Boards, read |
| Calendar | Deadlines und Release-Daten, in deiner Zeitzone | Calendar, read |
| Collections | Deine Requests, Ordner und Environments (ohne geheime Werte) | Collections, read |
| Graph | Wie alles zusammenhängt, auch die Verbindungen, die du gezeichnet hast | Graph, read |
Ein guter erster Schritt für einen Agenten ist der Graph: graph_project liefert ein ganzes Projekt mit allem, was eine Verbindung darum herum liegt, sodass der Agent sieht, welche Dokumente, Tasks und Requests zusammengehören, bevor er etwas anfasst. Die Verbindungen, die du gezeichnet hast (covers, depends on, documents), nimmt er als deine Absicht. Siehe Der Graph für KI-Agenten.
Gedächtnis über Sitzungen hinweg
Ein Agent vergisst alles, wenn seine Sitzung endet. Agent notes ändern das:
- Die Notizen liegen im Ordner Agent Notes in deinen Dokumenten, einem normalen Ordner, den du öffnen, lesen, bearbeiten und löschen kannst.
- Ein Agent liest seine Notizen zu Beginn einer Sitzung (
memory_list,memory_read) und hängt am Ende an, was er gelernt hat (memory_append). Eine Notiz trägt das Tagesdatum als Titel, wenn sie kein Thema nennt. - Die Notizen haben eine eigene Berechtigung, Agent notes, sodass du Notizen erlauben kannst, ohne dass der Agent deine anderen Dokumente schreiben darf.
- Apiboo schreibt nie von selbst eine Notiz. Das tut nur ein Agent, den du verbunden hast, und nur, wenn du es erlaubt hast.
- Den ganzen Ordner zu leeren (
memory_purge) braucht zusätzlich den Schalter für destruktive Aktionen.
Sichere Änderungen
| Schutz | Was er bedeutet |
|---|---|
| Schalter pro Bereich | Lesen und Schreiben pro Bereich, anfangs alles aus. Allow all schaltet Lesen und Schreiben ein, aber nie den Schalter für destruktive Aktionen. |
| Schalter für destruktive Aktionen | Dokumente, Tasks, Boards, Termine oder Requests löschen und Befehle auf Servern ausführen braucht einen eigenen Schalter, der standardmäßig aus ist. |
| Kein stilles Überschreiben | Text zu ändern, den ein Mensch getippt haben könnte, braucht die Revision, die der Agent gelesen hat (expected_rev). Hast du ihn inzwischen geändert, bekommt der Agent einen conflict und liest neu. |
| Rate Limits | 240 Lese-, 60 Schreib- und 10 destruktive Aufrufe pro Minute. |
| Ein Token | Nur als Hash gespeichert und einmal angezeigt. Ein neues sperrt alle alten Clients aus. |
| Terminal-Panes | Attach Apiboo MCP gibt einem Agenten in einer Apiboo-Terminal-Pane ein eigenes, temporäres Token mit deinen Berechtigungen. Es endet mit der Pane. |
| Keine Secrets | Vault, Passwörter, Variablenwerte und Responses sind nie erreichbar. |
Alles, was ein Agent schreibt, erscheint sofort in Apiboo, an denselben Stellen wie deine eigene Arbeit, sodass du es prüfen und zurückändern kannst.
Beispiele
„Plan the release on the Bookshop board." Der Agent liest das Bookshop-Board und das Release-Dokument, legt eine Liste „Release 1.4" an, fügt pro offenem Punkt einen Task hinzu und kommentiert die, die er nicht einordnen kann. Braucht Boards read und write, Documents read.
„Write the API doc from the collection." Er liest die Requests der Bookshop-Collection (Apiboo lässt Body-Werte, Zugangsdaten und Variablenwerte weg) und schreibt ein neues Dokument mit einer Endpoint-Referenz. Braucht Collections read, Documents write.
„Diagnose why this request fails." request_diagnose prüft den gespeicherten Request: jede {{variable}}, die er nutzt, und ob sie definiert, leer, ausgeschaltet oder im gewählten Environment nicht vorhanden ist; welche Auth er wirklich nutzt; einen Body ohne passenden Content-Type; einen Body, der sich nicht parsen lässt; doppelte Header; eine URL ohne Schema. Eine Response sieht der Agent nie; reicht das nicht, fragt er dich nach Statuscode und Meldung. Braucht Collections read.
„Import the OpenAPI spec." Der Agent übergibt die Spec-Datei aus deinem Repository an spec_import: OpenAPI 3.x, Swagger 2.0, Postman, Insomnia, HAR, Bruno (einen Request oder eine aus Bruno als eine JSON- oder OpenCollection-YAML-Datei exportierte Collection), Hoppscotch oder einen Apiboo-Export, bis 5 MB, als Text (eine URL ruft er nie ab). Ein Bruno-Collection-Ordner geht nicht über MCP; importier ihn in der App. Umgebungen in einer Datei werden nie geschrieben. Er kann vorher einen Probelauf machen, der zeigt, was angelegt würde. Operationen landen in einem Ordner pro Tag. Braucht Collections write.
„Deploy the Bookshop API to staging." Mit der Terminal-Berechtigung und deiner Freigabe für jeden Befehl. Siehe Beispiel: die Bookshop API auf Staging deployen.