MCP vs Function Calling: quando usar cada um (e por que você provavelmente precisa dos dois)

O que é function calling

Function calling (introduzido pela OpenAI em junho de 2023, hoje suportado por Anthropic, Google e modelos open-source via spec OpenAI-compatible) é a capacidade nativa do LLM de gerar, em vez de prosa, uma chamada estruturada a uma função registrada — com nome, argumentos validados contra JSON Schema, e retorno injetado no contexto para a próxima iteração.

Em código (Vercel AI SDK 6, sintaxe simplificada):

const result = await generateText({
  model: "openai/gpt-4o",
  tools: {
    getWeather: tool({
      description: "Retorna previsão do tempo para uma cidade.",
      inputSchema: z.object({ city: z.string() }),
      execute: async ({ city }) => fetchWeather(city),
    }),
  },
  prompt: "Como está o tempo em Goiânia?",
});

O modelo decide quando chamar getWeather, com quais argumentos, e o que fazer com o retorno. O desenvolvedor implementa a função, declara o schema, e o modelo orquestra.

O que é MCP

MCP (Model Context Protocol) é um protocolo aberto lançado pela Anthropic em novembro de 2024 que padroniza como aplicações expõem ferramentas, dados e prompts a clientes que consomem LLMs. É análogo ao LSP (Language Server Protocol) para IDEs: uma interface única que desacopla cliente de provedor.

Antes do MCP, conectar um LLM a, digamos, Jira exigia um desenvolvedor escrever wrappers de function calling no aplicativo cliente. Com MCP, a Atlassian (ou um terceiro) publica um servidor MCP do Jira uma vez; qualquer cliente que fale MCP (Claude Desktop, Claude Code, Cursor, agente customizado) consome esse servidor sem código de integração adicional.

A especificação cobre três primitivos:

• Tools: funções que o LLM pode invocar (equivalente a function calling, mas via protocolo).
• Resources: dados que o LLM pode ler (arquivos, queries de banco, documentação).
• Prompts: templates reutilizáveis (instruções pré-formatadas).

Comparação direta

Quando usar cada um

Use function calling diretamente quando a ferramenta é exclusiva do produto (lógica de negócio proprietária), o conjunto de funções é pequeno (sub-20), e não há necessidade de descoberta dinâmica. Exemplo: agente de suporte que consulta o banco do próprio produto.

Use MCP quando a integração deve ser consumida por múltiplos clientes (Claude Desktop + IDE + agente customizado), quando o conjunto de tools é grande e dinâmico (e.g., expõe todos os endpoints de uma API), quando você está publicando uma integração para terceiros (Stripe, Notion, Linear), ou quando quer desacoplar a evolução das tools do aplicativo cliente.

Arquitetura híbrida: o caso real

Em sistemas IA reais de 2026, function calling e MCP coexistem. Padrão típico:

1. O cliente (agente customizado, escrito em Next.js + Vercel AI SDK) conecta-se a 2 a 5 servidores MCP externos (PostgreSQL read-only do data warehouse, GitHub Enterprise, Linear, Slack).
2. As tools expostas pelos servidores MCP são passadas ao modelo via function calling — o protocolo do modelo continua sendo function calling, mas a fonte dessas funções é remota e padronizada.
3. Tools proprietárias específicas do produto (e.g., createTicketWithCustomWorkflow) são registradas direto no cliente via function calling, sem passar por MCP.

Esse híbrido entrega o melhor dos dois mundos: reutilização e descoberta dinâmica para integrações padronizadas, controle granular para lógica proprietária.

Armadilhas comuns

• Usar MCP para uma tool só: overhead de protocolo, conexão e parsing não justifica. Function calling direto é melhor.
• Expor um banco inteiro via MCP sem guardrails: agente IA com acesso SQL irrestrito é um incidente esperando para acontecer. Use views read-only, row-level security e timeout de query.
• Ignorar versionamento: MCP servers são contratos públicos. Mudança quebrar consumers é custo alto. Versione (HTTP path ou capability negotiation).
• Confiar no modelo para decidir tudo: function calling não substitui validação de input, autorização e auditoria. Modelo erra; o sistema precisa não errar.

Conclusão

Function calling e MCP não competem — operam em camadas diferentes. Function calling é a capacidade do modelo de chamar funções estruturadas. MCP é o protocolo padronizado que expõe ferramentas a clientes que usam function calling. A pergunta correta é quando padronizar uma integração como MCP, não qual escolher.

Na North Studio, o default é function calling para tools exclusivas do produto e MCP para integrações reutilizáveis ou expostas a clientes externos.