Bidirectional MCP: the marketplace and the exposed RAG

L'assistente che incontra gli strumenti a metà strada MCP ha due direzioni, e la maggior parte delle integrazioni ti racconta solo la prima

MCP ha due direzioni, e la maggior parte delle integrazioni ti racconta solo la prima. Nella direzione di collegamento (connect) porti dentro al workspace dei server MCP ESTERNI e i loro tool diventano richiamabili durante le chat - senza codice, senza ridistribuire. Nella direzione di esposizione (expose) Simmetric Chat si rivolta al contrario: un server MCP builtin serve la ricerca RAG del workspace ai client ESTERNI - i vostri IDE, dove i vostri sviluppatori lavorano già.

Questo articolo percorre entrambe le direzioni più le superfici di controllo che le rendono sicure da operare: il flusso di installazione dal marketplace, le connessioni manuali, il pinning per-chat, il transport fallback, e i controlli di salute.

Le operazioni di scrittura del marketplace richiedono l'amministratore (il browsing basta un utente autenticato). Fatti da FACT-CENSUS.md F-MCP-1.

La direzione connect: il marketplace

L'MCP Marketplace è un catalogo curato di server MCP esterni. Navigare il catalogo (lista + dettaglio) basta l'autenticazione; i rami di scrittura - creare voci e installare in un workspace - sono solo dell'admin. Il flusso di installazione è atomico e autosufficiente:

1. Lo schema valida il payload d'installazione (un workspace + un'opzionale coppia nome/intestazioni - le intestazioni passano un controllo lato-scrittura che respinge le chiavi hop-by-hop, impone una whitelist sui nomi e tira le dimensioni).
2. La voce deve esistere (404) e non deve già essere installata in quel workspace (409).
3. La riga di connessione scoped al workspace nasce con l'URL e il transport del catalogo.
4. L'evento atterra nel log di audit (mcp.installed), e il connettore parte fire-and-forget: un fallimento di connessione viene registrato, mai ingerito in silenzio dentro uno stato "sano".

Disinstallare è l'inverso: le registrazioni dei tool cadono, la connessione si elimina in modo duro, e la voce d'audit atterra (mcp.uninstalled). L'installazione resta così reversibile con zero residui.

I tool esterni diventano agent skill

Una volta connesso, ogni tool del server esterno si registra nella registry degli skill dell'agente sotto nomi senza collisioni (mcp_<connessione>_<tool>). La registry si risolve per chat:

• Nessun pin - ogni connessione abilitata del workspace presta i suoi tool.
• Con pin - solo quelle pinnate E abilitate E in scope; l'insieme dei pin non può mai TOGLIERE tool (solo aggiungere - l'unione rigorosa coi tool scoped al workspace resta).

Il pinning per-chat è il volante dell'operazione: una chat di conformità parla con esattamente i tool che deve, senza toccare il resto del workspace.

La direzione expose: l'IDE raggiunge il RAG

Il server MCP builtin espone il retrieval della piattaforma ai client esterni:

• `rag_query` - cerca nei documenti del workspace (la ricerca fondata e citata che usa il chat interno).
• `list_workspaces` - il braccio di scoperta lato client.

Il transport è l'endpoint HTTP Streamable stateless (la revisione core attuale di MCP, risposte solo-JSON); il transport SSE legacy resta con un periodo di grazia alla deprecazione. L'autenticazione ha due forme: con MCP_API_KEY impostata, un controllo bearer (manca o sbaglia = 401); senza, il server cade su solo-loopback - i chiamanti remoti ricevono un 401 invece dell'accesso non autenticato. La storia dell'IDE: l'editor dello sviluppatore raggiunge la stessa ricerca fondata sui documenti che raggiunge il chat - la knowledge base è un corpus con molte porte.

I binari operativi

Tre meccanismi tengono le due direzioni operabili anziché solo accese:

• Transport fallback - una connessione dichiarata streamable cade su SSE su un rifiuto 4xx (mai su un 5xx - un errore del server non deve degradare in silenzio il transport); una connessione dichiarata SSE-only resta SSE.
• Controlli di salute - un cron pg-boss gira sulle connessioni installate + abilitate ogni 30 minuti, pinga con tentativi esponenziali, e segue una scala di stato (sano → stale per i primi fallimenti → down dal terzo) con i dettagli del fallimento tenuti per connessione.
• Il mutex di connessione + la mappa di stato - connect/disconnect si serializzano per connessione; gli stati vivi vengono dal running, non dal database, così un "test" riflette la verità del momento.

La classe di audit

Ogni mutazione di marketplace e connessione scrive nel log degli eventi (mcp.installed / mcp.uninstalled / i rami CRUD) - il log immutabile dell'attività della piattaforma porta la superficie (per F-AUDIT-1), allineato alla storia operativa del resto della piattaforma.

Per continuare

La guida porta il riferimento completo - i campi del catalogo, i flussi di installazione/disinstallazione, le semantiche di pinning, i transport lato expose - su /it/docs/mcp-marketplace:

• MCP Marketplace - la guida
• La versione in linguaggio semplice
• Il post più vecchio sulla prima versione del marketplace: /it/blog/mcp-marketplace
• Fatti in questo post: righe FACT-CENSUS.md F-MCP-1 (il MCP bidirezionale + il marketplace) e F-AUDIT-1 (il log degli eventi)

• Richiedi una demo

Provenance: Simmetric Chat docs/MCP_MARKETPLACE.md + packages/server/src/agent/mcpServer.ts/mcpClient.ts (i transport + il fallback), services/mcpHealthCheckJob.ts, CHANGELOG.md v0.28.1 - allo stato documentale fissato dal census (SHA aca5b8ff).