Commencez par un accès en lecture
L'inspection du catalogue, de l'emplacement et de l'état peut constituer un ensemble d'outils initial limité. Un client devrait pouvoir découvrir ce qui est pris en charge avant d'obtenir l'autorité de créer, d'annuler ou de financer des ressources.
Séparez les actions à conséquences
L'annulation de serveur, la réinstallation et les actions de paiement nécessitent des portées explicites et des confirmations compréhensibles. Les descriptions des outils doivent indiquer leur effet, et le serveur doit faire respecter l'autorisation plutôt que de se fier au comportement du client.
Gérez les résultats incertains
Renvoiez des identifiants d'opération et des erreurs lisibles. Utilisez l'idempotence lorsqu'une nouvelle tentative pourrait créer une ressource ou un paiement supplémentaire. Enregistrez le résultat sans inclure de secrets dans les réponses des outils ou les journaux.
Les informations de version doivent être réelles
Un lancement nécessite un point de terminaison vérifié, des instructions d’authentification, une version de protocole prise en charge et des limites documentées. Aucun point de terminaison emprunté, fausse version SDK ni lien de téléchargement n’est fourni ici.
Séparez la description d'un outil de l'autorisation de l'exécuter
Un serveur MCP peut décrire des outils de catalogue et de gestion, tandis que le compte authentifié décide quels appels un client peut exécuter. Un outil nommé create_server nécessite des privilèges serveur et une décision de commande valide. Un outil read_catalogue ne devrait pas exiger d'identifiant disposant d'une autorité d'annulation ou de facturation.
Groupes d'outils utiles pour un agent d'infrastructure
La conception prévue couvre la consultation des plans et des images, la vérification des commandes et des opérations, la gestion des clés publiques SSH et l'observation de l'état du serveur. La création ou la résiliation d'un service et le lancement d'un paiement sont des actions à conséquences qui exigent l'autorisation appropriée. Renvoyez des identifiants structurés et des états terminaux clairs plutôt qu'un texte que le client doit deviner.
Le transport et l'authentification doivent être documentés
Un futur point de terminaison distant nécessite HTTPS, un transport pris en charge et un mécanisme de jeton explicite. Les identifiants doivent se trouver dans le canal d'authentification approuvé, et non dans un exemple de configuration public. L'enregistrement OAuth, les versions de protocole, les paquets stdio téléchargeables et les badges de compatibilité ne doivent être publiés qu'une fois que KoalaVPS les a implémentés et vérifiés.
Une nouvelle tentative doit revenir à la même opération
Un agent peut perdre sa connexion après que le serveur a accepté une requête. Persistez un identifiant d'opération ou d'idempotence avant de réessayer une action payante. Relisez l'état après une réponse incertaine. Les délais d'attente et l'absence de message ne prouvent pas que l'action d'origine a échoué.
Aucun point de terminaison KoalaVPS MCP hébergé n'est connecté ici
Cette page décrit une intégration prévue. Elle n'enregistre aucun agent, n'installe aucun paquet serveur, ne fournit aucun identifiant et ne connecte aucun outil de gestion actif. Les guides de déploiement expliquent comment les clients peuvent héberger leurs propres applications MCP sur un VPS ; ces applications sont distinctes d'un service de plan de contrôle KoalaVPS.
Un peu plus de clarté.
Cette page est-elle elle-même un point de terminaison de protocole MCP ?
Non. Il s'agit d'une page web explicative. Un futur point de terminaison machine doit être implémenté, documenté et authentifié séparément.
Un agent IA reçoit-il l’autorisation de dépenser simplement en se connectant ?
Non. La découverte d'outils et l'authentification ne remplacent pas la portée du compte, les vérifications de facturation ni les règles d'approbation pour l'action demandée.