MCP na prática: conectar ferramentas sem apagar fronteiras de confiança

Conecte uma ferramenta MCP identificando o servidor que recebe a solicitação e a conta que autoriza a operação. Antes de avançar, confira se a ferramenta pode ler dados, modificá-los ou ambos, e se o token foi emitido para aquele serviço. Uma conexão saudável ainda deixa essas decisões de acesso para você resolver.

O guia introdutório do protocolo apresenta MCP como um padrão aberto para ligar aplicações de IA a dados, ferramentas e fluxos externos. Ele padroniza a integração. A autorização e o comportamento seguro dependem também do cliente, do servidor e dos serviços envolvidos. Este guia combina essa distinção com a configuração documentada no Claude Code.

Entenda o caminho antes de configurar

O assistente usa um cliente para se comunicar com um servidor MCP. Esse servidor pode expor ferramentas ligadas a outro serviço. Pense num acesso a documentos: a aplicação de IA solicita uma consulta, o servidor atende a chamada e o serviço de documentos aplica as permissões da conta autorizada. Cada passagem tem responsabilidades próprias.

Isso evita uma confusão comum: protocolo de ferramentas não é sinônimo de login. OAuth, quando utilizado, trata a concessão de acesso. O transporte leva as mensagens entre cliente e servidor. E a lógica da ferramenta define o que uma chamada efetivamente faz. Uma conexão funcionando não demonstra que todos esses elementos receberam a configuração adequada.

Antes de instalar, confirme quem mantém o servidor e qual endereço oficial deve ser usado. Para um processo local, confirme também qual programa será executado e de onde ele vem. Um nome conhecido no catálogo não transforma qualquer pacote encontrado com nome parecido em software confiável.

Use um exemplo documentado de conexão remota

A documentação do Claude Code apresenta este comando para o servidor do Notion:

claude mcp add --transport http notion https://mcp.notion.com/mcp

O comando registra uma conexão HTTP com o nome notion. Ele é um exemplo oficial de configuração, não uma operação executada neste guia. Antes de reproduzi-lo, confira se esse é o serviço desejado e se você tem autorização para conectar a conta. Registrar o servidor e conceder acesso são etapas distintas.

Os argumentos de transporte aparecem antes do nome. Em configurações JSON, a documentação exige o tipo adequado para uma entrada com URL. Uma URL sem type é tratada como erro porque a ausência de tipo faz o cliente interpretar a entrada como um servidor stdio. Evite converter exemplos entre formatos por adivinhação.

HTTP remoto também difere de stdio. No segundo caso, o cliente inicia um processo local e troca mensagens com ele. Isso acrescenta a confiança no executável e no acesso que ele recebe à máquina. Escolha o transporte documentado pelo servidor; não substitua o método apenas porque outro exemplo parece mais curto.

Confira autorização e conta efetiva

Quando o servidor usa OAuth, complete o fluxo de autenticação apresentado pelo cliente e confira a conta escolhida. Use a interface de gerenciamento MCP para observar o estado da conexão. A presença de um servidor na configuração não demonstra que a autenticação terminou ou que a conta conectada é a pretendida.

Leia as permissões solicitadas antes de consentir. As boas práticas de segurança do MCP recomendam escopos mínimos e elevação quando uma operação privilegiada realmente exigir acesso adicional. Consultar documentos não deveria ser motivo automático para autorizar toda capacidade de escrita oferecida pelo serviço.

Uma fronteira importante está no destino do token. O servidor precisa validar que o token foi emitido para o recurso correto. As boas práticas rejeitam token passthrough: aceitar um token destinado a outro serviço e encaminhá-lo como se fosse autorização adequada para o servidor MCP. Isso compromete a separação entre os participantes.

Se houver um intermediário, o consentimento continua necessário

Um servidor que representa outros serviços pode introduzir o problema conhecido como confused deputy. Em termos práticos, um intermediário com acesso legítimo acaba sendo usado para agir em benefício de um cliente que não recebeu a autorização correspondente. O documento de segurança discute riscos envolvendo identificação de clientes e consentimento em proxies OAuth.

O ponto para quem integra não é implementar um fluxo próprio às pressas. É verificar que o fornecedor trata consentimento, identificação do cliente e validação de tokens como responsabilidades explícitas. Uma tela de login familiar não basta se o vínculo entre cliente, recurso e autorização estiver incorreto.

Para quem apenas utiliza a integração, a decisão é mais direta: prefira o fluxo oficial, não cole tokens de um serviço em outro por conveniência e não distribua configurações contendo segredos. Se o procedimento exigir credenciais, siga o mecanismo recomendado pelo mantenedor e preserve a separação entre configuração compartilhável e acesso particular.

Verifique a conexão com uma tarefa de baixo impacto

Como teste sugerido, peça a leitura de um documento não sensível que você consiga conferir manualmente. Compare o conteúdo devolvido com a fonte e observe se a conta efetiva consegue acessar somente o material esperado. Esta proposta não significa que tenhamos realizado a consulta ou validado um servidor específico.

Depois, confira uma condição negativa: um recurso fora do acesso concedido deve continuar indisponível. Não procure contornar a recusa. Ela ajuda a verificar a fronteira que a autorização deveria preservar. Se o próximo uso envolver escrita, avalie essa permissão separadamente e escolha uma operação reversível num ambiente apropriado.

1. Confira o conteúdo recuperado como dado externo. Não deixe instruções dentro de um documento redirecionarem o assistente para fora do seu pedido.
2. Rastreie a ação pela aplicação, pelo servidor e pela conta autorizadora. Confirme que as operações expostas cabem na permissão concedida; o MCP dá acesso ao conteúdo, sem torná-lo autoridade sobre a sessão.