Escolha o transporte deliberadamente
Um servidor stdio local e um serviço remoto HTTP têm necessidades de implantação diferentes. Use um transporte remoto suportado, TLS e uma rota autenticada. Verifique as versões do cliente e do servidor em vez de presumir que todas as implementações suportam as mesmas capacidades.
Trate cada ferramenta como um API
Valide argumentos, aplique autorização específica por usuário e limite recursos. Não exponha a execução arbitrária de shell como ferramenta de conveniência. Restrinja os destinos de saída onde uma ferramenta busca URLs e mantenha segredos fora de descrições e respostas.
Mantenha a coleta de identidade proporcional
Um host sem KYC pode minimizar os dados de cadastro do provedor, mas o serviço MCP ainda pode precisar de seus próprios usuários, segurança de sessão e controles de abuso. Explique o que ele registra e evite reter entradas de ferramentas sem uma finalidade definida.
Implemente para uma clareza operacional
Execute sob um usuário dedicado, use verificações de integridade, limite os tempos de requisição e mantenha o buffering e os timeouts do proxy reverso compatíveis com o protocolo. Teste autenticação, revogação, desconexões e novas tentativas antes de conceder privilégios de escrita.
Alinhe a autenticação com o protocolo suportado
Para uma implementação de MCP baseada em HTTP, reveja os requisitos de autorização atuais do protocolo e a versão suportada pelo cliente. O acesso a recursos baseado em OAuth envolve o público do token, a descoberta e o âmbito, não apenas uma palavra-passe na página inicial. Use HTTPS, valide os tokens para o recurso pretendido e mantenha as credenciais bearer fora das strings de consulta. Um servidor stdio usa um limite de credenciais local diferente.
- Testar um pedido não autenticado
- Teste uma solicitação autenticada fora do seu escopo
- Revogue uma credencial e verifique que deixa de funcionar
Documentação oficial: especificação de autorização MCP
Publique um primeiro conjunto de ferramentas limitado
Comece com ferramentas somente leitura que retornam uma quantidade limitada de dados. Adicione gravações de arquivos, operações de ciclo de vida do servidor ou mensagens externas somente depois que suas permissões e comportamento de duplicação forem compreendidos. Trate páginas web e documentos retornados como entrada não confiável; eles não devem expandir silenciosamente a autoridade do servidor de ferramentas.
Fixar o comportamento do protocolo antes de escrever regras de proxy
Registe tanto a versão do servidor SDK como a revisão do MCP que o cliente irá utilizar. Na revisão 2026-07-28 Streamable HTTP, os pedidos utilizam um endpoint POST; exemplos mais antigos que dependem de sessões de protocolo ou de um fluxo GET autónomo correspondem a uma revisão diferente. Não remova um aparente requisito de compatibilidade até saber que cliente suporta. Um proxy reverso deve preservar os cabeçalhos necessários, o estado HTTP e o comportamento de streaming de respostas para essa versão.
- Comece com uma ferramenta somente leitura em um listener de loopback e, em seguida, coloque a fronteira de HTTPS/autenticação pretendida à frente dela.
- Teste um resultado normal, um resultado em streaming, um timeout e um cliente desligado através do proxy público.
- Valide os valores de Origin permitidos conforme exigido pelo transporte; uma verificação de Origin não substitui a autenticação do chamador.
- Se os eventos chegarem apenas no final, inspecione o buffering do proxy e o comportamento de timeout antes de alterar o código da ferramenta.
Documentação oficial: MCP 2026-07-28: HTTP em streaming
Teste as falhas de autorização com o mesmo rigor que os sucessos
Para acesso a HTTP protegido por OAuth, o servidor MCP é um recurso protegido. Teste a descoberta de metadados, o emissor esperado e o público do token, e os escopos necessários para uma operação específica. Mantenha o token de autorização fora das strings de consulta de URL e nunca o encaminhe inalterado para um serviço downstream não relacionado. Uma falha de autenticação voltada ao cliente deve preservar o desafio HTTP apropriado para que o cliente possa se recuperar pelo fluxo suportado.
- Sem token ou com token expirado: o endpoint protegido rejeita o acesso em vez de retornar dados privados da ferramenta.
- Token válido com permissões insuficientes: o recurso pedido continua inacessível.
- Token para outro público: rejeite-o mesmo que a sua assinatura seja válida de outro modo.
- URL externo inesperado ou caminho de arquivo: valide com a autoridade da ferramenta antes de buscar ou gravar.
- Registos e rastos de erros: mantenha um identificador de operação e o resultado, removendo tokens e entradas privadas de ferramentas.
Documentação oficial: MCP 2026-07-28: autorização HTTP · MCP: práticas recomendadas de segurança