MCP na prática: conectar um agente sem entregar as chaves
O que o Model Context Protocol padroniza, o que sua aplicação ainda precisa controlar e como desenhar uma primeira integração útil.
Revisado em 4 de setembro de 2026. Os detalhes de protocolo abaixo se referem à especificação 2025-06-18.
O Model Context Protocol oferece às aplicações de IA uma forma comum de se conectar a recursos externos. Pode reduzir trabalho repetido de integração, mas não decide quais ações de negócio um agente deve poder executar.
Essa diferença importa quando o sistema conectado contém cadastros de clientes, dados operacionais ou ações difíceis de desfazer.
O que se conecta a quê?
Na arquitetura do MCP, o host é a aplicação de IA. Ele gerencia clientes, cada um conectado a um servidor que expõe capacidades. Um servidor pode disponibilizar documentos para consulta, um prompt reutilizável ou uma ferramenta para localizar pedidos.
O host coordena a interação; um servidor não precisa receber a conversa inteira para atender a uma solicitação específica. O protocolo permite negociar capacidades, então a integração precisa considerar o que ambos os lados realmente implementam. Veja a especificação de arquitetura do MCP.
Dois transportes padrão, diferentes formas de implantação
A especificação 2025-06-18 define stdio e Streamable HTTP. No stdio, o cliente inicia um subprocesso servidor e troca mensagens pela entrada e saída padrão. No Streamable HTTP, o servidor roda de forma independente e os clientes se comunicam por HTTP; SSE pode ser usado para streaming.
O Streamable HTTP substituiu o transporte HTTP+SSE anterior. Isso não torna o SSE em si obsoleto ou inerentemente inseguro. Uma implantação HTTP sem estado é uma escolha de projeto, não um terceiro transporte padrão. Veja a especificação de transportes.
Iniciar um subprocesso não o coloca automaticamente em uma sandbox. Confira a quais arquivos, credenciais e destinos de rede ele tem acesso. O isolamento de containers também depende da configuração; volumes do host ou privilégios excessivos podem expor mais do que o necessário.
Desenhe primeiro o limite de negócio
Suponha que sua equipe queira um assistente para investigar entregas atrasadas. É um exemplo de desenho de integração, não uma implementação completa de servidor.
Comece por uma consulta delimitada: localizar um pedido que o usuário autenticado tem direito de acessar e retornar o estado, datas relevantes e identificadores das fontes. Evite uma ferramenta genérica de banco de dados ou shell quando uma operação específica for suficiente.
Depois, separe as ações possíveis:
- Consultar o estado de um pedido.
- Preparar uma atualização para o cliente.
- Enviar a atualização aprovada.
- Alterar a atribuição da entrega.
Essas operações têm consequências diferentes. Não as reúna em uma ferramenta com privilégios amplos só porque pertencem ao mesmo processo.
A autorização precisa ser verificada no momento da execução. Um identificador de cliente fornecido pelo modelo é o alvo solicitado, não uma prova de que o usuário pode acessar aquele registro. A aprovação na interface é útil, mas o backend ainda precisa fazer cumprir a decisão.
O que o MCP não implementa por você
Você ainda precisa de validação de entradas, isolamento entre clientes, limites, timeouts e tratamento de falhas parciais. Um servidor compatível com o protocolo pode executar incorretamente uma operação de negócio.
Para uma escrita, defina como as tentativas repetidas funcionam antes de habilitá-las. Se o serviço de destino aceitou a mudança, mas a resposta se perdeu, repetir sem verificar pode duplicar o efeito. Retorne identificadores persistentes das operações e ofereça uma forma de consultar o resultado real.
Mantenha credenciais fora do texto visível ao modelo e dos logs de rotina. Em integrações remotas autenticadas, valide o destinatário previsto das credenciais; não repasse simplesmente o token de um cliente a outro serviço. A orientação de segurança do MCP alerta explicitamente contra esse repasse, chamado token passthrough. Leia a orientação de segurança.
Um primeiro teste de integração útil
Exercite o processo com um registro permitido, outro proibido, dados ausentes e uma dependência temporariamente indisponível. Verifique que o acesso negado continua negado mesmo se o pedido for formulado de outra maneira.
Para ações, teste envios duplicados e um timeout depois de a alteração ter sido concluída no destino. O usuário deve entender o que está confirmado, o que está incerto e como recuperar — sem uma mensagem de sucesso inventada.
Registre o suficiente para reconstruir a operação: identidade, ferramenta, alvo, decisão de autorização e resultado. Oculte dados sensíveis e defina retenção, em vez de guardar indefinidamente todos os argumentos e respostas.
MCP é um mecanismo de conexão. A qualidade da integração continua dependendo de uma operação bem definida e dos controles ao redor dela.
A seguir: como Skills complementam o MCP e limites de segurança para agentes.