Produkt · MCP-Governance
MCP verwalten — jedes Tool katalogisieren, abbilden wer was nutzt
Modul V, Capabilities. Der MCP-Client introspiziert die tools/list und resources/list jedes Servers in eine interne Registry — so erhalten Sie einen versionierten Katalog aus Servern, Skills und Tools, dazu einen Capability-Graphen, der zeigt, welcher Agent welches Tool nutzt. Die verwaltete Konfiguration bindet Ihre Secrets per Referenz ein; Secrets im Klartext gelangen niemals in den Katalog.
Im Produkt
Die Capabilities-Konsole
Ein echter Screenshot, Beispieldaten. Tabs für Server, Skills, Tools, den Capability-Graphen und verwaltete Konfigurationen. Der Verbindungsstatus wird aus realen Signalen abgeleitet; freigegebene Einträge tragen einen Content-Hash und, sofern ein Signaturschlüssel vorhanden ist, eine Ed25519-Signatur.
Was Sie verwalten
Eine Registry für jedes Tool, das Ihre Agenten erreichen können
Der MCP-Client spricht stdio und Streamable HTTP, introspiziert jeden Server und erfasst, was er vorfindet — so spiegelt der Katalog wider, was die Server tatsächlich bereitstellen, und nicht das, was eine Tabelle behauptet.
Katalog aus Introspektion
Der Client ruft tools/list und resources/list über stdio oder Streamable HTTP auf (SSE ist Legacy) und schreibt das Ergebnis in eine interne Registry. Sie erhalten einen versionierten Katalog aus MCP-Servern, Skills und Tools, mit einem Verbindungsstatus, der aus realen Signalen abgeleitet wird — nicht von Hand gepflegt.
Ein Capability-Graph
Sehen Sie, welcher Agent mit welchem Tool verbunden ist — der „wer was nutzt“-Graph im Zentrum der Konsole. Dies ist eine Nutzungskarte; sie unterscheidet sich von der Read/Read-Write-Access-Map, die eine eigenständige Oberfläche für eine andere Fragestellung ist.
Secrets per Referenz, niemals im Klartext
Die verwaltete MCP-Konfiguration bindet Ihre Secrets per Referenz ein (secret_refs). Secrets im Klartext werden niemals im Katalog gespeichert oder daraus gelesen — die Konfiguration verweist auf das Secret, sie enthält es nicht.
Annotationen sind deklariert, nicht vertrauenswürdig
MCP-Server können für ein Tool read_only_hint oder destructive_hint deklarieren. Wir stellen diese als deklariertes, nicht vertrauenswürdiges Signal des Servers dar — niemals als verbindliches Sicherheitssiegel. Behandeln Sie sie als Hinweis zur Prüfung, nicht als sicherheitsrelevante Wahrheit.
Was real ist
Katalog, Graph und verwaltete Konfiguration sind live; die vollständige MCP-RC-Reife ist in Arbeit
Wir sind präzise dabei, was der Vertrag heute garantiert und was nicht:
- Live (stabiler v1-Vertrag): der MCP-Client über stdio und Streamable HTTP, die Introspektion von tools/list und resources/list in die interne Registry, der Katalog aus Servern / Skills / Tools, der Capability-Graph und die verwaltete Konfiguration, die Secrets per Referenz einbindet. Der Verbindungsstatus wird aus realen Signalen abgeleitet.
- Freigabe und Integrität: freigegebene Katalogeinträge tragen einen Content-Hash und eine optionale Ed25519-Signatur. Ist kein Signaturschlüssel konfiguriert, erscheint ein Eintrag als „freigegeben, aber unsigniert“ — das sagen wir klar, statt eine Signatur vorzutäuschen, die nicht existiert.
- Keine vollständige Spec-Konformität: die Reife gegenüber der MCP-RC (Spec vom 28.07.2026) ist in Arbeit, und mehrere Spec-Änderungen sind noch nicht implementiert — wir behaupten keine vollständige oder aktuelle Konformität mit der MCP-Spec. Die öffentliche MCP-Registry befindet sich in der Preview und lehnt private Server derzeit ab; eine private Sub-Registry steht auf der Roadmap.
- Haltung: standardmäßig read-first und investigativ. Katalog und Graph beschreiben, was Ihre Server bereitstellen und wie Tools verbunden sind; sie verdrahten oder aktivieren nichts im Stillen um.
MCP-Governance — Fragen
Sagen mir die Annotationen read_only_hint / destructive_hint, dass ein Tool sicher ist?
Nein. Diese Annotationen werden vom MCP-Server selbst deklariert und sind daher ein nicht vertrauenswürdiges Signal — ein Server kann alles behaupten. Wir stellen sie im Katalog als deklarierten Hinweis dar, der Ihnen hilft zu entscheiden, was Sie prüfen sollten, niemals als verbindliches Sicherheitssiegel. Werten Sie eine „read only“-Annotation nicht als Beweis dafür, dass ein Tool nicht schreiben kann.
Worin unterscheidet sich der Capability-Graph von der Access-Map?
Der Capability-Graph beantwortet „welcher Agent nutzt welches Tool“ — er ist eine Nutzungskarte der Verbindungen in dieser Konsole. Die Read/Read-Write-Access-Map ist eine eigenständige Produktoberfläche, die beantwortet „welche Zugriffsstufe hat eine Identität auf eine Ressource“. Beide sind bewusst getrennt; wir vermischen das eine nicht mit dem anderen.
Werden meine Secrets im MCP-Katalog gespeichert?
Nein. Die verwaltete MCP-Konfiguration bindet Secrets per Referenz ein (secret_refs) — die Konfiguration verweist auf ein Secret, sie enthält den Klartextwert nicht. Der Katalog speichert oder liest niemals Secret-Material im Klartext.
Ist Olivares vollständig konform mit der aktuellen MCP-Spezifikation?
Noch nicht, und wir behaupten es nicht, bevor es ausgeliefert ist. Der Live-MCP-Client ist ein stabiler v1-Vertrag über stdio und Streamable HTTP (SSE ist Legacy), doch die Reife gegenüber der MCP-RC (Spec vom 28.07.2026) ist noch in Arbeit, mit mehreren nicht implementierten Änderungen. Die öffentliche MCP-Registry befindet sich in der Preview und lehnt private Server ab; eine private Sub-Registry steht auf der Roadmap.
Katalogisieren und verwalten Sie Ihren MCP-Bestand
Betreiben Sie Olivares auf Ihrer eigenen Infrastruktur, introspizieren Sie Ihre MCP-Server in einen versionierten Katalog, sehen Sie, wer mit welchem Tool verbunden ist, und halten Sie Secrets referenziert — niemals im Klartext.