Servidores MCP vs Function Calling: Escolha Sua Arma

É tentador. Realmente é.

Todo provedor de LLM tem function calling agora. OpenAI tem. Anthropic tem. Google tem. Você escolhe seu favorito, lê a documentação por vinte minutos, define suas funções como JSON schemas e manda ver. Funciona. Sua demo fica ótima. Seus investidores ficam impressionados.

O problema é que "funciona" e "funciona em escala com múltiplos fornecedores" são duas afirmações completamente diferentes. A primeira é uma tarde de terça-feira. A segunda é um emprego em tempo integral.

Quando você conecta function calling diretamente a um único provedor, não está apenas escolhendo um vendor. Está escolhendo o formato de schema dele, as convenções de parâmetros, a semântica de tratamento de erros e o calendário de releases. Está escrevendo código cola que, por definição, não é portável. E faz isso na camada onde portabilidade mais importa — a fronteira entre sua aplicação e a inteligência da qual ela depende.

A maioria das pessoas só percebe quando precisa suportar um segundo LLM. A essa altura, o código cola já fez metástase.

Faça este exercício. Vá até seu codebase e conte as linhas de código que existem unicamente para traduzir entre suas definições internas de ferramentas e o formato de function calling de um provedor específico.

Uma integração? Talvez cem linhas. Gerenciável. Duas integrações? Você começa a notar que OpenAI e Anthropic têm opiniões sutilmente diferentes sobre como expressar parâmetros opcionais. Três? Está mantendo uma matriz de compatibilidade. Cinco? Construiu um framework sem querer.

E os frameworks nunca param de crescer. Cada provedor atualiza sua API todo trimestre. Às vezes adicionam funcionalidades. Às vezes deprecam coisas. Às vezes "melhoram" o formato do schema de maneiras que quebram suas definições existentes em produção às 2 da manhã de um sábado.

O imposto de manutenção do function calling multi-fornecedor não é linear. É combinatório. Cada novo provedor multiplica a superfície. Cada mudança de API cascateia por todas as integrações. Sua camada "simples" de function calling se torna a parte mais frágil do seu stack — o arquivo que todo mundo tem medo de tocar.

Ninguém coloca esse custo no documento de arquitetura. Ninguém estima no planejamento de sprint. Simplesmente acumula silenciosamente, até que um dia você percebe que metade do seu tempo de engenharia vai para manter integrações vivas ao invés de construir funcionalidades.

MCP não é um produto. Não é a API de uma startup. É um protocolo. Essa distinção importa mais do que as pessoas pensam.

Quando você escreve um servidor MCP, descreve suas ferramentas uma vez. Um schema. Um conjunto de descrições. Um formato de erro. É isso. Todo LLM que fala MCP pode descobrir e usar suas ferramentas sem que você escreva uma única linha de código específico de fornecedor.

Sem adaptadores. Sem matrizes de versão. Sem "if openai then formato A, elif anthropic then formato B". O protocolo é o contrato, e qualquer cliente que implementa o protocolo recebe suas ferramentas de graça.

É o mesmo padrão que tornou o HTTP um sucesso. Ninguém escreve uma API diferente para Chrome, Firefox e Safari. Você implementa o protocolo e todo cliente em conformidade funciona. MCP faz para integração de ferramentas de IA o que HTTP fez para entrega de conteúdo web — torna a camada de transporte entediante para que você possa focar na camada de aplicação.

O resultado prático é que suas definições de ferramentas se tornam ativos ao invés de passivos. Você as escreve uma vez, testa uma vez, documenta uma vez. Quando um novo provedor de LLM aparece, não reescreve nada. Só aponta para seu servidor MCP e funciona.

Seria desonesto se não reconhecesse isto: às vezes function calling é a escolha certa.

Se está construindo uma aplicação que só vai usar um LLM, e sabe qual, e não está se enganando — function calling direto é mais simples. Menos abstração. Menos peças móveis. Troca portabilidade por objetividade, e às vezes essa troca vale a pena.

Se precisa de funcionalidades específicas do provedor que ainda não têm equivalente MCP — pense em modos de saída estruturada, APIs de uso de computador ou comportamentos de streaming específicos — integração direta faz sentido. Não dá para acessar o que o protocolo não expõe.

E se está prototipando, na fase "faz funcionar", function calling te leva lá mais rápido. MCP tem custo de configuração inicial. Para um hackathon de fim de semana, esse custo é real.

Mas aqui está a pergunta que precisa responder com honestidade: "um fornecedor para sempre" realmente descreve seu futuro? Porque na minha experiência, as empresas que dizem "só vamos usar OpenAI" são as mesmas que freneticamente adicionam suporte a Claude seis meses depois quando seus usuários começam a pedir. As que dizem "só estamos prototipando" são as mesmas que ainda rodam aquele protótipo em produção dois anos depois.

O custo de migrar de function calling para MCP sobe a cada dia que você espera. O custo de começar com MCP se mantém mais ou menos constante.

Eis o que acho que a maioria não percebe: MCP e function calling não são inimigos. São camadas no mesmo stack.

Ferramentas MCP podem ser expostas como funções para qualquer LLM que suporte function calling. O protocolo é a fonte da verdade — a descrição canônica do que suas ferramentas fazem, o que aceitam e o que retornam. Os adaptadores de function calling são gerados, não escritos à mão. Seu servidor MCP é a fonte única; os formatos específicos de cada fornecedor são projeções.

Isso significa que você não precisa escolher. Pode ter MCP como sua camada de definição de ferramentas e continuar usando function calling como mecanismo de entrega para cada LLM. A diferença é que com MCP, essas definições de função derivam de uma fonte única ao invés de serem mantidas independentemente por fornecedor.

É para onde a indústria está indo, saiba ela ou não. O padrão "uma descrição canônica, muitos formatos derivados" venceu em todos os outros domínios — schemas de banco de dados, especificações de API, sistemas de tipos. A integração de ferramentas de IA vai convergir para o mesmo padrão porque a alternativa é um fardo de manutenção que cresce mais rápido que a equipe de engenharia de qualquer um.

As empresas que entendem isso agora vão gastar seu tempo construindo ferramentas melhores. As que entenderem depois vão gastar seu tempo reescrevendo código cola. Ambos os grupos vão acabar no mesmo lugar. A única pergunta é quanto tempo desperdiçam chegando lá.