Model Context Protocol (MCP) é um protocolo aberto que padroniza como uma aplicação de IA descobre e acessa contexto e capacidades oferecidos por programas chamados servidores. Em termos práticos, uma aplicação pode se conectar a um servidor MCP que publica ferramentas, dados ou modelos de interação. Isso reduz a necessidade de criar uma integração diferente para cada par de aplicativo e serviço, mas não torna qualquer ferramenta automaticamente compatível, segura ou autorizada.

Nota editorial: Sem teste próprio. O artigo explica critérios e limites; não substitui a documentação do fabricante nem avaliação elétrica ou de segurança da instalação.

Arquitetura e primitivas: documentação atual do MCP e especificação de 28/07/2026. Os riscos são resumidos a partir das boas práticas oficiais de segurança; para automação, veja a integração MCP Client do n8n.

Host, client e server sem confusão

O host é o aplicativo de IA que a pessoa usa — por exemplo, um editor, desktop assistant ou plataforma de automação. Ele cria um cliente MCP para cada servidor. O cliente é a parte da aplicação que fala o protocolo; o servidor é o programa que expõe ferramentas ou contexto. “Servidor” não significa necessariamente um computador remoto: pode ser um processo local por STDIO ou um serviço remoto via HTTP.

A documentação atual descreve duas camadas. A camada de dados define mensagens JSON-RPC, descoberta de versões/capacidades, ferramentas, recursos, prompts e notificações. A camada de transporte descreve como as mensagens viajam, incluindo STDIO local e Streamable HTTP remoto e sua autorização. Separar essas camadas ajuda a entender por que duas implementações podem falar MCP, mas ainda depender de transporte ou autenticação compatíveis.

Imagine um assistente conectado a um servidor de agenda e a outro de CRM. O host cria duas conexões isoladas; o cliente de cada conexão solicita as capacidades disponíveis. O servidor de agenda não precisa receber o histórico inteiro da conversa nem enxergar o servidor do CRM. Essa fronteira depende da implementação do host e da configuração, então leia a documentação do produto, em vez de assumir que o protocolo sozinho garante isolamento perfeito.

Tools, resources e prompts: três coisas diferentes

Tools são ações executáveis, como consultar um pedido, criar um rascunho ou buscar um registro. O cliente pode descobrir a lista de ferramentas e os esquemas dos argumentos; a aplicação e o modelo podem então decidir quando chamar uma delas. Uma tool pode ter efeito de leitura ou escrita. A decisão de publicar, enviar ou apagar deve permanecer sob controle claro do sistema e, quando necessário, exigir confirmação humana.

Resources representam dados que o servidor fornece como contexto, por exemplo conteúdo de arquivo, esquema de banco ou resposta de API. A leitura de um recurso não é necessariamente uma ação mutável, embora o conteúdo possa conter dados sensíveis. Limite o conjunto de recursos ao necessário e controle quem pode consultá-los.

Prompts são modelos reutilizáveis que orientam a interação. Podem estruturar uma tarefa e parâmetros, mas não são garantia de qualidade, segurança ou acesso. O host precisa mostrar a origem e tratar texto vindo de servidores como entrada externa. A pessoa deve distinguir instrução de sistema, contexto do servidor e decisão que produz efeito real.

O MCP também define recursos opcionais no cliente e extensões. A versão atual 2026-07-28 declara Sampling e Logging obsoletos para novas implementações; detalhes e compatibilidade podem variar conforme cliente e servidor. Ao ler guias antigos, confira a versão da especificação e do SDK, pois tutoriais anteriores podem descrever lifecycle e primitivas de versões passadas.

Exemplo conceitual: agente consulta o CRM

Suponha que uma equipe pergunte “quais oportunidades sem contato há hoje?”. O host recebe a pergunta. O cliente MCP lista ferramentas que o servidor do CRM oferece, como buscar oportunidades, com esquema de filtros. O modelo sugere uma chamada de leitura com data e status. O servidor consulta apenas os registros permitidos e devolve resultados estruturados. O host apresenta um resumo com link para a fonte, e a pessoa valida antes de registrar uma ação.

Se a pessoa pedir “envie uma mensagem para cada lead”, essa é uma operação diferente. Ela pode expor dados ou disparar comunicações externas. Uma implementação segura separa busca de envio, limita a quantidade, apresenta o conteúdo e exige aprovação explícita. O protocolo fornece a forma de chamar; política do host, autorização do usuário, scopes e controles do servidor definem se a ação pode ocorrer.

Em uma plataforma de automação como n8n, o node MCP Client permite conectar workflows a ferramentas expostas por um servidor MCP compatível. Isso é diferente de afirmar que todo workflow pode automaticamente oferecer suas ações como um servidor MCP, ou que todos os planos e versões tenham a mesma capacidade. Consulte a versão e a documentação oficial do node, credenciais e transporte antes de desenhar produção.

MCP também não é um modelo de IA, um agente completo, uma API de negócio nem uma automação pronta. É uma convenção de comunicação e descoberta. A qualidade da resposta continua dependendo do modelo, dados, instruções, ferramentas, permissões e validações do aplicativo. O servidor pode estar indisponível, devolver erro ou oferecer uma descrição enganosa; a interface deve expor essas condições.

Riscos e limites que precisam entrar no desenho

Uma ferramenta MCP pode alterar sistemas, acessar informação pessoal ou chamar serviços pagos. Conceda menor privilégio: somente leitura quando basta, escopos estreitos, lista permitida de ações e credenciais separadas por ambiente. Evite compartilhar um token amplo com vários servidores e não copie segredos para prompts, logs ou arquivos de configuração em repositórios.

Conteúdo retornado por tools e resources deve ser tratado como entrada não confiável. Um registro ou página pode conter instruções maliciosas para tentar induzir o modelo a enviar dados ou executar uma ação. O host precisa separar instruções de sistema e conteúdo externo, limitar a exposição e exigir revisão para efeitos importantes.

As melhores práticas oficiais do MCP descrevem riscos como confused deputy, token passthrough, SSRF, sequestro de sessão e excesso de escopo. Para integrações HTTP, use autenticação e autorização conforme a especificação e o serviço; não repasse token de downstream sem validar audiência e permissões. Para STDIO local, proteja os segredos no ambiente e valide o executável e os argumentos que o cliente inicia.

Registre servidor, versão, fornecedor, ferramentas disponíveis, escopos e responsável. Reavalie quando a lista de tools muda: uma atualização pode adicionar capacidades de escrita ou remover limites. Use ambiente de teste e dados fictícios, monitore chamadas, imponha timeout e limites, e mantenha um caminho para revogar credenciais. Essas práticas não eliminam todo risco, mas tornam o acesso verificável e reversível.

MCP não concede autorização por conta própria nem torna confiável um servidor desconhecido. Antes de instalar um servidor comunitário, revise repositório, dependências, configuração, acessos de rede, arquivos e permissões. Um processo local pode herdar privilégios do usuário; um serviço remoto pode receber dados enviados pelo cliente. Trate a conexão como integração de software com superfície de ataque real.

Quando adotar e como testar

MCP é útil quando um host já suporta o protocolo e vários serviços ou ferramentas precisam expor capacidades de forma consistente. Pode reduzir trabalho de conexão e facilitar descoberta. Se existe uma API simples e uma integração específica atende melhor a latência, auditabilidade e governança da empresa, não há obrigação de introduzir MCP. Compare custo de implantação, manutenção do servidor e gestão de credenciais.

Faça um piloto com uma ferramenta de leitura e dados fictícios. Verifique versão do protocolo, transporte, autenticação, nome e esquema da tool, tratamento de erro, logs e comportamento quando o servidor retorna texto inesperado. Depois teste uma ação de escrita em sandbox, com confirmação e rollback. Não use produção até definir quem aprova, como revogar e como investigar chamadas.

Avalie a saída do workflow pelo resultado e não pelo rótulo MCP: o campo consultado corresponde ao registro? A ferramenta recebeu apenas os parâmetros necessários? Chamadas repetidas duplicam efeitos? O que aparece nos logs? Quais usuários têm autorização? Essas perguntas tornam a validação prática e não dependente de uma demonstração feliz.

Se o cenário envolve clientes, cobrança ou dados sensíveis, envolva segurança e jurídico conforme a política da organização. Limite retenção, minimize dados, use contas de serviço restritas e documente a finalidade. Não compartilhe informação pessoal com um servidor apenas porque o host consegue conectá-lo.

Perguntas frequentes

MCP é uma API?

Não exatamente. É um protocolo que padroniza descoberta e comunicação entre hosts/clientes e servidores. O servidor pode usar APIs por trás, mas MCP define outra camada de interação.

Preciso usar um modelo específico?

O protocolo não define qual LLM usar. O host precisa implementar MCP e conectar o cliente ao servidor; compatibilidade depende do aplicativo e das capacidades implementadas.

Um servidor MCP pode executar ações?

Sim, ferramentas podem realizar operações. O host e o servidor devem aplicar autorização, menor privilégio, confirmação quando apropriada e auditoria.

MCP é seguro por padrão?

Não. A especificação e as boas práticas descrevem controles, mas segurança depende do host, servidor, transporte, credenciais, escopos e revisão humana.

Como o n8n usa MCP?

O node MCP Client pode conectar workflows a ferramentas de servidores compatíveis. Verifique a documentação da versão, autenticação, transporte e os limites do seu plano antes de implementar.

Fontes e referências