MCP vs function calling: qual a diferença e quando usar cada um

Quem já trabalha com tool calling cedo ou tarde faz a pergunta: o MCP é só function calling com um nome novo? A resposta curta é não. Eles operam em camadas diferentes e se completam.

Function calling é o mecanismo pelo qual o modelo pede uma ferramenta. MCP, ou Model Context Protocol, é a camada que padroniza como essas ferramentas são expostas e descobertas, e ela usa function calling por baixo.

Este é um artigo curto e direto, para desfazer de uma vez por todas essa confusão. Entenda o que é cada um, a relação entre os dois, por que o MCP existe mesmo já havendo function calling, e quando cada abordagem faz sentido.

O MCP é function calling renomeado?

Não, o MCP não é function calling renomeado e não o substitui. Eles participam de camadas distintas.

• Function calling é uma capacidade do modelo: a forma como ele expressa que quer usar uma ferramenta.
• MCP é uma camada de infraestrutura: o padrão que torna esse pedido portável, descobrível e executável entre sistemas e fornecedores diferentes.

Um é mecanismo, o outro é protocolo. Longe de competirem, o MCP se apoia no function calling para funcionar.

O que é function calling

Function calling é uma capacidade do modelo de linguagem. Diante de um conjunto de ferramentas descritas, em vez de responder em texto livre, o modelo gera uma saída estruturada, em geral JSON, pedindo a execução de uma ferramenta com certos argumentos.

Function calling é, portanto, o mecanismo de decisão e de expressão do modelo, o ato de pedir uma ferramenta.

Cada grande fornecedor, como OpenAI, Anthropic e Google, oferece isso com um schema e um padrão de invocação próprios.

O que é MCP?

MCP é um padrão aberto, no modelo cliente servidor, construído sobre JSON-RPC 2.0, que define como as ferramentas são descobertas, invocadas e gerenciadas entre aplicações e modelos. Em vez de embutir a lógica da ferramenta dentro do aplicativo, o MCP expõe as capacidades por servidores, que os clientes podem descobrir e usar.

Um ponto em específico já mostra que o MCP é mais amplo do que o function calling: ele tem três primitivas, tools, resources e prompts. Sendo que resources e prompts não têm equivalente direto no function calling puro.

Para entender o conceito e a arquitetura em detalhe, leia o artigo o que é MCP.

Como os dois trabalham juntos

Aqui está o ponto central: o MCP usa function calling por baixo. O fluxo real de uma chamada tem cinco passos:

1. O cliente MCP conecta ao servidor MCP e pede a lista de ferramentas, descobrindo o que existe e o schema de cada uma.
2. O cliente traduz essas definições para o formato que o mecanismo de function calling do modelo espera.
3. O modelo, vendo as ferramentas, decide chamar uma e gera a chamada estruturada. Este passo é o function calling.
4. O cliente MCP roteia a chamada para o servidor, que executa e devolve o resultado.
5. O resultado volta para o modelo.

Ou seja, function calling é o passo 3, o modelo expressando a intenção. O MCP são os passos 1, 2, 4 e 5: a descoberta, a tradução, o roteamento e a execução padronizados.

O cliente MCP funciona como um tradutor entre o padrão do servidor e o schema de function calling do modelo.

O elo entre o modelo e o cliente é function calling. O elo entre o cliente, o servidor e a ferramenta é MCP. São camadas encaixadas, não alternativas.

A tabela resume onde cada um atua:

Por que o MCP existe, se já há function calling

Se todo fornecedor já suporta function calling, por que criar o MCP?

A resposta é a fragmentação. Cada fornecedor tem o seu schema e o seu padrão. Trocar de um modelo para outro significa reescrever as definições de ferramenta. Usar a mesma ferramenta em dois agentes de fornecedores diferentes significa manter duas implementações.

O MCP resolve isso ao permitir definir a ferramenta uma única vez, no servidor MCP, e usá-la em qualquer modelo compatível. É o mesmo papel de padronização que o REST teve para os serviços web e o Docker para o deploy. Além da portabilidade, o MCP acrescenta a descoberta dinâmica, em que o agente descobre as ferramentas em tempo de execução em vez de recebê-las embutidas no prompt a cada requisição, e uma melhor gestão de contexto quando há muitas ferramentas, já que não precisa enviar o schema de todas em toda chamada.

Quando usar cada um

A escolha depende da escala e do cenário:

• Function calling puro é mais simples, leve e um pouco mais rápido em uma chamada única, sem o salto para um servidor. Bom para agentes simples, com poucas ferramentas, em um único fornecedor, ou para um protótipo.
• MCP compensa quando há muitas ferramentas, vários fornecedores, necessidade de portabilidade, de segurança no servidor e de governança. Ele adiciona um salto de servidor e alguma latência, em troca dessa padronização.

A regra prática:

• Poucas ferramentas, um fornecedor, protótipo, fique no function calling.
• Muitas ferramentas, multi fornecedor, produção, use MCP.

E os dois convivem: boa parte das implementações de produção usa ambos, o MCP expondo as ferramentas e o modelo as invocando pelo seu mecanismo de function calling.

Para ver como isso se compara a outras formas de conectar dados a uma IA, veja também MCP vs API e RAG vs MCP.

Exemplo real

Um caso concreto deixa a relação clara. O servidor MCP da Partnr usa tool calling por baixo. Ele expõe as ferramentas de dados financeiros de forma padronizada pelo MCP, e qualquer modelo compatível as invoca pelo seu próprio mecanismo de function calling.

Na prática, isso significa definir a integração uma vez e usá-la com o Claude, com modelos da OpenAI ou com outro cliente compatível, sem reescrever a definição de ferramenta para cada um.

É o argumento da padronização aplicado a dados de mercado, fundamentalistas e macroeconômicos brasileiros: o mesmo servidor serve a qualquer agente, em vez de uma implementação de function calling por fornecedor.

Conclusão

MCP e function calling não são a mesma coisa nem concorrem. Function calling é como o modelo pede uma ferramenta. MCP é a camada que padroniza como as ferramentas são expostas, descobertas e executadas, e que usa o function calling por baixo para operar. Um é mecanismo, o outro é infraestrutura, e juntos formam o caminho completo de uma chamada.

Na hora de decidir, pese a escala. Poucas ferramentas em um só fornecedor pedem o function calling direto. Muitas ferramentas, vários modelos e um ambiente de produção pedem o MCP por cima. Como quase sempre, a resposta madura não é um ou outro, e sim os dois no seu devido lugar.