Inizia con l'accesso in lettura
L'ispezione di catalogo, posizione e stato può costituire un set iniziale limitato di strumenti. Un client dovrebbe poter scoprire cosa è supportato prima di ottenere l'autorizzazione a creare, annullare o finanziare risorse.
Separa le azioni con conseguenze
Le azioni di cancellazione del server, reinstallazione e pagamento richiedono scope espliciti e conferme comprensibili. Le descrizioni degli strumenti devono indicarne l'effetto e il server deve applicare l'autorizzazione invece di fidarsi del comportamento del client.
Gestisci esiti incerti
Restituisci identificatori di operazione ed errori leggibili. Usa l'idempotenza dove un nuovo tentativo potrebbe creare una risorsa o un pagamento aggiuntivo. Registra l'esito senza includere segreti nelle risposte degli strumenti o nei log.
Le informazioni sulla versione devono essere reali
Un lancio richiede un endpoint verificato, istruzioni di autenticazione, una versione di protocollo supportata e limiti documentati. Qui non viene fornito alcun endpoint preso in prestito, rilascio SDK falso o link di download.
Separare la descrizione di uno strumento dall'autorizzazione a eseguirlo
Un server MCP può descrivere strumenti di catalogo e gestione, mentre l'account autenticato decide quali chiamate un client può eseguire. Uno strumento chiamato create_server richiede privilegi sul server e una valida decisione d'ordine. Uno strumento read_catalogue non dovrebbe richiedere una credenziale con autorità di cancellazione o fatturazione.
Gruppi di strumenti utili per un agente infrastrutturale
Il design previsto copre la lettura di piani e immagini, la verifica di ordini e operazioni, la gestione delle chiavi pubbliche SSH e l'osservazione dello stato del server. Creare o cancellare un servizio e avviare un pagamento sono azioni consequenziali che richiedono l'autorizzazione appropriata. Restituisci identificatori strutturati e stati terminali chiari anziché testo in prosa che un client deve indovinare.
Trasporto e autenticazione devono essere documentati
Un futuro endpoint remoto necessita di HTTPS, un trasporto supportato e un meccanismo di token esplicito. Le credenziali appartengono al canale di autenticazione approvato, non a un esempio di configurazione pubblico. La registrazione OAuth, le versioni del protocollo, i pacchetti stdio scaricabili e i badge di compatibilità devono essere pubblicati solo dopo che KoalaVPS li implementa e verifica.
Un nuovo tentativo deve tornare alla stessa operazione
Un agente può perdere la connessione dopo che il server ha accettato una richiesta. Persisti un identificativo di operazione o di idempotenza prima di ritentare un'azione a pagamento. Rileggi lo stato dopo una risposta incerta. I timeout e l'assenza di un messaggio non provano che l'azione originale sia fallita.
Nessun endpoint KoalaVPS MCP ospitato è connesso qui
Questa pagina descrive un'integrazione pianificata. Non registra un agente, non installa un pacchetto server, non fornisce credenziali né collega uno strumento di gestione attivo. Le guide di distribuzione spiegano come i clienti possono ospitare le proprie applicazioni MCP su un VPS; tali applicazioni sono separate da un servizio control-plane KoalaVPS.
Un po' più di chiarezza.
Questa pagina è essa stessa un endpoint del protocollo MCP?
No. È una pagina web esplicativa. Un futuro endpoint macchina deve essere implementato, documentato e autenticato separatamente.
Un agente AI riceve il permesso di spendere solo connettendosi?
No. La scoperta degli strumenti e l'autenticazione non sostituiscono l'ambito dell'account, i controlli di fatturazione o le regole di approvazione per l'azione richiesta.