Blog

Integração 1‑a‑1 não escala.
MCP existe para reduzir o “N×M” de conectar agentes a ferramentas e dados.

Quem já tentou montar um “assistente interno” sabe o problema: cada agente precisa conversar com várias fontes (docs, banco, Git, CRM, tickets). Sem padrão, você cai num cenário em que cada integração vira um projeto.

O Model Context Protocol (MCP) surgiu como um padrão aberto para criar conexões seguras e reutilizáveis entre aplicações com IA e fontes de dados/ferramentas. A própria Anthropic descreve o MCP como um padrão para permitir conexões de duas vias entre fontes de dados e ferramentas de IA.

O que você vai ver aqui

• O que é MCP (sem buzzword)
• Como ele se relaciona com tool calling
• Arquitetura MCP: cliente, servidor e recursos/ferramentas
• Quando faz sentido adotar (e quando é exagero)
• Checklist de segurança para não criar “agência excessiva”

MCP em uma frase

MCP é um protocolo para que:

• você exponha dados/ferramentas por meio de servidores MCP
• agentes e apps de IA atuem como clientes MCP e conectem nesses servidores
• a integração siga um padrão (em vez de cada par cliente/ferramenta ser uma solução única)

MCP vs tool calling: qual a diferença?

Eles se complementam, mas não são a mesma coisa.

Tool calling (function calling) é o mecanismo pelo qual um LLM chama uma função descrita com schema (geralmente JSON).
MCP é um padrão para como disponibilizar ferramentas e recursos de forma consistente e conectável.

Um jeito simples de pensar:

• tool calling: “como o modelo pede para executar algo”
• MCP: “como eu publico e conecto ferramentas/recursos em um ecossistema”

Se você ainda não tem tool calling bem estruturado, comece por ele: Tool calling: integração segura.

Quando adotar MCP

MCP tende a fazer sentido quando:

• você tem múltiplas ferramentas e múltiplos agentes/apps
• precisa de um jeito padrão de expor recursos (documentos, dados, ações)
• quer trocar o agente/modelo sem reescrever todas as integrações
• quer governança por “servidor de integração” (controle, logs, limites)

MCP pode ser exagero quando:

• você tem 1 app e 1 integração simples
• seu caso é “só RAG” com uma base de conhecimento
• sua maturidade de segurança/observabilidade ainda é baixa

Segurança: MCP não elimina risco (ele muda onde o risco vive)

Quando você conecta agentes a ferramentas, o risco principal é o agente fazer mais do que deveria — por permissão, autonomia ou falta de validação.

Isso aparece no OWASP GenAI como “agência excessiva”. Algumas medidas práticas:

1) Minimizar ferramentas e permissões

• publique só o necessário
• prefira ferramentas read‑only quando possível
• aplique escopo por usuário/tenant (não use “conta master”)

2) Evitar “ferramentas abertas demais”

Se um servidor expõe algo do tipo “executar comando” ou “rodar query livre”, você está criando uma superfície de ataque enorme.

Prefira operações específicas, com schema rígido e allowlists.

3) Validação e autorização continuam no sistema destino

Mesmo usando MCP, a regra não muda:

• autorização é no backend
• validação de input é obrigatória
• logs e auditoria são parte do produto

4) Observabilidade e limites

• logar chamadas por ferramenta, usuário e contexto
• rate limits / budgets (evitar abuso e custo)
• monitorar erros e padrões suspeitos

Se você quiser estruturar isso como disciplina, veja: LLMOps: métricas, logs e evals.

Checklist de adoção (decisão rápida)

• Tenho mais de 3–5 ferramentas e mais de 1 agente/app consumindo?
• Quero um padrão para publicar integrações com governança e auditoria?
• Já tenho autorização, validação e logs bem definidos no backend?
• Tenho maturidade para operar incidentes e fazer rollback?

Se a maioria for “sim”, MCP pode reduzir retrabalho e melhorar consistência.
Se a maioria for “não”, comece com tool calling + RAG bem feitos.

Referências

• Anthropic: Model Context Protocol
• Anthropic Engineering: code execution with MCP
• OWASP GenAI: Excessive Agency