MCP Marketplace: collegare strumenti esterni al vostro agente AI

Perché un agente ha bisogno di porte, non solo di una stanza

L'agente ReAct al cuore di Simmetric Chat sa già ragionare e agire: cerca nella vostra base di conoscenza con l'RAG ibrido, scrive nella memoria del workspace ed elabora documenti. Ma un agente chiuso dentro le proprie skill è un sistema chiuso. Il Model Context Protocol (MCP) è lo standard aperto che lo trasforma in un sistema aperto - un protocollo condiviso attraverso cui un assistente AI può scoprire e chiamare strumenti esterni, e attraverso cui gli strumenti esterni possono raggiungere le capacità dell'assistente stesso.

La storia MCP di Simmetric Chat è bidirezionale. In uscita, il vostro agente si collega a server MCP esterni e ne acquisisce gli strumenti come skill. In ingresso, la piattaforma può esporre la propria conoscenza RAG ad altri client MCP, come gli assistenti negli IDE. Questo articolo copre il lato in uscita da capo a fondo: il marketplace, le connessioni e i controlli che decidono cosa il vostro agente può davvero raggiungere in una data conversazione.

Il marketplace: un catalogo curato di server di strumenti

Gli amministratori raggiungono il marketplace dalla barra laterale - la voce è riservata agli admin, perché installare un server di strumenti gli apre un varco nelle conversazioni del workspace. Il catalogo presenta i server MCP disponibili come schede con i dettagli che contano prima di un'installazione:

• Badge di categoria - i server sono raggruppati per dominio (strumenti per sviluppatori, database, comunicazione e altro), con pillole di categoria che filtrano la griglia. Le categorie sono generate dai dati del catalogo, quindi i filtri riflettono ciò che esiste davvero.
• Livelli di verifica - i server official provengono da maintainer riconosciuti, i verified_community sono stati revisionati, e le voci unverified sono elencate ma non vagliate. Il livello è sulla scheda, così il livello di fiducia è visibile prima del clic.
• Stato di salute - l'endpoint di ciascun server viene sondato in un ciclo di 30 minuti, e la sua scheda mostra se al momento è healthy, stale o down, più la data dell'ultimo commit per giudicare se il progetto è mantenuto attivamente.
• Elenco strumenti - ogni strumento esposto dal server, con nome e descrizione, compare nella pagina di dettaglio prima che installiate qualsiasi cosa.

Una barra di ricerca filtra il catalogo per nome o descrizione in tempo reale. Nulla di tutto ciò passa per un intermediario cloud che non potete ispezionare: il catalogo è un insieme di endpoint, e i badge di salute vi dicono quali sono vivi adesso.

Installazione in un clic, con scope sul workspace

Installare un server è un solo clic dalla scheda o dalla sua pagina di dettaglio, con un prerequisito: deve essere selezionato un workspace, perché ogni connessione MCP ha scope su un workspace. Dietro il clic, il sistema crea un record di connessione con il nome predefinito del server, tenta subito la connessione e registra gli strumenti scoperti nel registro delle skill dell'agente.

Ciò che ottenete è l'unione delle connessioni del workspace: ogni server MCP abilitato e connesso contribuisce con i suoi strumenti all'agente. La connessione viene creata anche se il server non è raggiungibile al momento dell'installazione - arriva marcata disconnected, e potete correggerne URL o transport dalle impostazioni di connessione e ritestarla.

La disinstallazione è l'inverso deliberato: elimina il record di connessione, chiude la connessione runtime e deregistra tutti i suoi strumenti. L'azione è distruttiva - la configurazione viene rimossa, non soft-deleted - che è il comportamento onesto per una superficie di permessi così potente.

Gestire le connessioni nelle impostazioni

Ogni connessione, installata dal marketplace o creata a mano, vive in Impostazioni → Connessioni MCP. La tabella mostra il nome visualizzato, l'URL del server con il suo transport, un punto di stato live e un interruttore abilita/disabilita:

• Transport. Sono supportati due tipi di connessione: Server-Sent Events (sse) e streamable HTTP (streamable-http). La modifica di una connessione può cambiare URL, nome o transport, e modificare una connessione abilitata innesca una riconnessione automatica.
• Stato live. La tabella interroga i server ogni 30 secondi: verde per connesso, grigio per disconnesso, rosso per errore. Un'azione Test disconnette, riconnette e riporta il numero di strumenti scoperti - con un timeout di 10 secondi, così un endpoint morto vi costa dieci secondi, non un pomeriggio.
• Abilitare contro disabilitare. La disabilitazione chiude la connessione runtime e deregistra gli strumenti mantenendo la configurazione nel database, così un'integrazione stagionale può essere spenta senza cancellare nulla.

Per i casi di mismatch di transport nel mondo reale, il client ricade con senso: una connessione configurata per streamable HTTP che risponde con un 4xx ritenta come SSE, mentre una connessione dichiarata esplicitamente sse resta su SSE.

Pinning per chat: privilegio minimo per le conversazioni

L'abilitazione a livello di workspace è un pennello largo. Il controllo fine è il pinning per chat, disponibile dal pannello console accanto a ogni conversazione: un menu a discesa elenca le connessioni MCP del workspace con un punto di stato e un interruttore per ciascuna.

Fissate (pin) una connessione per renderla il set di strumenti deliberato di quella chat - utile per conversazioni focalizzate, discussioni sensibili o per testare come si comporta l'agente con un sottoinsieme specifico di strumenti. Il modello di pinning è strettamente additivo: fissare delle connessioni non rimuove mai gli strumenti delle altre connessioni attive e connesse del workspace; togliere tutti i pin riporta all'unione predefinita di tutte le connessioni abilitate. I pin sopravvivono a ricaricamenti e riavvii, memorizzati per chat, con un interruttore ottimistico che ritorna allo stato precedente e segnala un errore se la persistenza fallisce.

Il risultato è un modello a privilegio minimo per gli strumenti dell'agente: il workspace decide cosa esiste, gli interruttori di connessione decidono cosa è generalmente disponibile, e ogni chat decide cosa può raggiungere quella specifica conversazione.

La direzione in ingresso: esporre l'RAG via MCP

Lo stesso protocollo gira anche al contrario. La piattaforma può fare da server MCP, esponendo la ricerca RAG ibrida sulla propria base di conoscenza così che client MCP esterni - gli assistenti negli IDE sono l'esempio canonico - possano ancorare le loro risposte alla vostra conoscenza curata e protetta da RBAC. I vostri documenti restano dove sono; l'assistente dell'IDE chiama, riceve risultati di ricerca con citazioni e non ha mai bisogno di una copia del corpus.

Questo trasforma la base di conoscenza in infrastruttura: gli stessi documenti indicizzati servono il workspace di chat interno e qualunque strumento MCP-aware che il vostro team usa già, con le stesse regole di accesso applicate al confine.

Dove gli strumenti girano nel ciclo dell'agente

Gli strumenti MCP entrano nell'agente come skill di prima classe. Quando l'orchestratore ReAct è in esecuzione, gli strumenti forniti via MCP stanno accanto alle skill integrate - ricerca nella base di conoscenza, memoria del workspace, elaborazione dei documenti - e l'agente decide a ogni turno se una chiamata a un tool aiuta a rispondere. I nomi degli strumenti sono racchiusi per namespace per connessione così gli identificatori non collidono mai, e ogni evento in streaming che riferisce uso di strumenti porta il nome sorgente leggibile, così la traccia di attività della chat mostra quale connessione ha servito quale chiamata.

I controlli di salute sulle connessioni installate girano come job pianificati attraverso la coda basata su Postgres della piattaforma, così un marketplace che diventa stale viene notato dall'infrastruttura e non dagli utenti. L'intera superficie - catalogo, connessioni, pinning - è protetta dall'RBAC della piattaforma: gate admin su marketplace e gestione delle connessioni, e il pinner per chat resta dentro la superficie di chat che gli utenti hanno già.

Per iniziare

1. Aprite il marketplace dalla barra laterale (ruolo admin) e scegliete un server verificato i cui strumenti corrispondano a un flusso di lavoro reale.
2. Selezionate un workspace, installate e confermate che il punto di stato diventi verde.
3. Aprite una chat, verificate che lo strumento compaia nel pannello console e fissatelo se quella conversazione deve restarvi limitata.
4. Fate una domanda che richieda lo strumento - la traccia di attività dell'agente mostra la chiamata, la sua sorgente e il suo risultato.

I server MCP esterni sono solo server: eseguitene uno sulla vostra infrastruttura, puntate una connessione su di esso, e la superficie di capacità del vostro agente cresce senza alcuna modifica di codice alla piattaforma.

Leggi la guida completa nella documentazione →