Bidirektionales MCP: der Marktplatz und der freigelegte RAG

Der Assistent, der den Werkzeugen halbwegs entgegenkommt MCP hat zwei Richtungen, und die meisten Integrationen erzählen nur eine

MCP hat zwei Richtungen, und die meisten Integrationen erzählen nur eine. In der Connect-Richtung holen Sie EXTERNE MCP-Server in das Workspace, und ihre Tools werden in Chats aufrufbar - ohne Code, ohne Redeploy. In der Expose-Richtung stülpt sich Simmetric Chat um: ein eingebauter MCP-Server bedient die RAG-Suche des Workspace an EXTERNE Clients - Ihre IDEs, dort wo Ihre Entwickler ohnehin arbeiten.

Dieser Artikel geht beide Richtungen durch plus die Kontrollflächen, die sie betriebs sicher machen: den Install-Ablauf per Marktplatz, die manuellen Verbindungen, das Pinning pro Chat, den Transport-Fallback, und die Gesundheitschecks.

Die Schreib-Arme des Marktplatzes sind Admin-gebunden (Stöbern reicht ein Angemeldeter). Fakten: FACT-CENSUS.md F-MCP-1.

Die Connect-Richtung: der Marktplatz

Der MCP-Marktplatz ist ein kuratierter Katalog externer MCP-Server. Durchstöbern (Liste + Detail) reicht die Anmeldung; die Schreib-Arme - Einträge anlegen und in ein Workspace installieren - sind nur dem Admin. Der Install-Ablauf ist atomisch und in sich geschlossen:

1. Das Schema validiert den Install-Payload (ein Workspace + optionale Name/Header-Überschreibung - die Header passieren einen Schreib-seitigen Blocklist-Check, der Hop-by-Hop-Schlüssel verwirft, eine Namens-Regex erzwingt, und Größen deckelt).
2. Der Eintrag muss existieren (404) und darf in diesem Workspace nicht schon installiert sein (409).
3. Die workspace-scoped Verbindungszeile entsteht mit URL und Transport des Katalogs.
4. Das Ereignis landet im Audit-Log (mcp.installed), und der Konnektor läuft fire-and-forget an: ein Connect-Fehler wird protokolliert, nie still in einen „gesunden“ Zustand geschluckt.

Die Deinstallation ist das Inverse: Die Tool-Registrierungen fallen, die Verbindung hart-gelöscht, und der Audit-Eintrag landet (mcp.uninstalled). Die Installation bleibt so rückholbar mit null Rest.

Externe Tools werden Agent-Skills

Ist verbunden, registriert sich das Tool jedes externen Servers kollisionsfrei in der Skill-Registry des Agenten (mcp_<verbindung>_<tool>). Die Registry löst je Chat auf:

• Ohne Pins - jede aktivierte Verbindung des Workspace leiht ihre Tools.
• Mit Pins - nur die gepinnten UND aktivierten UND im Scope; der Pinsatz kann niemals Tools NEHMEN (er fügt nur hinzu - die strenge Vereinigung mit den workspace-scoped Tools bleibt).

Das Pinning pro Chat ist das Lenkrad des Betriebs: Ein Compliance-Chat spricht mit genau den Tools, die er darf - ohne den Rest des Workspace anzufassen.

Die Expose-Richtung: die IDE erreicht den RAG

Der eingebaute MCP-Server legt das Retrieval der Plattform an externe Clients frei:

• `rag_query` - durchsucht die Dokumente des Workspace (die belegte, zitierte Suche, die der interne Chat nutzt).
• `list_workspaces` - der Entdeckungsarm auf der Client-Seite.

Der Transport ist der zustandslose Streamable-HTTP-Endpoint (die gegenwärtige MCP-Core-Revision, nur-JSON-Antworten); der legacy SSE-Transport bleibt mit einer Abklingfrist. Die Authentifizierung hat zwei Formen: mit gesetztem MCP_API_KEY eine Bearer-Prüfung (fehlt oder falsch = 401); ohne fällt der Server auf nur-Loopback zurück - entfernte Aufrufer bekommen 401 statt unbeauthentifizierten Zugang. Die IDE-Geschichte: Der Editor Ihrer Entwickler erreicht dieselbe fundierte Dokumentensuche, die der Chat erreicht - die Knowledge Base ist ein Korpus mit vielen Türen.

Die Betriebsgüter

Drei Mechanismen halten beide Richtungen betriebsfähig statt nur eingeschaltet:

• Transport-Fallback - eine als streamable deklarierte Verbindung fällt bei einer 4xx-Ablehnung auf SSE zurück (nie bei einem 5xx - ein Serverfehler darf den Transport nicht still verschlechtern); eine als SSE deklarierte Verbindung bleibt SSE.
• Gesundheitschecks - ein pg-boss-Cron fährt alle 30 Minuten über die installierten + aktivierten Verbindungen, pingt mit exponentiellem Retry, und folgt einer Status-Leiter (gesund → stale ab den ersten Fehlschlägen → down ab dem dritten) mit den Fehlerdetails je Verbindung.
• Der Verbindungs-Mutex + die Status-Map - connect/disconnect serialisieren je Verbindung; die lebenden Status kommen aus dem Lauf, nicht aus der Datenbank, sodass ein „Test“ die Wahrheit des Augenblicks spiegelt.

Die Audit-Klasse

Jede Marktplatz- und Verbindungsmutation schreibt ins Ereignis-Log (mcp.installed / mcp.uninstalled / die CRUD-Arme) - das unveränderliche Aktivitätsregister der Plattform trägt die Fläche (per F-AUDIT-1), im Einklang mit der Bedienergeschichte des Rests der Plattform.

Weiterlesen

Die Anleitung trägt die komplette Referenz - die Katalogfelder, install/uninstall, die Pinning-Semantik, die Transporte auf der Expose-Seite - unter /de/docs/mcp-marketplace:

• MCP Marketplace - die Anleitung
• Der ältere Beitrag zum ersten Schnitt des Marktplatzes: /de/blog/mcp-marketplace
• Fakten dieses Beitrags: Zeilen FACT-CENSUS.md F-MCP-1 (bidirektionales MCP + der Marktplatz) und F-AUDIT-1 (das Ereignisregister)

Provenance: Simmetric Chat docs/MCP_MARKETPLACE.md + packages/server/src/agent/mcpServer.ts/mcpClient.ts (die Transporte + der Fallback), services/mcpHealthCheckJob.ts, CHANGELOG.md v0.28.1 - am vom Census fixierten Dokumentenstand (SHA aca5b8ff).