{"id":2328,"date":"2025-07-05T10:00:00","date_gmt":"2025-07-05T08:00:00","guid":{"rendered":"https:\/\/pletzenauer.com\/?p=2328"},"modified":"2026-08-05T17:24:43","modified_gmt":"2026-08-05T15:24:43","slug":"model-context-protocol-mcp-n8n","status":"publish","type":"post","link":"https:\/\/pletzenauer.com\/pt-pt\/2025\/07\/05\/model-context-protocol-mcp-n8n\/","title":{"rendered":"Model Context Protocol (MCP) explicado de forma clara \u2013 com exemplo em n8n"},"content":{"rendered":"

Quem constr\u00f3i agentes de IA conhece o problema: para cada fun\u00e7\u00e3o de um servi\u00e7o ligado \u00e9 preciso definir uma ferramenta pr\u00f3pria. Procurar, criar, alterar e apagar uma entrada de calend\u00e1rio \u2013 s\u00e3o logo quatro blocos separados, e isso apenas para um \u00fanico servi\u00e7o. Com muitas liga\u00e7\u00f5es, o esfor\u00e7o de manuten\u00e7\u00e3o cresce na mesma propor\u00e7\u00e3o. O Model Context Protocol (MCP)<\/strong> segue outra abordagem: normaliza a forma como um modelo de linguagem comunica com um servi\u00e7o \u2013 e reduz drasticamente o n\u00famero de blocos necess\u00e1rios. Este artigo resume o conceito e um exemplo pr\u00e1tico concreto com n8n.<\/p>\n

\nO essencial em resumo<\/strong><\/p>\n
    \n
  • O MCP normaliza a forma como um modelo de linguagem compreende o contexto de um servi\u00e7o \u2013 ou seja, o que ele sabe fazer e como se fala com ele.<\/li>\n
  • Em vez de ligar cada fun\u00e7\u00e3o separadamente, basta um servidor MCP<\/em> (\u00e0 frente do servi\u00e7o) e um cliente MCP<\/em> (no agente).<\/li>\n
  • O agente precisa apenas de dois passos: listar<\/em> fun\u00e7\u00f5es (List Tools) e executar<\/em> fun\u00e7\u00f5es (Execute Tool).<\/li>\n
  • No n8n isto reproduz-se com uma vari\u00e1vel de ambiente, um n\u00f3 da comunidade e duas ferramentas de cliente MCP.<\/li>\n
  • O MCP \u00e9 uma tecnologia recente: existem preocupa\u00e7\u00f5es de seguran\u00e7a conhecidas \u2013 em ambientes produtivos conv\u00e9m ter cuidado.<\/li>\n<\/ul>\n<\/div>\n
    \"Compara\u00e7\u00e3o
    Compara\u00e7\u00e3o em duas colunas: \u00e0 esquerda a liga\u00e7\u00e3o cl\u00e1ssica de uma ferramenta por fun\u00e7\u00e3o, com muitos blocos; \u00e0 direita o MCP com apenas dois passos, List Tools e Execute Tool.<\/figcaption><\/figure>\n

    O que o MCP resolve<\/h2>\n

    A ideia base do Model Context Protocol est\u00e1 no nome: um modelo de linguagem deve compreender o contexto<\/strong> de uma aplica\u00e7\u00e3o. Em concreto: o que faz esta aplica\u00e7\u00e3o? Para que serve? E como executo a\u00e7\u00f5es dentro dela?<\/p>\n

    Classicamente, ao construir agentes liga-se cada ferramenta individualmente \u2013 cada fun\u00e7\u00e3o \u00e9 um bloco pr\u00f3prio. No Google Calendar, por exemplo: uma ferramenta para procurar entradas, outra para atualizar, outra para apagar, outra para criar. Quatro fun\u00e7\u00f5es para um servi\u00e7o. Em agentes complexos com muitos servi\u00e7os ligados, isto soma rapidamente dezenas de blocos.<\/p>\n

    Servidor, cliente e o esquema uniforme<\/h2>\n

    O MCP trabalha com dois pap\u00e9is:<\/p>\n

      \n
    • Servidor MCP:<\/strong> coloca-se \u00e0 frente do servi\u00e7o propriamente dito (p. ex. Airbnb ou Google Calendar) e descreve como se pode interagir com esse servi\u00e7o.<\/li>\n
    • Cliente MCP:<\/strong> fica no agente e consulta e invoca as fun\u00e7\u00f5es do servidor.<\/li>\n<\/ul>\n

      Na implementa\u00e7\u00e3o atual \u2013 por exemplo no n8n \u2013 bastam para isso dois passos em vez de muitas ferramentas isoladas:<\/p>\n

        \n
      1. List Tools (listar):<\/strong> o agente pergunta ao servidor que fun\u00e7\u00f5es est\u00e3o dispon\u00edveis.<\/li>\n
      2. Execute Tool (executar):<\/strong> o agente invoca uma fun\u00e7\u00e3o concreta com os par\u00e2metros adequados.<\/li>\n<\/ol>\n

        O decisivo \u00e9 o esquema uniforme<\/strong>. Independentemente do servi\u00e7o que esteja por tr\u00e1s: a resposta a um pedido List Tools tem sempre a mesma estrutura. Cont\u00e9m, por fun\u00e7\u00e3o, o nome, uma descri\u00e7\u00e3o e um esquema com os par\u00e2metros permitidos. Os conte\u00fados e os par\u00e2metros diferem de servi\u00e7o para servi\u00e7o \u2013 a estrutura mant\u00e9m-se constante. \u00c9 exatamente isso que o protocolo define e normaliza.<\/p>\n

        Um exemplo com a ferramenta Airbnb<\/h3>\n

        Se perguntarmos ao agente que possibilidades oferece a ferramenta Airbnb, ele vai buscar a lista de fun\u00e7\u00f5es atrav\u00e9s da pr\u00f3pria ferramenta List Tools. De volta v\u00eam, entre outras:<\/p>\n