A confusão entre MCP e function calling nasce porque os dois aparecem perto do mesmo ponto da arquitetura: o momento em que um modelo precisa sair da geração de texto e usar alguma capacidade externa. Mas eles não resolvem exatamente o mesmo problema. Function calling, ou tool calling, é principalmente um mecanismo para o modelo escolher uma ferramenta e produzir argumentos estruturados. MCP, o Model Context Protocol, é um protocolo para conectar uma aplicação de IA a servidores que expõem ferramentas, recursos e prompts de maneira padronizada.
A distinção mais útil é esta: function calling responde “qual ferramenta o modelo quer usar e com quais argumentos?”. MCP responde “como a aplicação encontra, descreve, acessa e governa capacidades externas de forma interoperável?”. Em uma arquitetura real, essas respostas podem aparecer na mesma execução. O host descobre uma ferramenta por MCP, apresenta essa capacidade ao modelo por uma abstração de tools e, quando o modelo decide usá-la, a chamada percorre o cliente MCP até o servidor. Em outras situações, a ferramenta é uma função local da própria aplicação e não há MCP algum.
A primeira diferença: decisão do modelo não é o mesmo que integração
Em function calling, a aplicação fornece ao modelo uma descrição da ferramenta, normalmente com nome, descrição e parâmetros estruturados por schema. Diante de uma solicitação, o modelo pode responder não com a resposta final, mas com uma chamada indicando a ferramenta e os argumentos. No fluxo clássico de funções próprias, a aplicação recebe essa intenção, executa o código correspondente e devolve o resultado ao modelo para que ele continue.
Isso é importante porque function calling não significa, por si só, que o modelo executou a função. A documentação atual da OpenAI separa explicitamente a decisão da execução no caso de funções controladas pelo cliente: a aplicação recebe a chamada, executa a função e envia o resultado de volta. Outros tipos de ferramenta podem ser hospedados pelo provedor, mas esse é outro arranjo de execução.
MCP entra em uma camada diferente. A especificação 2026-07-28 define uma arquitetura host-cliente-servidor baseada em JSON-RPC. O host é a aplicação que coordena a experiência com o
modelo. Cada cliente MCP se conecta a um servidor específico. O servidor anuncia capacidades que podem incluir tools, resources e prompts. Assim, o protocolo não serve apenas para “chamar função”: ele também padroniza descoberta, leitura de contexto, negociação de capacidades, transporte e aspectos de autorização.
O que function calling faz bem
Function calling é especialmente direto quando a ferramenta pertence à própria aplicação. Imagine um sistema interno com a função consultar_status_pedido, que recebe um order_id. A equipe já conhece o código, controla a autenticação, sabe onde a função roda e não precisa tornar essa integração reutilizável por outros hosts de IA.
Nesse caso, basta declarar a ferramenta para o modelo, definir o schema de entrada e tratar a chamada. O contrato é pequeno e previsível. Se a aplicação tiver cinco ou dez funções estáveis, essa solução costuma ter menos peças operacionais do que introduzir um protocolo adicional.
As APIs modernas ampliaram esse desenho. A OpenAI, por exemplo, hoje oferece mecanismos de tool search para carregar ferramentas sob demanda em determinados modelos, e provedores também possuem ferramentas hospedadas. Isso significa que “descoberta dinâmica” não é exclusividade absoluta do MCP. A diferença é que, sem MCP, esse mecanismo tende a pertencer à API ou ao framework específico do provedor. MCP tenta padronizar a interface entre host e servidores de capacidades independentemente de um único fornecedor de modelo.
O que MCP acrescenta
MCP ganha valor quando a integração deixa de ser apenas uma função conhecida pelo seu aplicativo e passa a ser uma capacidade que diferentes aplicações de IA podem descobrir e usar através de um contrato comum.
Na especificação atual, servidores podem expor tools para ações e consultas, resources para dados contextuais identificados por URI e prompts para templates reutilizáveis. O protocolo também define como o cliente descobre capacidades do servidor. Isso separa a lógica de integração da API específica do modelo e facilita que o mesmo servidor seja consumido por hosts diferentes, desde que ambos implementem a versão e as capacidades compatíveis.
Esse ganho de portabilidade não elimina o trabalho de integração. Alguém ainda precisa implementar o servidor MCP, autenticação, políticas, observabilidade e tratamento de erros. O benefício aparece quando essa camada compartilhada substitui vários adaptadores proprietários ou quando a capacidade precisa ser descoberta por mais de um agente, IDE, assistente ou plataforma.
Um exemplo único, do schema ao resultado
Considere a ferramenta consultar_status_pedido. Ela recebe order_id e retorna status, previsão de entrega e, quando aplicável, código de rastreio. O objetivo do usuário é simples: “Onde está o pedido 84521?”.
Etapa 1: o schema descreve a capacidade
No caminho de function calling, a aplicação inclui a ferramenta consultar_status_pedido entre as tools que o modelo pode usar. O schema informa que order_id é obrigatório e qual tipo de valor é esperado. A descrição deve deixar claro quando a ferramenta é apropriada e o que ela devolve.
No caminho MCP, o servidor também descreve a ferramenta com nome, metadados e schema. A diferença é que essa descrição faz parte de uma interface de servidor que pode ser descoberta pelo cliente MCP. O host não precisa necessariamente ter codificado cada ferramenta individualmente antes da conexão.
Etapa 2: o modelo decide se precisa da ferramenta
Depois de ler a pergunta, o modelo conclui que não consegue responder de forma confiável apenas com o contexto disponível. Ele seleciona consultar_status_pedido e gera o argumento order_id igual a 84521.
Esse é o ponto em que as arquiteturas parecem iguais para quem olha apenas o comportamento do modelo. Em ambas, existe uma ferramenta descrita e uma decisão de chamada. A divergência aparece logo depois: quem possui a ferramenta, como ela foi descoberta e por qual caminho a chamada chega ao executor.
Etapa 3: execução local com function calling
Se consultar_status_pedido é uma função da própria aplicação, o orquestrador recebe a chamada do modelo e executa seu código local ou sua integração direta com o backend. Depois, envia o resultado ao modelo. O modelo transforma o retorno técnico em uma resposta para o usuário.
Aqui, o contrato entre modelo e aplicação é o centro da solução. A aplicação já sabe onde está o executor e como chamá-lo. Não há necessidade de host, cliente e servidor MCP como protocolo separado.
Etapa 4: execução por MCP
Se a mesma capacidade está publicada por um servidor MCP, o host mantém um cliente conectado a esse servidor. O cliente pode descobrir que consultar_status_pedido existe, obter seu schema e disponibilizá-lo na camada de ferramentas do agente. Quando a chamada é autorizada, o cliente envia a requisição MCP ao servidor, que executa a operação e devolve o resultado.
Na versão 2026-07-28, o núcleo do MCP é stateless: cada requisição carrega os metadados necessários de versão e capacidades, em vez de depender de estado implícito de sessão. O transporte padrão pode ser stdio para processos locais ou Streamable HTTP para servidores acessados por HTTP. Em ambos os casos, a semântica do protocolo continua separada da decisão do modelo.
Etapa 5: arquitetura híbrida
Agora suponha que o agente tenha duas classes de capacidade. Uma função local calcula o prazo prometido segundo regras internas, enquanto um servidor MCP da logística fornece o status mais recente do envio. O modelo pode usar a função local e a ferramenta MCP no mesmo fluxo.
É justamente por isso que “MCP ou function calling?” muitas vezes é uma pergunta incompleta. Em um sistema híbrido, function calling pode continuar sendo a forma como o modelo expressa a decisão de usar uma ferramenta controlada pelo aplicativo, enquanto MCP fornece uma superfície padronizada para ferramentas externas. Em APIs que oferecem MCP como tipo de tool hospedada, o provedor pode esconder parte desse ciclo; em SDKs que conectam sessões MCP à lista de ferramentas, a implementação pode usar o mesmo loop de tool calling para encaminhar as chamadas. O detalhe muda por plataforma, mas as responsabilidades conceituais continuam distintas.
MCP não substitui o raciocínio de tool calling
Um servidor MCP não decide sozinho, de forma geral, qual ferramenta o modelo deve usar para atender à intenção do usuário. Ele descreve e oferece capacidades. O host e o modelo continuam participando da seleção e da orquestração.
Também é incorreto tratar MCP como “um catálogo de funções”. Tools são uma parte importante, mas o protocolo inclui resources e prompts, além de recursos de descoberta, transporte, autorização e outras interações entre host, cliente e servidor. Essa amplitude é uma das razões para MCP fazer sentido como protocolo, e não apenas como uma convenção de schema.
Function calling não resolve portabilidade sozinho
Uma definição de função em JSON Schema pode ser muito parecida entre provedores, mas a forma de registrar tools, receber chamadas, devolver resultados, exigir aprovação e manter o loop de execução varia por API. Uma equipe pode escrever adaptadores para cada plataforma e isso pode ser perfeitamente aceitável em um produto fechado.
MCP tenta colocar a integração externa atrás de um contrato comum. A mesma capacidade pode ser exposta por um servidor e consumida por hosts diferentes. Isso reduz acoplamento em cenários com muitos clientes, mas adiciona uma camada operacional que precisa ser justificada.
Matriz de decisão: compare a camada que realmente muda
Portabilidade
Function calling simples tende a ficar acoplado à forma como a aplicação ou o provedor define e entrega tools. É uma boa escolha quando o produto controla as duas pontas e não há necessidade de reutilizar a integração em vários hosts. MCP é mais atraente quando a mesma capacidade precisa ser consumida por diferentes aplicações, agentes ou fornecedores, porque existe um protocolo comum entre host e servidor.
Descoberta dinâmica
No function calling tradicional, a aplicação envia ao modelo um conjunto conhecido de ferramentas. APIs modernas podem carregar ferramentas sob demanda com mecanismos próprios, então essa fronteira ficou menos rígida. MCP, porém, padroniza descoberta de capacidades no nível do servidor. O cliente pode consultar o que o servidor oferece e reagir a mudanças sem que cada ferramenta precise estar codificada individualmente no host.
Execução
Em funções controladas pelo cliente, o modelo pede a chamada e a aplicação executa. Isso oferece controle direto sobre código, rede e tratamento de erros. Com MCP, a execução normalmente pertence ao servidor MCP, embora a conexão possa ser local via stdio ou remota via HTTP. Algumas plataformas também executam o acesso ao MCP como ferramenta hospedada, reduzindo o trabalho do cliente. Portanto, “onde roda?” deve ser respondido pela implementação concreta, não pelo nome da técnica.
Autenticação e aprovação
Function calling define a intenção estruturada da chamada, mas não autentica magicamente o serviço externo. A aplicação ainda precisa proteger credenciais, verificar autorização e decidir quando pedir confirmação ao usuário. MCP possui um framework de autorização para transportes HTTP e atribui ao host responsabilidades de consentimento e políticas. Plataformas que oferecem MCP hospedado também podem adicionar controles de aprovação. Em operações de escrita ou alto impacto, a existência do protocolo não elimina a necessidade de um limite humano claro.
Latência
Uma função local pode ter o caminho mais curto: modelo, aplicação, executor, resultado. Um servidor MCP remoto pode acrescentar descoberta, transporte e mais uma fronteira de rede. Isso não significa que MCP será sempre mais lento. Descoberta e listas de capacidades podem ser cacheadas, e a especificação atual introduz sinais de cache e mecanismos de notificação para evitar consultas desnecessárias. A decisão deve ser medida no fluxo real, especialmente quando a integração remota já exigiria uma API externa de qualquer forma.
Governança
Function calling dá à aplicação um ponto explícito para validar argumentos, aplicar allowlists, registrar chamadas e bloquear ações. MCP amplia a superfície de governança porque o host pode controlar quais servidores e ferramentas são expostos, enquanto cada servidor mantém sua própria política e autenticação. Em ambientes com várias equipes, essa separação pode ajudar; em um sistema pequeno, pode aumentar complexidade sem retorno proporcional.
Quando usar apenas function calling
Escolha uma solução centrada em function calling quando as ferramentas são poucas, estáveis, pertencem à sua aplicação e não precisam ser reutilizadas por vários hosts. Também faz sentido quando a execução deve permanecer estritamente dentro do seu backend e você quer minimizar camadas de protocolo.
Um bom sinal é conseguir responder claramente: “essas funções só existem para este agente, este produto controla o executor e qualquer nova ferramenta será adicionada pelo mesmo time”. Nesse cenário, MCP pode ser uma abstração prematura.
Quando MCP passa a valer o custo
MCP começa a ser mais convincente quando há muitas integrações, quando servidores de capacidades são mantidos por equipes ou empresas diferentes, quando ferramentas precisam ser descobertas dinamicamente ou quando a mesma integração deve funcionar em múltiplos hosts de IA.
Também é útil quando o domínio envolve mais do que ações. Um servidor que oferece recursos de contexto, templates de prompt e ferramentas sob um mesmo protocolo está resolvendo um problema maior do que function calling isolado.
Quando usar os dois
Use uma arquitetura híbrida quando algumas capacidades são locais e específicas do produto, enquanto outras vêm de servidores MCP reutilizáveis. O agente pode receber funções nativas para operações internas de baixa latência e, ao mesmo tempo, acessar ferramentas MCP de parceiros, bancos de dados, sistemas corporativos ou serviços especializados.
As documentações atuais dos principais ecossistemas mostram essa coexistência de formas diferentes. A OpenAI permite combinar remote MCP com outras tools em uma mesma requisição. A Anthropic oferece tool use e um conector MCP para servidores remotos. O SDK do Gemini pode conectar uma sessão MCP ao mecanismo de tools e executar automaticamente o loop de chamadas em cenários suportados. Isso reforça a leitura arquitetural: MCP e function calling são peças que podem se encaixar, não substitutos obrigatórios.
O erro de arquitetura mais comum
O erro mais comum é escolher pela novidade da tecnologia, e não pela fronteira que precisa ser padronizada. Se o problema é apenas permitir que o modelo chame três funções do seu backend, comece pelo mecanismo de tools da plataforma. Se o problema é distribuir uma integração reutilizável para vários hosts, descobrir capacidades e reduzir adaptadores específicos, MCP passa a resolver uma necessidade concreta.
O segundo erro é supor que MCP transfere automaticamente segurança e governança para o protocolo. Não transfere. O host ainda precisa decidir o que expõe ao modelo, o usuário precisa ter controle sobre ações sensíveis e o servidor precisa autenticar e autorizar o que executa. A especificação MCP reforça explicitamente consentimento, fronteiras de segurança e possibilidade de negar invocações.
Uma regra prática para decidir
Pergunte primeiro quem é dono da ferramenta e quantos consumidores independentes ela terá. Se a resposta for “meu aplicativo, um único agente”, function calling tende a ser suficiente. Se a resposta for “uma capacidade compartilhada por vários hosts ou clientes”, MCP merece avaliação. Se houver ferramentas dos dois tipos no mesmo produto, não force uma escolha única: mantenha as funções locais onde elas são mais simples e use MCP onde a portabilidade e a descoberta justificam a camada extra.
Depois, meça o que muda de verdade: quantidade de adaptadores, tempo para adicionar uma integração, custo de autenticação, latência, facilidade de aprovação, rastreabilidade e manutenção. A arquitetura correta não é a que usa mais protocolos; é a que coloca cada responsabilidade na camada certa.
