Percorso di compilazione
Tratta il server MCP come un piccolo backend verificabile.
La prima versione deve essere semplice e prevedibile: un confine di processo chiaro, pochi strumenti, una configurazione prevedibile e log sufficienti a diagnosticare le chiamate dei client.
Scegli il trasporto di produzione
I server MCP desktop spesso partono da stdio. Un server MCP ospitato deve esporre un trasporto compatibile con HTTP, una route di integrità e un URL HTTPS stabile.
Definisci strumenti con compiti circoscritti
Parti da pochi strumenti che corrispondano ad azioni reali del prodotto. Per ciascuno definisci uno schema di input chiaro, validazione, timeout e formato degli errori.
Tieni le credenziali fuori dai sorgenti
Conserva chiavi dei fornitori, URL dei database, segreti dei webhook e segreti dei client OAuth come segreti Adios, poi fai riferimento a essi da adios.yaml.
Eseguilo come un’API
Aggiungi comandi di compilazione, avvio e controllo di integrità. Testa la route MCP in locale, controlla i log e assicurati che le dipendenze non funzionanti facciano fallire il controllo di disponibilità.
Distribuisci e collega i client
Distribuisci il server su Adios, associa una route o un dominio personalizzato e indirizza i client MCP compatibili all’URL di produzione.
Struttura del progetto
Tieni separati codice del protocollo, strumenti, autenticazione e configurazione di distribuzione.
package.jsonDipendenze dell’ambiente di esecuzione, script e adattatore SDK MCP.
src/server.tsServer HTTP, adattatore di trasporto MCP, strumenti e risorse.
src/tools/*.tsPiccoli handler degli strumenti con validazione degli input e timeout.
src/auth.tsControlli opzionali con token bearer, OAuth o richieste firmate.
scripts/healthcheck.jsSonda di disponibilità usata da Adios.
adios.yamlCompilazione, avvio, porta, integrità, regione e riferimenti a segreti.
adios.yaml
Distribuisci il server MCP con comandi espliciti per l’ambiente di esecuzione.
Questo esempio presuppone un server MCP in Node o TypeScript che espone un trasporto HTTP su `PORT`. Usa lo stesso schema per Python, Go o un altro ambiente di esecuzione.
name: product-mcp-server
region: de
build_cmd: npm ci && npm run build
start_cmd: node dist/server.js
runtime:
name: node@24
port: 8080
health_path: /healthz
env:
MCP_AUTH_TOKEN: secret://MCP_AUTH_TOKEN
DATABASE_URL: secret://DATABASE_URL
PROVIDER_API_KEY: secret://PROVIDER_API_KEYCiclo di sviluppo
Compila in locale, poi verifica tramite la route distribuita.
Test locali degli strumenti
Chiama ogni handler degli strumenti con input validi e non validi. Il server deve restituire errori strutturati, non stack trace.
Anteprima su Adios
Distribuisci un’anteprima, controlla i log dell’ambiente di esecuzione e verifica l’endpoint di integrità prima di collegare client reali.
Rilascio in produzione
Associa la route definitiva, ruota i segreti tramite Adios e usa lo stesso flusso di distribuzione per le future modifiche agli strumenti.
FAQ
Domande sui server MCP personalizzati.
Il mio server MCP ospitato deve usare stdio?
No, per l’hosting in produzione. Stdio è utile per le integrazioni desktop locali, ma un server ospitato deve esporre un trasporto compatibile con HTTP e una route di integrità tramite HTTPS.
Posso distribuire un server MCP in TypeScript o Python?
Sì. Adios esegue normali processi applicativi di lunga durata. Usa l’ambiente di esecuzione e il comando di avvio necessari al server MCP, poi esponi la porta configurata.
Come devo proteggere gli strumenti MCP?
Tratta gli strumenti MCP come endpoint API. Valida gli input, richiedi credenziali con ambito limitato, imposta timeout, evita token amministrativi con permessi troppo ampi e tieni i segreti fuori dai sorgenti.
In cosa differisce dalla pagina della piattaforma MCP di Adios?
Questa guida spiega come creare e distribuire il tuo server MCP. La pagina /mcp spiega come usare Adios tramite il suo endpoint MCP.