Model Context Protocol (MCP) explicado de forma clara – com exemplo em n8n

Quem constrói agentes de IA conhece o problema: para cada função de um serviço ligado é preciso definir uma ferramenta própria. Procurar, criar, alterar e apagar uma entrada de calendário – são logo quatro blocos separados, e isso apenas para um único serviço. Com muitas ligações, o esforço de manutenção cresce na mesma proporção. O Model Context Protocol (MCP) segue outra abordagem: normaliza a forma como um modelo de linguagem comunica com um serviço – e reduz drasticamente o número de blocos necessários. Este artigo resume o conceito e um exemplo prático concreto com n8n.

O que o MCP resolve

A ideia base do Model Context Protocol está no nome: um modelo de linguagem deve compreender o contexto de uma aplicação. Em concreto: o que faz esta aplicação? Para que serve? E como executo ações dentro dela?

Classicamente, ao construir agentes liga-se cada ferramenta individualmente – cada função é um bloco próprio. No Google Calendar, por exemplo: uma ferramenta para procurar entradas, outra para atualizar, outra para apagar, outra para criar. Quatro funções para um serviço. Em agentes complexos com muitos serviços ligados, isto soma rapidamente dezenas de blocos.

Servidor, cliente e o esquema uniforme

O MCP trabalha com dois papéis:

• Servidor MCP: coloca-se à frente do serviço propriamente dito (p. ex. Airbnb ou Google Calendar) e descreve como se pode interagir com esse serviço.
• Cliente MCP: fica no agente e consulta e invoca as funções do servidor.

Na implementação atual – por exemplo no n8n – bastam para isso dois passos em vez de muitas ferramentas isoladas:

1. List Tools (listar): o agente pergunta ao servidor que funções estão disponíveis.
2. Execute Tool (executar): o agente invoca uma função concreta com os parâmetros adequados.

O decisivo é o esquema uniforme. Independentemente do serviço que esteja por trás: a resposta a um pedido List Tools tem sempre a mesma estrutura. Contém, por função, o nome, uma descrição e um esquema com os parâmetros permitidos. Os conteúdos e os parâmetros diferem de serviço para serviço – a estrutura mantém-se constante. É exatamente isso que o protocolo define e normaliza.

Um exemplo com a ferramenta Airbnb

Se perguntarmos ao agente que possibilidades oferece a ferramenta Airbnb, ele vai buscar a lista de funções através da própria ferramenta List Tools. De volta vêm, entre outras:

• Airbnb Search: pesquisa de ofertas com filtros e paginação – por exemplo localização, data de check-in e check-out, número de adultos, crianças, bebés e animais de estimação, bem como intervalo de preços.
• Airbnb Listing Details: informação detalhada sobre uma oferta específica através do respetivo listing ID.

O agente não precisou de receber nada previamente definido – obteve por si próprio as funções disponíveis, as suas descrições e o esquema de parâmetros. No esquema vê-se, por exemplo, um campo de texto location (cidade, região, etc.), os campos de data para check-in e check-out, o número de adultos e o preço mínimo e máximo.

Se depois fizermos um pedido concreto – por exemplo um alojamento em Banguecoque para seis pessoas até 50 euros por noite –, o agente procede em duas fases: chama primeiro List Tools (não guardou nada, porque não há memória ativa), reconhece pelo esquema os parâmetros necessários e executa a pesquisa através de Execute Tool. O resultado – por exemplo um alojamento com três camas por cerca de 35 euros por noite – regressa, e isto com apenas duas ferramentas adicionadas. Se o Airbnb oferecesse mais funções, por exemplo para gerir anúncios próprios, estas seriam cobertas pelo mesmo esquema, sem definir mais blocos.

Como reproduzir o MCP no n8n

Os passos seguintes mostram a configuração com o exemplo do Airbnb. Presta-se bem a experiências, porque não é necessária qualquer chave de API.

1. Definir a variável de ambiente: defina N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE como true. Isso permite que os nós da comunidade acedam a ferramentas. Numa instalação com Docker (p. ex. num servidor Hetzner), introduza isto na secção environment do ficheiro docker-compose e reinicie a instância.
2. Criar o AI-Agent: crie um AI-Agent e associe-lhe um modelo (no vídeo, GPT-4.1 Mini).
3. Instalar o nó da comunidade: em Settings → Community Nodes instale o pacote n8n-nodes-mcp e confirme o aviso sobre a instalação de código não verificado proveniente de fontes públicas.
4. Adicionar a ferramenta de cliente MCP: no sinal de mais junto a Tools procure por „MCP“. Atenção: não confundir com a MCP Client Tool própria do n8n – a variante da comunidade reconhece-se pelo símbolo da caixa e é atualmente mais completa.
5. Criar as credenciais: como tipo de ligação existem Command Line, Server-Sent Events e HTTP Streamable. No exemplo fica-se por Command Line. Os valores corretos estão no repositório do respetivo servidor MCP, na secção sobre a instalação. Para o Airbnb: comando npx, argumentos introduzidos passo a passo – -y, o pacote @openbnb/mcp-server-airbnb e, opcionalmente, --ignore-robots-txt.

Nota sobre robots.txt: a opção --ignore-robots-txt ignora as regras de acesso de um site. Para uma demonstração é aceitável – em ambientes produtivos deve respeitar o robots.txt dos respetivos serviços.

Configurar as duas operações

De seguida precisa de duas ferramentas de cliente MCP com operações diferentes:

• List Tools: dê à ferramenta o nome „Airbnb List Tools“, por exemplo, e indique na descrição que serve para obter todas as ferramentas Airbnb disponíveis. Um clique de teste (Execute Step) deve devolver a conhecida lista de funções com nome, descrição e esquema.
• Execute Tool: uma segunda ferramenta de cliente MCP com a operação Execute Tool. Descrição: para executar ferramentas Airbnb, que podem ser listadas através da ferramenta List Tools. O nome da ferramenta é passado como expression, para que o agente decida sozinho que função invoca; os parâmetros da ferramenta deixa-os livres, para que ele os determine também.

Depois de arrumar e guardar, o agente pode ser testado – por exemplo novamente com o pedido de Banguecoque. Vai buscar a lista de funções, devolve-a ao modelo, decide-se pela pesquisa e entrega alojamentos adequados. Exatamente o comportamento da parte conceptual, agora no seu próprio fluxo de trabalho.

Para além do n8n – e uma palavra sobre segurança

O MCP não se limita a plataformas de automatização. Também aplicações de desktop como o Claude Desktop se podem ligar a servidores MCP. Assim é possível delegar tarefas no chat a programas instalados localmente – um exemplo muito citado é o controlo do software 3D Blender por MCP, em que uma pessoa sem conhecimentos de Blender cria renderizações. O servidor MCP corre localmente, o modelo de linguagem continua a funcionar através do serviço na nuvem.

Com todo o entusiasmo, vale o seguinte: o MCP é um desenvolvimento recente. Já existem preocupações de segurança e foram encontradas falhas de segurança. Sobretudo em ambientes produtivos, a tecnologia deve ser usada com cautela – vale a pena acompanhar a evolução antes de assentar processos críticos sobre ela.

Conclusão

O Model Context Protocol é uma abordagem pragmática de normalização: um modelo de linguagem aprende, através de um servidor MCP, o que um serviço sabe fazer e como se fala com ele – em vez de predefinir cada função individualmente. Para agentes de IA complexos isso significa visivelmente menos blocos e menos manutenção; no exemplo com n8n bastam dois passos: listar e executar. A abordagem é convincente, mas ainda recente. Quem a experimentar deve começar por serviços não críticos e, em ambientes produtivos, levar a sério as questões de segurança em aberto.

Fonte: Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch) – canal de YouTube Philip Thomas, em alemão.