Comece com acesso de leitura
A inspeção do catálogo, da localização e do estado pode constituir um conjunto de ferramentas inicial limitado. Um cliente deve poder saber o que é suportado antes de obter autoridade para criar, cancelar ou financiar recursos.
Separe ações consequentes
O cancelamento do servidor, a reinstalação e as ações de pagamento exigem âmbitos explícitos e confirmações compreensíveis. As descrições das ferramentas devem indicar o seu efeito, e o servidor deve impor a autorização em vez de confiar no comportamento do cliente.
Lidar com resultados incertos
Devolva identificadores de operação e erros legíveis. Utilize idempotência quando uma nova tentativa possa criar um recurso ou pagamento adicional. Registe o resultado sem incluir segredos nas respostas das ferramentas ou nos registos.
As informações de lançamento devem ser reais
Um lançamento requer um endpoint verificado, instruções de autenticação, uma versão de protocolo suportada e limites documentados. Não é fornecido aqui nenhum endpoint emprestado, lançamento falso de SDK nem ligação de transferência.
Separar a descrição de uma ferramenta da permissão para executá-la
Um servidor MCP pode descrever ferramentas de catálogo e gestão, enquanto a conta autenticada decide quais chamadas um cliente pode executar. Uma ferramenta chamada create_server precisa de privilégios de servidor e de uma decisão de pedido válida. Uma ferramenta read_catalogue não deve exigir uma credencial com autoridade de cancelamento ou faturamento.
Grupos de ferramentas úteis para um agente de infraestrutura
O design pretendido abrange a leitura de planos e imagens, a verificação de pedidos e operações, o gerenciamento de chaves públicas SSH e a observação do estado do servidor. Criar ou cancelar um serviço e iniciar um pagamento são ações consequentes que exigem a autorização adequada. Retorne identificadores estruturados e estados terminais claros em vez de texto que o cliente precise adivinhar.
Transporte e autenticação devem ser documentados
Um futuro endpoint remoto precisa de HTTPS, um transporte suportado e um mecanismo de token explícito. As credenciais pertencem ao canal de autenticação aprovado, não a um exemplo de configuração público. O registro OAuth, as versões de protocolo, os pacotes stdio para download e os selos de compatibilidade só devem ser publicados depois que KoalaVPS os implementar e verificar.
Uma nova tentativa deve retornar à mesma operação
Um agente pode perder a ligação depois de o servidor ter aceitado um pedido. Persista um identificador de operação ou de idempotência antes de repetir uma ação paga. Volte a ler o estado após uma resposta incerta. Os tempos limite e a ausência de mensagem não provam que a ação original falhou.
Nenhum endpoint KoalaVPS MCP alojado está ligado aqui
Esta página descreve uma integração planeada. Não regista um agente, não instala um pacote de servidor, não fornece credenciais nem liga uma ferramenta de gestão ativa. Os guias de implementação explicam como os clientes podem alojar as suas próprias aplicações MCP num VPS; essas aplicações são independentes de um serviço de plano de controlo KoalaVPS.
Um pouco mais de clareza.
Esta página é, ela própria, um endpoint do protocolo MCP?
Não. É uma página web explicativa. Um futuro endpoint de máquina deve ser implementado, documentado e autenticado separadamente.
Um agente de IA recebe permissão para gastar apenas por se conectar?
Não. A descoberta de ferramentas e a autenticação não substituem o âmbito da conta, as verificações de faturação ou as regras de aprovação para a ação solicitada.