Para separar teste e produção em conectores MCP do Claude, mantenha destinos, credenciais, dados e permissões distintos no servidor que oferece as ferramentas. Identificar o conector como “teste” ajuda a pessoa a escolher, mas a proteção efetiva precisa impedir que uma chamada experimental alcance a base real. A mesma regra vale para consultas, arquivos, filas e serviços acionados depois da primeira chamada.
Este guia propõe uma arquitetura de implantação e um roteiro de verificação. Não descreve um botão do Claude que crie ambientes isolados automaticamente. O produto oferece conexão com servidores MCP remotos; a separação dos sistemas conectados depende da sua implementação. Consulte também a página de integrações do Claude para contextualizar as conexões disponíveis.
Resumo rápido
- Separe os destinos de teste e produção e confira a configuração efetivamente carregada.
- Use credenciais diferentes e permissões restritas em cada ambiente.
- Crie dados fictícios para experimentar leitura e escrita.
- Teste tentativas de cruzar ambientes e registre a recusa do servidor.
- Promova uma versão revisada, sem transportar segredos ou dados reais.
O que deve ficar separado
MCP é um protocolo para aplicações de IA acessarem ferramentas e fontes de dados. O servidor pode, por exemplo, oferecer uma consulta de pedidos ou uma operação para atualizar um cadastro. Para compreender os componentes antes de configurar ambientes, veja o guia de MCP. Aqui, o problema é decidir a qual sistema cada ferramenta terá acesso quando for chamada.
Trate ambiente como um conjunto de recursos. Ele inclui o endereço do servidor, a identidade usada na autenticação, o banco consultado, o armazenamento de arquivos e os serviços posteriores. Dois endereços que usam a mesma senha de banco continuam permitindo interferência entre experimentos e operação. Dois bancos também não bastam se ambos os servidores publicam mensagens na mesma fila de atendimento.
Liste todas as saídas de cada ferramenta, incluindo os efeitos indiretos. Uma função chamada “simular orçamento” pode consultar o estoque real, gravar um arquivo compartilhado e enviar um aviso ao vendedor. O nome não demonstra que a operação é uma simulação. A revisão deve seguir a chamada até seu último destino e identificar onde pode haver mudança persistente.
| Componente | Teste | Produção | Como conferir |
|---|---|---|---|
| Servidor MCP | Destino próprio de homologação | Destino operacional aprovado | Registro de configuração e identificação retornada |
| Credencial | Identidade sem acesso à operação | Identidade limitada ao fluxo real | Tentativa controlada de acesso cruzado |
| Dados | Clientes e pedidos fictícios | Registros efetivos do negócio | Marcadores exclusivos por base |
| Mensagens | Caixa ou fila de teste | Destinatários autorizados | Inspeção dos destinos antes do envio |
| Registros | Evidências de homologação | Rastreabilidade operacional | Identificador de ambiente em cada evento |
Identifique o destino sem depender da memória
Adote nomes que incluam sistema, finalidade e ambiente, como “Pedidos da loja: homologação”. Registre junto o endereço completo, o proprietário e a data da última conferência. Essa convenção é uma recomendação de operação. Não presuma que o nome exibido na interface modifica as permissões ou valida o banco conectado.
A documentação de conectores personalizados do Claude descreve o cadastro de nome, URL e autenticação. Use esses campos para conferir o destino pretendido. A revisão do endereço merece uma etapa própria, como mostra o artigo sobre verificação de domínio de um conector remoto.
Na implementação do seu servidor, considere uma ferramenta de diagnóstico somente de leitura que retorne ambiente, versão e um identificador não secreto da instalação. Compare a resposta com o registro aprovado. Evite retornar variáveis de ambiente completas: elas podem conter senhas. Esse diagnóstico é uma opção de projeto do servidor, não uma função garantida pelo Claude ou obrigatória em qualquer conector.
Faça a conferência no início de uma sessão de homologação e depois de mudanças de configuração. Uma versão recém-publicada pode ter carregado um arquivo incorreto mesmo que o domínio continue certo. Verifique também o serviço de destino: a identidade de homologação deve encontrar apenas o marcador fictício definido para aquela base.
Isole permissões, segredos e dados
Crie identidades específicas para os ambientes quando o serviço conectado permitir essa divisão. Evite uma credencial administrativa compartilhada por todos os testes. Conceda somente as ações necessárias, comece por leitura e libere escrita quando houver um caso de uso revisado. Uma credencial de homologação não deve receber acesso à base real para facilitar um teste pontual.
Na especificação de autorização MCP consultada, a validação do destinatário do token é parte da fronteira de autorização. A orientação de segurança do protocolo também trata o repasse indevido de tokens. Esses requisitos não substituem a decisão da empresa sobre quais bases e contas pertencem a cada ambiente.
Monte um conjunto fictício que represente casos difíceis: pedido cancelado, cliente sem endereço, produto indisponível e cadastro duplicado. Dê a cada registro um identificador de teste visível. Não copie uma planilha de clientes inteira apenas para ter dados realistas. O objetivo é reproduzir as condições da operação com o menor conteúdo necessário para avaliar a ferramenta.
Guarde segredos fora do HTML de documentação, dos prompts e dos exemplos de chamada. Quando houver integração Google, as boas práticas oficiais de OAuth orientam o armazenamento seguro de credenciais e tokens. Na ficha de homologação, informe apenas a referência ao local protegido e quem pode administrar o acesso.
Teste as fronteiras e promova uma versão
Um teste positivo mostra que a ferramenta consegue executar a tarefa. Um teste de fronteira mostra que ela recusa o que não deveria fazer. Prepare ambos. Consulte um pedido fictício, tente consultar um identificador reservado à produção e verifique que a segunda operação falha sem revelar conteúdo do registro real.
Faça o mesmo com escrita. Crie um orçamento em homologação e confira onde ele apareceu. Tente alterar o destino por um argumento inesperado, por um identificador de outra conta ou por uma configuração incompleta. O servidor deve resolver e validar o ambiente a partir de configuração confiável. Uma frase no prompt pedindo cuidado não deve ser o único controle.
Registre entrada, resultado esperado, resultado observado e referência à evidência. Evite anexar tokens aos registros. A aprovação deve mostrar qual versão foi testada, quais ferramentas estavam disponíveis e quais integrações posteriores foram verificadas. O roteiro de teste de agentes antes da produção ajuda a organizar critérios observáveis.
Ao promover, reutilize o código e os critérios aprovados, mas aplique as configurações específicas de produção pelo processo autorizado da equipe. Não copie o arquivo de segredos de homologação. Faça uma leitura limitada, confira o ambiente e só então valide uma escrita de baixo impacto previamente combinada. Defina quem interrompe o fluxo se o destino divergir do esperado.
Planeje a reversão antes da mudança: versão anterior, responsável e operações que exigem correção manual. Voltar o código não desfaz um e-mail enviado ou um pedido alterado. Se houver efeito persistente, interrompa novas chamadas e faça uma reconciliação dos registros afetados. O plano precisa refletir o negócio conectado, não apenas o servidor MCP.
Exemplo: distribuidora de peças em Curitiba
Considere uma distribuidora fictícia de peças em Curitiba que quer usar Claude para consultar disponibilidade e preparar orçamentos. O exemplo é ilustrativo e não relata resultados de uma empresa real. A equipe possui uma base de pedidos, uma pasta de propostas e um serviço que avisa vendedores quando um orçamento fica pronto.
Na homologação, o servidor usa produtos fictícios e uma pasta exclusiva. O aviso vai para uma caixa de teste administrada pela equipe. A ferramenta de orçamento aceita somente códigos existentes nessa base. O responsável registra o identificador da instalação e confere que o destino do aviso também está separado. Assim, a avaliação inclui o efeito posterior à geração do documento.
O roteiro contém um pedido válido, um item inexistente e um código que representa um cliente da operação. Para o último caso, espera-se recusa sem informação sobre o cliente. Se a ferramenta encontra o cadastro real, a equipe suspende a promoção e investiga a permissão da identidade usada no banco.
Depois da correção, uma segunda pessoa repete os casos e aprova a versão. A configuração operacional é aplicada separadamente. O primeiro orçamento real tem destinatário e conteúdo revisados pelo vendedor responsável. A decisão de liberar novas operações depende dessa conferência e da capacidade de interromper o fluxo, não da qualidade aparente da resposta textual.
Erros comuns
- Trocar apenas o nome: dois conectores com rótulos diferentes podem alcançar a mesma base. Verifique credenciais e destinos efetivos.
- Compartilhar saídas secundárias: separar o banco e esquecer e-mail, arquivo ou fila permite efeitos reais durante o teste.
- Confiar em instruções de linguagem: pedir “use só homologação” não revoga uma permissão concedida no servidor.
- Testar com acesso amplo: uma identidade administrativa esconde falhas que aparecerão com o usuário operacional.
- Promover sem evidências: uma conversa bem-sucedida não substitui casos registrados e conferência dos dados gravados.
- Reverter só o código: avalie efeitos externos já realizados antes de declarar que o serviço voltou ao estado anterior.
Perguntas frequentes
Dois conectores garantem isolamento?
Não. Eles podem apontar para serviços que compartilham credenciais e dados. A separação deve existir nos recursos acessados e ser demonstrada com testes de recusa entre os ambientes.
Posso começar com um servidor somente de leitura?
Sim, quando isso atende ao objetivo inicial. Ainda é preciso controlar quais dados ele pode ler. Uma consulta sem escrita também pode expor informações de produção se a credencial estiver configurada incorretamente.
Uma ferramenta de simulação nunca altera dados?
Isso depende da implementação. Confira o contrato da ferramenta e seus efeitos posteriores. Um nome com “simular” não prova ausência de gravação, cobrança, mensagem ou atualização de arquivo.
É necessário usar dados reais na homologação?
Prefira dados fictícios que representem as condições relevantes. Se uma investigação exigir conteúdo operacional, defina uma autorização específica e um procedimento apropriado; não transforme a cópia integral da base em rotina de teste.
Quem deve aprovar a passagem para produção?
O responsável pelo sistema e alguém que compreenda o efeito de negócio das ferramentas. A aprovação deve identificar versão, escopo e evidências, além de quem pode interromper a execução quando houver divergência.
