Server MCP remoto in azione: un nuovo punto d'ingresso per i prodotti SaaS nell'era dell'IA
Scopri come costruire un server MCP remoto per il tuo prodotto SaaS. Condividiamo la nostra esperienza con MCP vs. Agent Skills, integrazione OAuth e progettazione degli strumenti MCP.
YijunDeveloper
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
I prodotti SaaS hanno un problema di lunga data: il time-to-value è troppo lento. Molti utenti abbandonano prima di raggiungere il momento “aha”.
Abbiamo iterato sull'onboarding di Logto diverse volte. Ha aiutato, ma il collo di bottiglia non è sparito. Finisci comunque per leggere la documentazione, scorrere i tutorial, installare SDK, configurare impostazioni, scrivere codice, poi fare debug dell'ultimo 10% prima che qualcosa funzioni.
Quindi abbiamo provato un approccio diverso: un server MCP remoto come control plane IDE-nativo di Logto. Invece di cliccare nell'admin console, configuri Logto e generi codice di integrazione tramite una conversazione, direttamente dove stai costruendo l'app.
Un prompt può portarti da zero a un'integrazione funzionante. L'agente non si limita a generare codice, crea e configura anche l'applicazione Logto sul tuo tenant. Tutto dall'interno del tuo IDE. (Prova Logto MCP Server)
In questo articolo condividerò la nostra esperienza e riflessioni sulla costruzione del Logto MCP Server, incluso:
MCP vs. Agent Skills: perché abbiamo scelto MCP
Problemi che abbiamo incontrato nel lanciare un server MCP, e come li abbiamo risolti
Come progettiamo gli strumenti MCP, e come dovresti progettare i tuoi
Prima di decidere come l'IA dovesse accedere a Logto, abbiamo valutato due opzioni: server MCP e Agent Skills.
I server MCP hanno due forme: locale e remoto.
Un server MCP locale gira sulla macchina dell'utente. Richiede installazione di servizi, configurazione dell'ambiente, credenziali, o flussi di login speciali. Nell'utilizzo e nella distribuzione, è molto simile alle skill.
Un server MCP remoto è ospitato lato server. Gli utenti si connettono tramite URL e autorizzano con OAuth. Questo modello è più vicino all'estensione di un servizio SaaS.
Da un punto di vista strutturale, una Agent Skill è una combinazione di "logica di business + capacità sottostanti". Queste capacità possono essere strumenti, CLI o chiamate API. Gli strumenti MCP possono fornire questo livello in modo unificato.
Quindi la domanda chiave non è come sono implementate le capacità, ma come vengono consegnate agli utenti.
Agent Skills consegnano: una toolchain locale completa (pacchetto Skill + runtime locale + API key o credenziali di piattaforma + strumenti CLI + flusso di installazione, configurazione, aggiornamento e manutenzione).
In sostanza, dai la capacità agli utenti affinché la gestiscano autonomamente.
I server MCP remoti consegnano: un punto d'ingresso di servizio remoto (URL + login OAuth).
In sintesi, fornisci la capacità come servizio.
Di seguito li confrontiamo sotto il profilo dell’esperienza utente, della portata dell’ecosistema, e del costo di consegna e manutenzione.
Le Agent Skills dipendono di solito da API di piattaforma o strumenti CLI. Gli utenti devono prima creare API key o installare e loggarsi nelle CLI. Questi passaggi non sono complessi, ma alzano la barriera d'ingresso.
I server MCP supportano OAuth. Gli utenti fanno login con il proprio account SaaS. L’esperienza è come "Accedi con Google".
Per gli utenti, usare un server MCP è semplice: inserisci un URL, fai login, connettiti. Questa è l’esperienza che vogliamo offrire.
Sul sito di MCP, ci sono già 104 app AI che supportano MCP, inclusi strumenti come VS Code, Cursor e Windsurf.
Le Agent Skills sono ancora specifiche per ciascuna piattaforma. Anche se molte piattaforme iniziano a supportarle, quando distribuiamo un server MCP, gli utenti possono usarlo subito. Se diffondiamo una Skill, solo gli utenti di quella piattaforma possono usarla.
MCP è incluso anche dalla Agentic AI Foundation (AAIF). È uno standard a livello di protocollo. L’ecosistema continuerà a crescere. Per noi, questo rende MCP un investimento a lungo termine valido.
Le Agent Skills dipendono da API o CLI di piattaforma, il che porta rapidamente a problemi:
Cosa succede se l’API cambia?
Cosa succede se la CLI perde compatibilità?
Come aggiorni e redistribuisci la Skill?
Devi anche distribuire le CLI, gestire credenziali sparse, adattarti a più piattaforme, e guidare gli utenti all'aggiornamento. Il ROI è molto basso.
I server MCP sono molto più semplici. Gli utenti si connettono a un URL. Punta sempre alla versione più aggiornata. Quando aggiorniamo il server MCP, gli utenti lo ottengono alla prossima connessione. Nessun aggiornamento necessario. Se le API cambiano, aggiorniamo direttamente nel server MCP.
La maggior parte dei prodotti SaaS ha già un’infrastruttura solida: API robuste e sistemi di autenticazione maturi. Un server MCP si inserisce naturalmente come “interfaccia AI” dell’API, proprio come la console admin è un’altra interfaccia sugli stessi endpoint.
Per Logto, scegliere un server MCP si adatta alla nostra architettura e sfrutta i nostri punti di forza.
Centralizza anche tutte le richieste in un unico punto d’ingresso. Log e audit sono più semplici. I permessi sono chiari: l’IA può fare solo ciò che l’utente autorizza. Questo modello è strutturalmente più pulito per scenari enterprise e di compliance.
Problemi che abbiamo incontrato nel lanciare un server MCP, e come li abbiamo risolti#
MCP non è perfetto. La maggior parte dei problemi riguarda la maturità dell’ecosistema. Miglioreranno nel tempo. Per ora, usiamo workaround per soddisfare i bisogni reali.
Con le Agent Skills, logica di business e contesto sono confezionati insieme. L’LLM sa come usarli. MCP fornisce solo strumenti. Dopo la connessione, l’LLM non sa:
Gli scenari d’uso
L’ordine delle chiamate
I vincoli di business
MCP ha il concetto di Istruzioni, ma non tutti i client lo supportano. Le Istruzioni inoltre inseriscono tutto il contenuto nel contesto al momento della connessione, sprecando token.
Un’altra idea è inserire indicazioni nelle descrizioni degli strumenti. Ma questo causa due problemi:
Le descrizioni diventano complesse. Workflow multi-strumento creano logiche ingarbugliate e difficili da gestire.
Man mano che cresce il numero di strumenti, le descrizioni consumano gran parte della finestra di contesto.
Il nostro workaround: fornire uno strumento getInstructions
L’idea è semplice: se le Istruzioni non sono ben supportate, trasformale in uno strumento.
L’LLM può chiamare getInstructions su richiesta.
Per il task A, chiama getTaskAInstructions. Il server MCP restituisce un prompt che spiega come completare il task A e come combinare altri strumenti.
La logica di business complessa resta dietro agli strumenti di istruzione. Gli altri strumenti restano semplici. Le descrizioni degli strumenti si concentrano solo sulla loro funzione.
È simile ad Agent Skills: i prompt vengono caricati su richiesta. È anche più efficiente delle Istruzioni globali, perché evita di caricare tutto nel contesto.
Per molti prodotti SaaS, alcuni segreti non devono mai essere esposti (ad esempio, client secret, API key, chiavi di firma webhook). Se trapelano, altri possono impersonarti o accedere direttamente alle risorse.
Il rischio con gli LLM è che una chat non è un canale sicuro. Le conversazioni possono essere loggate, copiate, inoltrate o finite nei log di debug. Non puoi assumere che "solo io e il modello possiamo vedere questo". Consegnare un segreto di lunga durata a un LLM, o chiedergli di mostrarne uno all’utente, è molto rischioso.
Questo è comune anche nelle integrazioni web classiche: gli sviluppatori spesso hanno bisogno di un segreto, lo mettono tra le variabili d’ambiente del server o nei file di configurazione, e poi completano passi come l’inizializzazione degli SDK.
Per mantenere l’onboarding semplice senza ridurre la sicurezza dei segreti, facciamo tre cose:
Usiamo segreti temporanei durante l’integrazione
Durante la configurazione via chat, il server MCP restituisce solo segreti temporanei brevissimi (ad esempio, validi 1 ora). Sono sufficienti per far funzionare l’integrazione, e spesso scadono prima di andare in produzione. Prima di andare live, gli sviluppatori creano e sostituiscono manualmente con segreti di produzione al di fuori della chat.
Rendiamo esplicito il perimetro di sicurezza
Avvertiamo chiaramente gli utenti: non creare, incollare o memorizzare segreti di produzione in chat. Ricordiamo anche che persino variabili d’ambiente o file di config possono trapelare se un agente / LLM vi accede tramite strumenti o vie indirette. Metti i segreti di produzione solo in ambienti dove non usi integrazioni AI-assistite.
Non gestire segreti di produzione in chat; guida gli utenti sulla console
I segreti a lunga scadenza non vengono generati o distribuiti in chat. Vengono creati e gestiti sulla pagina delle credenziali della console. In chat, forniamo solo un link diretto alla console così l’utente possa completare la configurazione dei segreti lì.
Logto dispone di una API di Management completa. La nostra prima idea era semplice: esporre ogni endpoint della API come strumento MCP.
Questo è fallito subito.
Prima, esplosione del contesto. Logto ha molte API. Mappare uno a uno riempie la finestra di contesto. Ogni descrizione dello strumento costa token.
Secondo, perdita di significato. Le API sono blocchi costruttivi atomici per sviluppatori. Ma gli utenti del Logto MCP Server non stanno costruendo sistemi. Vogliono solo completare task. Non interessa loro quante API esistono.
Esempio: Logto ha una API sign-in-experience per branding, metodi di accesso, iscrizione e policy di sicurezza.
All’inizio ci chiedevamo come esporre tutti i parametri all’LLM. Come insegnargli a combinare le chiamate.
Ma è la mentalità sbagliata. Gli utenti non stanno chiamando le API. Vogliono cambiare il branding o configurare i metodi di login.
Quindi gli strumenti devono essere updateBranding, updateSignInMethod, updateSignUpMethod. Il server MCP compone internamente le chiamate API.
Il Logto MCP Server deve essere trattato come un prodotto, non come semplice wrapper di API. È "un’altra admin console".
Se gli utenti usano direttamente il tuo servizio (come una console), gli strumenti devono essere orientati al business.
Se fornisci capacità di base su cui altri costruiscono, tieni gli strumenti atomici e semplici. Esempio: un server MCP filesystem con read_file, write_file, poi gli agenti di coding li combinano.
Altri principi:
Mantieni la logica degli strumenti e le descrizioni semplici per risparmiare contesto.
Per workflow complessi, usa strumenti getInstructions per caricare indicazioni su richiesta. Mantieni anche le loro descrizioni semplici.
A volte i server MCP devono fornire non solo strumenti ma anche indicazioni su come combinarli in task, come fanno le Agent Skills.
Questo è frequente nei SaaS. Per esempio, GitHub MCP Server, Logto MCP Server, piattaforme di analytics. Gli utenti vogliono workflow, non chiamate atomiche.
Lo strumento getInstructions è un workaround. Un supporto a livello di protocollo sarebbe meglio.
I client si collegano a molti server MCP, ma non tutte le sessioni hanno bisogno di tutti. L’attivazione/disattivazione a livello sessione potrebbe ridurre lo spreco di contesto.
Isolamento del contesto per le chiamate agli strumenti MCP#
Le chiamate agli strumenti consumano molto contesto. Se le interazioni MCP sono gestite da sub-agenti, la conversazione principale potrebbe ricevere solo risultati condensati.
Questa è la nostra esperienza nella costruzione di un server MCP remoto.
Se stai esplorando questa direzione, prova il Logto MCP Server o unisciti al nostro Discord per scambiare esperienze di implementazione reale con la community.
Condivideremo anche dettagli sull’architettura e sul flusso OAuth in futuri articoli.
