Sim — e muitos apps usam. Use function calling para ferramentas in-app que o usuário nunca vê (auth, lookups internos). Use MCP para ferramentas que o usuário quer acessar de outros clientes também. Os dois coexistem na mesma sessão Claude.

MCP é mais lento que function calling?

Marginalmente. Function calling é in-process; MCP é JSON-RPC sobre stdio ou HTTP-SSE. A latência adicional é single-digit ms para stdio, ~50-100ms para HTTP. Para fluxos LLM-bound o custo é invisível — o modelo leva 2-30s de qualquer jeito.

MCP funciona com modelos não-Anthropic?

Sim. MCP é model-agnostic — o protocolo não liga para qual LLM você usa. Goose, Continue e a camada MCP-compat da OpenAI rodam servidores MCP contra modelos não-Claude. Anthropic enviou MCP primeiro porque investiu cedo; o protocolo em si é aberto.

Devo migrar meu app function-calling existente para MCP?

Só se você quer as ferramentas disponíveis fora do app — para pipeline CI, Claude Desktop, agent de colega. Se ferramentas são app-internas para sempre, function calling tá bom.

Todos os posts

MCPMCPfunction callingengenharia

MCP vs function calling: quando trocar (e quando não)

Function calling é o padrão in-app de declarar ferramentas dentro de uma única conversa de SDK LLM; MCP (Model Context Protocol) é o padrão cross-app de rodar ferramentas como serviço JSON-RPC separado que qualquer cliente MCP-aware (Claude Desktop, Code, SDKs, agents) descobre e chama.

inite26 de abr. de 20262 min de leitura

Use function calling quando você tem um único app SDK, suas ferramentas são simples e você controla cliente e servidor. Use MCP quando quer o mesmo toolchain funcionando em Claude Desktop, Code, agents e CI sem reescrever a integração; quando ferramentas têm side effects que você quer centralizados; ou quando constrói produto cujos usuários vão plugar em seu próprio cliente LLM. Árvore de decisão é 90% contagem-de-clientes: 1 cliente = function calling, 2+ = MCP.

Fatos-chave

Function calling enviou na API da OpenAI em junho 2023; Anthropic adicionou em maio 2024.
MCP entrou em GA no Claude Desktop em novembro 2024.
Servidores MCP pré-construídos para filesystem, GitHub, Slack, Postgres e 50+ surfaces (abril 2026).
Migrar app SDK para MCP toma 80-200 LOC para superfície de 5 ferramentas (ports reais que medimos).

Function calling e MCP resolvem o mesmo problema raiz (deixe LLMs chamarem seu código) em escopos diferentes. Escolher o errado custa semanas; escolher o certo é mostly contar clientes.

A regra simples

Um cliente LLM → function calling. Dois ou mais → MCP.

Esses são 90% da decisão. Os 10% restantes são edge cases.

Onde function calling ainda vence

Três cenários:

Builds SDK single-app. Você envia um chatbot dentro de app Next.js. Ferramentas vivem ao lado dos route handlers. O usuário nunca vê o LLM diretamente — fala com sua UI. MCP adiciona overhead sem payoff.
Ferramentas com requirements de latência sub-ms. Function calling é in-process. MCP adiciona overhead JSON-RPC — geralmente invisível, mas se você otimiza tail latency em token-streaming, in-process vence.
Ferramentas tightly coupled à sua auth/session. Se a ferramenta precisa da sessão logada para fazer qualquer coisa, MCP torna o handoff de auth awkward.

Onde MCP vence

Cinco cenários, em ordem de quanto se apoiam nas forças do MCP:

Você quer a mesma ferramenta de múltiplos clientes. Claude Desktop, Code, SDK, script CI, agent de colega — todos batem no mesmo servidor MCP. Escreva uma vez, plugue em todo lugar.
O usuário escolhe o cliente LLM. Você envia produto (como ideaudit). Usuários têm Claude Desktop, Code ou outro cliente MCP-aware. MCP é como você os alcança todos.
Você quer auditing centralizado de tool calls. Servidores MCP logam toda chamada num lugar. Function calling espalha logs por N apps consumidores.
Ferramentas têm side effects em infra compartilhada. Database writes, rate limits de API, billing meters. Centralizar num servidor MCP te dá um chokepoint em vez de N.
Você quer ferramentas pré-construídas. Filesystem, GitHub, Slack, Postgres — o ecossistema MCP envia dúzias.

Padrão de migração

Se você tem app SDK existente e quer expor ferramentas pro Claude Desktop também:

Puxe definições de ferramenta da chamada SDK pra um módulo standalone.
Wrap esse módulo num servidor MCP (TypeScript ou Python — boilerplate é ~50 LOC).
Mantenha o app SDK chamando o mesmo módulo localmente para ferramentas in-app.
Registre o servidor MCP na config do Claude Desktop.

O mesmo código serve ambos clientes. Custo de migração em ports reais: 80-200 LOC para superfície de 5 ferramentas.

O que ideaudit escolheu

MCP, ponta a ponta. Razão: usuários têm Claude Desktop, Code e apps SDK. Queríamos um servidor, um modelo de auth, um rate limiter. Function calling por cliente teria significado reimplementar 103 ferramentas três vezes e rezar para se manterem em sync.

curl -fsSL https://inite.studio/install.sh | sh

As 103 ferramentas são as mesmas conversando com ideaudit do Claude Desktop, Code ou SDK. Essa é a vitória do MCP, em uma frase.

FAQ

Perguntas frequentes

Posso usar os dois?
Sim — e muitos apps usam. Use function calling para ferramentas in-app que o usuário nunca vê (auth, lookups internos). Use MCP para ferramentas que o usuário quer acessar de outros clientes também. Os dois coexistem na mesma sessão Claude.
MCP é mais lento que function calling?
Marginalmente. Function calling é in-process; MCP é JSON-RPC sobre stdio ou HTTP-SSE. A latência adicional é single-digit ms para stdio, ~50-100ms para HTTP. Para fluxos LLM-bound o custo é invisível — o modelo leva 2-30s de qualquer jeito.
MCP funciona com modelos não-Anthropic?
Sim. MCP é model-agnostic — o protocolo não liga para qual LLM você usa. Goose, Continue e a camada MCP-compat da OpenAI rodam servidores MCP contra modelos não-Claude. Anthropic enviou MCP primeiro porque investiu cedo; o protocolo em si é aberto.
Devo migrar meu app function-calling existente para MCP?
Só se você quer as ferramentas disponíveis fora do app — para pipeline CI, Claude Desktop, agent de colega. Se ferramentas são app-internas para sempre, function calling tá bom.