Em março de 2026, o MCP atingiu 97 milhões de downloads mensais de SDK. Saiu de 100 mil no lançamento. Em 14 meses, o protocolo criado pela Anthropic virou a camada de infra padrão para agentes de IA, com mais de 10.000 servidores públicos ativos e suporte nativo em Cursor, Windsurf, Claude, GPT e Llama. Mas 97 milhões de downloads não significam que function calling morreu. Significam que você precisa saber quando um serve melhor que o outro.
O Problema com Function Calling em Escala
Function calling é elegante para sistemas pequenos. Você define um schema JSON, o modelo gera a chamada estruturada, seu código executa. Para 1 a 5 tools, funciona perfeitamente. O problema começa quando o sistema cresce.
O overhead é linear: cada request envia o schema de todas as tools disponíveis. Com 10 tools, você dobra o tamanho do contexto. Com 100 tools, a latência explode e o custo de tokens sobe proporcionalmente. Benchmarks publicados pela Portkey em 2026 mostram cold starts chegando a 2.485ms em sistemas com muitas tools. Não porque o modelo é lento: porque você está enviando um manual inteiro a cada request.
Além disso, function calling é vendor-specific. O schema da OpenAI difere do Google. O da Anthropic tem particularidades próprias. Mudar de modelo significa reescrever a camada de tools do zero.
Dado-chave: Sistemas com function calling e 100+ tools têm overhead que escala linearmente com o número de tools no contexto. O MCP carrega apenas as tools necessárias por interação (fonte: Portkey, 2026).
MCP Não Substitui Function Calling: Ele Padroniza a Execução
Aqui está o ângulo que a maioria dos tutoriais erra. MCP e function calling não são concorrentes. Function calling é a fase 1, geração de intenção: o modelo decide que quer chamar uma tool e gera o JSON. MCP é a fase 2, infra de execução: o protocolo que padroniza como essa chamada é roteada, descoberta e executada, independente de qual modelo gerou a intenção.
Você pode ter um call_mcp_tool como function call. O modelo gera qual MCP server chamar, a função roteia via protocolo. Os dois coexistem no mesmo sistema.
O que MCP resolve que function calling não resolve:
- Descoberta dinâmica: tools são descobertas em runtime, sem modificar o código do agente
- Portabilidade: mesmo servidor MCP funciona com Claude, GPT e Llama sem reescrever nada
- Modularidade: adicionar ou remover uma integração não toca no core do agente
- Escala: carrega só as tools relevantes para o contexto atual
Quando Usar MCP e Quando Function Calling Ainda Vence?
A escolha depende de três variáveis: quantidade de tools, necessidade de portabilidade entre modelos e complexidade esperada do sistema ao longo do tempo.
| Cenário | Recomendação | Por quê |
|---|---|---|
| 1 a 5 tools, modelo fixo, sistema simples | Function calling direto | Menos infra, latência mínima, zero overhead adicional |
| 10+ tools, crescimento esperado | MCP | Evita contexto gigante, escala sem reescrever a camada de tools |
| Multi-modelo (Claude + GPT + Llama) | MCP | Portabilidade nativa, um servidor atende todos os modelos |
| Equipes separadas por domínio de integração | MCP | Cada time publica seu server independente, o agente consome via protocolo |
| Agente de voz, latência crítica (abaixo de 100ms) | Function calling ou MCP local | MCP via rede adiciona 30 a 50ms; MCP local (stdio) adiciona menos de 1ms |
Function Calling: Implementação Direta
// Simples, sem infra extra, ideal para sistemas com poucas tools
const tools = [
{
name: "buscar_pedido",
description: "Busca status de pedido pelo ID",
input_schema: {
type: "object",
properties: {
pedido_id: { type: "string", description: "ID do pedido" }
},
required: ["pedido_id"]
}
}
];
const response = await anthropic.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 1024,
tools,
messages: [{ role: "user", content: "Status do pedido #12345?" }]
});
MCP: Descoberta Dinâmica de Tools
// O agente descobre tools do servidor MCP dinamicamente em runtime
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
const client = new Client({ name: "meu-agente", version: "1.0.0" });
await client.connect(new StdioClientTransport({
command: "node",
args: ["./servidor-pedidos.js"]
}));
// Tools descobertas em runtime, não hardcoded no agente
const { tools } = await client.listTools();
const response = await anthropic.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 1024,
tools: tools.map(t => ({
name: t.name,
description: t.description,
input_schema: t.inputSchema
})),
messages: [{ role: "user", content: "Status do pedido #12345?" }]
});
A diferença é sutil no código, mas estrutural na arquitetura: no segundo exemplo, um novo servidor MCP publicado pela equipe de CRM fica disponível no agente automaticamente. Sem pull request no repositório do agente.
O Que os Números de 2026 Dizem Sobre Performance
O argumento mais comum contra MCP é overhead de latência. Os dados colocam isso em perspectiva:
- MCP local (stdio transport): menos de 1ms de overhead. Invisível para o usuário.
- MCP via rede (SSE/HTTP): 30 a 50ms em média. Para chatbots de texto, imperceptível.
- MCP enterprise gateway: sub-3ms a 5.000 requisições por segundo com gateway otimizado.
- Cache de tool calls: cold start de 2.485ms vira 0,01ms no hit de cache. Redução de 41x.
Para a maioria dos casos de uso de negócio, o overhead do MCP some na latência de rede e de processamento do modelo. Para agentes de voz, onde cada 50ms é perceptível pelo usuário, function calling com modelo único ainda é a escolha mais segura.
MCP na Verboo: Sem Gerenciar Servidor
A Verboo suporta MCP Servers nativamente. Você aponta o servidor MCP existente (GitHub, Notion, seu próprio CRM, qualquer serviço com server publicado) e o Assistente descobre as tools automaticamente. Sem escrever schemas manualmente. Sem manter lista de tools no código. A configuração fica na aba Integrações do seu Assistente em verboo.ai/lab.
Com mais de 390 empresas na plataforma e 27 milhões de mensagens processadas, a Verboo já roda essa arquitetura em produção com latência abaixo de 500ms de ponta a ponta. A maioria dos sistemas que chegam na Verboo vêm de implementações com function calling ad hoc, schemas duplicados e integrações frágeis. MCP nativo significa que cada nova integração não exige modificar o código do Assistente.
Segundo o relatório State of MCP da Zuplo (2026), 41% das organizações de software já estão em alguma etapa de produção com MCP. O ecossistema tem mais de 10.000 servidores públicos. A curva de adoção passou do ponto de inflexão.
Se você está começando um projeto de agente agora, a pergunta não é "devo usar MCP?". É "quantas tools tenho hoje e quantas terei em 6 meses?". Se a resposta for mais de 5, a decisão já está tomada.
A Verboo já opera nesse modelo. Conheça a plataforma.
