O que é MCP? Como o Model Context Protocol conecta agentes e ferramentas

Um modelo de IA sabe gerar texto. Mas como ele consulta seu CRM, lê documentação interna, cria uma issue ou acessa um banco sem cada aplicação inventar uma integração diferente?

Esse é o problema que o MCP — Model Context Protocol tenta padronizar.

MCP é um padrão aberto para conectar aplicações de IA a ferramentas, dados e capacidades externas.

Ele cria uma linguagem comum entre aplicações que hospedam modelos e sistemas que disponibilizam recursos para esses modelos.

Mas MCP não é uma API que substitui todas as APIs. Também não é um agente, um modelo ou uma camada automática de segurança.

Ele é uma interface de integração.

O problema que MCP resolve

Sem uma camada comum, um agente pode implementar cada integração diretamente:

agente
 ├── GitHub
 ├── banco
 ├── documentação
 ├── tickets
 └── arquivos

Funciona. O problema aparece quando cada cliente ou framework cria seu próprio formato para descobrir ferramentas, descrever argumentos, executar chamadas e retornar resultados.

MCP propõe uma interface comum:

aplicação de IA
      ↓
     MCP
      ↓
servidores MCP
 ├── Git
 ├── banco
 ├── docs
 └── sistemas internos

O ganho não é mágica. É padronização e portabilidade.

A analogia do USB-C ajuda — com limites

Uma analogia comum compara MCP ao USB-C: dispositivos diferentes conseguem conversar por uma interface conhecida.

Ela ajuda a entender portabilidade, mas não segurança.

Conectar não significa autorizar qualquer operação, confiar no servidor ou permitir acesso irrestrito.

MCP padroniza comunicação. Identidade, autorização, política e segurança continuam sendo responsabilidade da arquitetura.

Host, client e server

Uma visão simplificada:

usuário
  ↓
MCP host
  ↓
MCP client
  ↓
transporte
  ↓
MCP server
  ↓
sistema externo

MCP host

O host é a aplicação onde a experiência acontece: IDE, agente, chat ou aplicação própria. Ele coordena conexões e decide quais capacidades ficam disponíveis.

MCP client

O client mantém uma conexão com um MCP server. Pode negociar versão e capacidades, descobrir tools, ler resources, obter prompts e executar chamadas.

Um host pode manter vários clients:

host
 ├── client → Git
 ├── client → banco
 └── client → documentação

MCP server

O server expõe capacidades. Pode rodar localmente ou remotamente e frequentemente fica entre o agente e um sistema já existente.

MCP server CRM
      ↓
API do CRM
      ↓
dados e ações

Portanto, MCP não precisa substituir a API do sistema. O servidor pode apresentar uma parte dela de forma padronizada para aplicações de IA.

Tools: ações que o modelo pode executar

Tools representam operações como:

buscar_cliente(email)
criar_issue(titulo, descricao)
consultar_pedido(id)
executar_teste(suite)

O servidor publica as definições. O client as descobre e o modelo pode decidir quando chamar uma delas.

pedido do usuário
      ↓
modelo escolhe tool
      ↓
MCP client
      ↓
MCP server
      ↓
sistema
      ↓
resultado

No artigo Agentes de IA: o que são, como funcionam e como criar um, vimos que tools transformam um modelo que apenas responde em um sistema capaz de agir. MCP pode ser a camada padronizada pela qual essas tools chegam ao agente.

Resources: informação acessível

Resources representam conteúdo ou dados que o client pode ler.

Exemplos conceituais:

file:///projeto/README.md
docs://politica/reembolso
schema://database/customers

Uma tool é orientada a uma operação. Um resource é orientado a conteúdo acessível.

Prompts: templates reutilizáveis

Servidores também podem expor prompts: templates que o usuário pode selecionar no client.

/revisar-codigo
/analisar-incidente
/resumir-documento

Nos SDKs oficiais, prompts são uma capacidade distinta. Normalmente o usuário escolhe o template, enquanto tools são capacidades que o modelo pode decidir chamar.

MCP não é function calling

Os conceitos se encontram, mas não são iguais.

Com function calling, sua aplicação fornece tools ao modelo e executa a função escolhida.

Com MCP, existe uma camada padronizada de descoberta e comunicação com servidores externos.

Function calling ajuda o modelo a escolher uma ferramenta disponível. MCP ajuda aplicações de IA a descobrir e acessar capacidades externas por uma interface comum.

Os dois podem trabalhar juntos.

MCP também não substitui REST API

Imagine:

POST /tickets
GET /customers/{id}

Um MCP server pode usar essa API internamente:

agente → MCP → server → REST API → serviço

Talvez a API tenha 180 endpoints, mas o agente precise apenas de quatro capacidades bem definidas.

Essa redução pode melhorar clareza, segurança e decisão do modelo.

Por que MCP ficou importante para agentes?

Agentes precisam de ferramentas. Quanto mais agentes e ferramentas existem, mais caro fica criar integração exclusiva para cada combinação.

Sem padrão:

agente A × serviço X
agente A × serviço Y
agente B × serviço X
agente B × serviço Y

Com uma interface comum:

hosts compatíveis
       ↕
      MCP
       ↕
servers compatíveis

Isso reduz acoplamento sem eliminar o trabalho de integração.

Um exemplo real: documentação

A OpenAI mantém atualmente um MCP server público de documentação. Clientes compatíveis podem pesquisar e ler documentação oficial durante o trabalho.

agente de código
      ↓
MCP
      ↓
documentação oficial

O servidor é somente leitura.

Esse é um bom princípio: exponha apenas a capacidade necessária.

Exemplo: CRM

Um servidor MCP para CRM poderia expor:

buscar_conta
listar_oportunidades
criar_nota
criar_tarefa

O agente consegue pesquisar uma conta e preparar um follow-up sem receber permissão para excluir clientes, alterar preços ou fechar contratos.

O protocolo permite conexão. Sua arquitetura define poder.

Como client e server conversam?

Os SDKs atuais suportam cenários como:

stdio

O servidor roda como processo local e conversa por entrada/saída padrão. É útil para filesystem, CLI e ferramentas de desenvolvimento.

Streamable HTTP

O servidor é acessado por HTTP. É útil para serviços remotos e integrações compartilhadas.

A escolha muda requisitos de rede, autenticação, disponibilidade e segurança.

Descoberta é parte central

Um client pode descobrir quais tools o servidor oferece.

As definições podem conter:

• nome;
• descrição;
• schema de entrada;
• schema de saída.

Isso permite trabalhar com servidores sem codificar cada tool manualmente no host.

Mas descoberta dinâmica também exige controle.

A descrição da tool é engenharia

Compare:

process_data(input)

com:

buscar_pedido_por_numero(numero)

Quanto mais clara e estreita a ferramenta, menos o modelo precisa adivinhar.

Um MCP server não deveria ser simplesmente sua API inteira convertida mecanicamente em centenas de tools.

Menos tools pode ser melhor

Um agente com 150 ferramentas enfrenta mais ambiguidade que um agente com 12 capacidades bem definidas.

Menos tools podem significar:

• menos contexto;
• menos escolhas erradas;
• menor superfície de segurança;
• avaliações mais simples.

Antes de expor uma capacidade, pergunte:

o agente realmente precisa disso?

Segurança: MCP é uma fronteira de confiança

Quando o servidor dá acesso apenas a documentação pública, o risco é limitado.

Quando conecta e-mail, arquivos, CRM, banco, infraestrutura ou pagamentos, a situação muda.

Uma interpretação errada do modelo pode virar ação.

Por isso, trate MCP como uma fronteira de confiança.

Menor privilégio

Se o agente precisa ler pedidos, não dê permissão para excluir pedidos.

Se precisa criar rascunho, não dê permissão para enviar.

Aprovação humana

Em produtos e APIs compatíveis, chamadas sensíveis podem exigir aprovação explícita.

agente prepara
      ↓
tool sensível
      ↓
aprovação
      ↓
execução

Prompt injection continua existindo

Se um agente lê conteúdo externo e possui tools poderosas, esse conteúdo pode tentar induzi-lo a executar ações indevidas.

MCP não resolve isso sozinho.

Você ainda precisa de:

• separação entre instruções e dados;
• allowlist de tools;
• autorização;
• validação;
• aprovação;
• isolamento;
• auditoria.

Padronização de transporte não é política de segurança.

Cuidado com servidores de terceiros

Antes de conectar um servidor, avalie:

• quem opera;
• código-fonte;
• permissões;
• dados enviados;
• autenticação;
• logs;
• atualização;
• dependências.

O Official MCP Registry ajuda na descoberta. Presença no registry, porém, não equivale a auditoria completa de segurança.

MCP local é automaticamente seguro?

Não.

Um processo local pode ter acesso a arquivos, shell, credenciais e variáveis de ambiente.

Local descreve onde roda. Não prova em quem confiar.

Quando MCP faz sentido?

Considere MCP quando:

• a mesma capacidade deve funcionar em múltiplos hosts;
• integrações precisam ser descobertas dinamicamente;
• você está construindo um ecossistema de tools;
• quer desacoplar agente e implementação;
• precisa conectar ferramentas locais e remotas por um contrato comum.

Quando pode ser exagero?

Se sua aplicação possui duas tools internas, um único consumidor e function calling já resolve o problema, adicionar MCP pode ser apenas mais uma camada.

Não adote protocolo porque está em alta.

Adote quando portabilidade e desacoplamento pagam a complexidade.

Como criar seu primeiro MCP server

1. Escolha uma capacidade estreita

Comece com algo como:

consultar documentação interna.

Não:

administrar toda a empresa.

2. Defina o que será exposto

search_docs(query)
get_document(id)

3. Use um SDK oficial

O ecossistema MCP mantém SDKs para diferentes linguagens. A linha v2 atual do SDK TypeScript implementa a especificação de 2026-07-28.

4. Escolha o transporte

Local: stdio.

Remoto: Streamable HTTP.

5. Defina schemas claros

Prefira operações específicas e argumentos tipados.

6. Teste com um client

Verifique descoberta, chamadas, erros, timeout, argumentos inválidos e permissões.

7. Comece read-only

Uma primeira versão que apenas pesquisa documentação ou consulta dados é mais segura para aprender o protocolo.

Depois amplie gradualmente.

MCP torna um sistema agentic?

Não.

Você pode usar MCP sem construir um agente autônomo e pode construir um agente sem MCP.

agente
  ↓
precisa de tools?
  ↓
MCP pode ser uma interface

MCP é infraestrutura de integração.

Comportamento agentic é arquitetura de decisão.

MCP, n8n e automação

Esse encontro é particularmente interessante.

Um workflow pode disponibilizar uma capacidade estreita:

criar_lead
gerar_relatorio
consultar_estoque

Um agente pode chamar essa capacidade por uma interface padronizada, enquanto o workflow mantém lógica determinística e credenciais fora do modelo.

agente
  ↓
MCP
  ↓
capacidade controlada
  ↓
workflow
  ↓
sistemas reais

Isso combina:

• decisão probabilística do agente;
• execução determinística do workflow.

O padrão que eu prefiro

Para ações relevantes:

modelo decide
      ↓
MCP expõe capacidade estreita
      ↓
software valida
      ↓
sistema executa

Quando necessário, adicione aprovação humana antes da execução.

O modelo não precisa possuir a chave do reino.

Ele precisa da ferramenta certa.

Checklist antes de conectar um MCP server

Pergunte:

• Quem opera este servidor?
• Que tools ele expõe?
• Quais dados consegue ler?
• O que consegue modificar?
• Quais credenciais usa?
• O modelo precisa de todas essas capacidades?
• Ações sensíveis exigem aprovação?
• Existe log?
• Posso revogar acesso?
• Qual é o impacto de uma decisão errada?

Se essas respostas não estão claras, a integração ainda não está pronta para produção.

O que MCP realmente muda

MCP não torna modelos mais inteligentes.

Ele torna capacidades mais portáveis e descobríveis.

Isso desloca a integração de:

“como programo esta ferramenta especificamente para este agente?”

para:

“como exponho esta capacidade de forma que diferentes hosts compatíveis possam utilizá-la?”

Quanto mais software for operado por modelos, maior o valor de contratos comuns para conectar contexto, dados, ferramentas e ações.

Mas a regra continua:

conectar é fácil; conectar com o poder certo, os limites certos e evidência suficiente é engenharia.

Próximo nível

Depois de entender host, client, server, tools e resources, o passo seguinte é usar MCP em um fluxo real.

No n8n AI Mastery, a continuação é prática: workflows, APIs, agentes, MCP, memória, observabilidade e produção trabalhando como um sistema.

O próximo artigo deste cluster entra justamente na base dessa jornada: n8n — o que é, como funciona e quando usar.

CURADORIA SEMANAL

Uma curadoria útil, uma vez por semana

Receba os melhores conteúdos sobre negócios, tecnologia e marketing — sem ruído e sem spam.

Website

Nome opcional Seu melhor e-mail

Quero receber a curadoria semanal e aceito o uso destes dados conforme a Política de Privacidade. Posso cancelar a qualquer momento. Quero receber a curadoria →