MCP e function calling resolvem problemas diferentes. O function calling permite que um modelo solicite uma ação, enquanto o MCP oferece aos apps um protocolo compartilhado para encontrar ferramentas. Este artigo compara os dois com exemplos de código da OpenAI e do Claude, uma lista de verificação de segurança e uma regra simples para escolher.
Escolha a camada errada e você vai refazer a mesma integração duas vezes. MCP vs function calling parece uma bifurcação no caminho, mas as duas coisas ficam em níveis diferentes da mesma arquitetura. Function calling é a forma como um modelo pede uma ação. O Model Context Protocol (MCP) é a forma como um aplicativo encontra e alcança as ferramentas em que essa ação roda.
A resposta curta, antes de qualquer código: function calling é um recurso do modelo, MCP é um protocolo de comunicação, e a maioria das configurações de MCP usa function calling por baixo dos panos. Com duas ou três ferramentas dentro de um único app, o function calling puro é mais simples. Quando vários apps precisam das mesmas ferramentas, o MCP se paga rápido. As seções abaixo mostram exemplos da OpenAI e da Claude para as duas abordagens, lado a lado.
Um modelo de linguagem só produz texto. O function calling dá a esse texto um formato em que seu código pode confiar. Em cada requisição você envia uma lista de definições de ferramentas: um nome, uma descrição em linguagem simples e um JSON Schema para os argumentos. Quando o modelo decide que uma ferramenta é necessária, ele não executa nada. Ele devolve uma chamada estruturada com o nome da ferramenta e os argumentos, e é o seu código que faz o trabalho.
💡 Dica: O modelo nunca executa código. Ele propõe uma chamada, e sua aplicação decide se vai executá-la. É exatamente nessa lacuna que devem ficar as verificações de permissão e os registros de log.
As definições ficam na sua própria base de código, geralmente ao lado da função que descrevem. A OpenAI chama o campo do schema de parameters. A Claude chama de input_schema. O envelope muda um pouco entre provedores, então uma ferramenta escrita para um precisa de um adaptador simples para o outro.
Esse é o custo real do function calling puro: cada app mantém a sua própria cópia de cada definição, e cada provedor quer o seu próprio formato. Se você criar a mesma consulta de pedido para um app de chat, um plugin de IDE e um bot de suporte, vai manter três cópias.
A Anthropic lançou o MCP em novembro de 2024 como um protocolo aberto, e a OpenAI adotou em março de 2025. O MCP padroniza como as ferramentas são descritas, listadas e chamadas, então uma ferramenta escrita uma única vez como um servidor MCP funciona em todo cliente que fala o protocolo. É a porta padrão da foto acima: um formato de conector, muitos dispositivos. Em vez de N apps vezes M ferramentas de cola personalizada, você constrói N clientes e M servidores.
O MCP tem três papéis:
As mensagens usam JSON-RPC 2.0. Servidores locais se comunicam por stdio, e servidores remotos por Streamable HTTP. O cliente abre uma sessão, pergunta ao servidor o que ele oferece e chama as coisas pelo nome.
Um servidor pode expor três tipos de capacidade:
| Primitiva | O que é | Quem controla |
|---|---|---|
| Ferramentas | Ações ou cálculos que o modelo pode chamar | O modelo |
| Recursos | Dados legíveis identificados por uma URI, como um arquivo ou um registro | A aplicação |
| Prompts | Modelos de mensagem reutilizáveis | O usuário |
Só as ferramentas se sobrepõem ao function calling. Recursos e prompts não têm um padrão no function calling puro, e isso é parte do motivo pelo qual as pessoas recorrem ao MCP.
Aqui está o tráfego de rede de uma única ferramenta. O cliente pede ao servidor as ferramentas dele:
{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}
O servidor responde com definições parecidas com as que você escreveria à mão, exceto que o campo do schema é inputSchema em camelCase:
{"jsonrpc": "2.0", "id": 1, "result": {"tools": [{
"name": "get_order_status",
"description": "Look up the shipping status of an order by its ID.",
"inputSchema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"]
}
}]}}
Depois, quando o modelo pede essa ferramenta, o cliente envia:
{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
"params": {"name": "get_order_status", "arguments": {"order_id": "8841"}}}
| Pergunta | Function calling | MCP |
|---|---|---|
| O que é? | Um recurso da API do modelo | Um protocolo aberto entre apps e servidores de ferramentas |
| Onde ficam as definições? | No código do seu app, enviadas a cada requisição | No servidor, listadas sob demanda com tools/list |
| Quem executa a ferramenta? | O processo da sua aplicação | O servidor MCP, local ou remoto |
| Reúso entre apps | Copiar e adaptar em cada app | Escrever uma vez, conectar a partir de qualquer cliente |
| Precisa do outro? | Não | Sim, o modelo ainda chama ferramentas via function calling |
| Esforço de configuração | Minutos | Algumas horas para o primeiro servidor, minutos para um já existente |
| Melhor para | Poucas ferramentas, lógica privada do app | Ferramentas compartilhadas e integrações de terceiros |
As duas não são rivais, porque o MCP alimenta o function calling. Aqui está o caminho completo de uma requisição em uma configuração MCP:
tools/call.Do ponto de vista do modelo, nada mudou. Ele viu definições de ferramentas e emitiu uma chamada. O que mudou foi quem escreveu as definições e quem executou a função.
💡 Regra prática: Se você consegue apontar a linha do seu próprio código que executa a função, está fazendo function calling puro. Se um servidor separado a executa, está usando MCP, com o function calling ainda acontecendo entre o modelo e o cliente.
A mesma ferramenta, de quatro formas: uma consulta de status de pedido. Os exemplos usam Python, e a URL do servidor MCP é um marcador que você substitui pela sua.
Esta versão usa a Responses API com o GPT 5. Você define a ferramenta, executa a função por conta própria e devolve um item function_call_output.
import json
from openai import OpenAI
client = OpenAI()
def get_order_status(order_id: str) -> dict:
return {"order_id": order_id, "status": "shipped", "eta": "2026-10-09"}
tools = [{
"type": "function",
"name": "get_order_status",
"description": "Look up the shipping status of an order by its ID.",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
"additionalProperties": False,
},
"strict": True,
}]
input_items = [{"role": "user", "content": "Where is order 8841?"}]
response = client.responses.create(model="gpt-5", tools=tools, input=input_items)
input_items += response.output
for item in response.output:
if item.type == "function_call":
result = get_order_status(**json.loads(item.arguments))
input_items.append({
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
})
final = client.responses.create(model="gpt-5", tools=tools, input=input_items)
print(final.output_text)
A mesma pergunta, sem schema e sem laço no seu código. A API se conecta ao servidor, lista as ferramentas dele e as chama por você.
response = client.responses.create(
model="gpt-5",
tools=[{
"type": "mcp",
"server_label": "orders",
"server_url": "https://mcp.example.com/mcp",
"require_approval": "always",
}],
input="Where is order 8841?",
)
print(response.output_text)
Com require_approval definido como "always", a resposta contém uma solicitação de aprovação para cada chamada, e o seu código decide se a permite. Use "never" apenas com servidores em que você confia totalmente.
A Messages API segue o mesmo ciclo com nomes de campos diferentes. O schema vai em input_schema, o modelo sinaliza uma chamada com stop_reason == "tool_use", e você responde com um bloco tool_result.
import json
import anthropic
client = anthropic.Anthropic()
tools = [{
"name": "get_order_status",
"description": "Look up the shipping status of an order by its ID.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}]
messages = [{"role": "user", "content": "Where is order 8841?"}]
response = client.messages.create(
model="claude-sonnet-5-5", max_tokens=1024, tools=tools, messages=messages
)
if response.stop_reason == "tool_use":
messages.append({"role": "assistant", "content": response.content})
results = []
for block in response.content:
if block.type == "tool_use":
output = get_order_status(**block.input)
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": json.dumps(output),
})
messages.append({"role": "user", "content": results})
response = client.messages.create(
model="claude-sonnet-5-5", max_tokens=1024, tools=tools, messages=messages
)
print(response.content[-1].text)
Envie todos os tool_result de um mesmo turno em uma única mensagem do usuário. Dividi-los em mensagens diferentes ensina o modelo a parar de chamar ferramentas em paralelo.
O conector MCP precisa de duas partes: o servidor em mcp_servers, e uma entrada mcp_toolset correspondente em tools. Ele também fica atrás de um cabeçalho beta e alcança servidores remotos via HTTP, não servidores stdio locais.
response = client.beta.messages.create(
model="claude-sonnet-5-5",
max_tokens=1024,
betas=["mcp-client-2025-11-20"],
mcp_servers=[{
"type": "url",
"url": "https://mcp.example.com/mcp",
"name": "orders",
}],
tools=[{"type": "mcp_toolset", "mcp_server_name": "orders"}],
messages=[{"role": "user", "content": "Where is order 8841?"}],
)
Compare as quatro. As versões MCP são mais curtas porque o schema e o ciclo saíram do seu código. A contrapartida é o controle: você entrega o ciclo para a API e confia no que o servidor diz sobre si mesmo.
Nomes, descrições e resultados das ferramentas fluem todos para o contexto do modelo. Um servidor descuidado ou hostil pode esconder instruções neles, o que é uma via de injeção de prompt. O function calling puro tem o mesmo risco com os resultados das ferramentas, mas o MCP amplia esse risco porque terceiros escrevem as descrições.
Cada definição é enviada como tokens de entrada em todas as requisições. Quarenta ferramentas com descrições longas podem somar milhares de tokens antes de o usuário dizer uma palavra. O MCP torna isso fácil de acontecer sem querer, porque anexar um servidor traz todas as suas ferramentas de uma vez.
Três correções funcionam bem:
💡 Erros comuns: anexar todos os servidores a cada requisição, aprovar automaticamente ações de escrita e pular os logs de chamadas. Cada um deles é barato de evitar no primeiro dia e caro de corrigir depois de um incidente.
A maioria dos sistemas de produção acaba misturando as duas abordagens. A lógica privada fica como ferramentas de função em processo, e as capacidades compartilhadas ou de terceiros chegam por servidores MCP. As duas chegam ao modelo pela mesma interface de function calling, então misturá-las custa quase nada.
O PicassoIA expõe sua geração de imagens e vídeos por um conector MCP, o que o torna um exemplo útil das escolhas de design acima. A geração leva tempo, então as ferramentas são divididas em iniciadores e uma verificação de status. Este é o mesmo formato que você construiria à mão com duas definições de função.
| Ferramenta | O que faz |
|---|---|
generate_image | Inicia uma tarefa de imagem e devolve um ID de previsão |
edit_image | Inicia uma edição de uma imagem existente |
generate_video_picassoia | Inicia uma tarefa de vídeo com o modelo de vídeo do PicassoIA |
generate_video_seedance | Inicia uma tarefa de vídeo com o Seedance |
get_generation | Consulta uma previsão até que ela tenha êxito ou falhe |
list_generations | Lista gerações anteriores |
cancel_generation | Cancela uma tarefa que ainda está na fila ou em execução |
list_models | Mostra quais modelos sua conta pode usar |
get_account | Mostra seu plano e os limites de execuções paralelas |
O padrão vale a pena copiar nos seus próprios servidores: devolver um ID rapidamente, consultar com uma ferramenta separada e dar ao modelo uma ferramenta de cancelamento para que ele possa desistir de uma execução ruim. A documentação para desenvolvedores lista 5 previsões simultâneas por conta, compartilhadas entre credenciais de API e conexões MCP, então um cliente bem-comportado consulta em vez de disparar tudo de uma vez. As mesmas tarefas também estão disponíveis por uma API REST no estilo Replicate em https://api.picassoia.com/v1. Confira a página de preços para saber quais planos incluem acesso à API e ao MCP.
Antes de montar o código, você pode rascunhar schemas de ferramentas e testar prompts na página do Claude Sonnet 5. A página do modelo expõe estas entradas:
low, que desliga o pensamento para respostas mais rápidas e baratas. Mude para high ou max para um bug complicado em vários arquivos ou um design com muitas ferramentas. Os níveis são low, medium, high, xhigh e max.💡 Dica: Peça o schema primeiro e depois peça ao modelo que critique a própria descrição. Descrições curtas e específicas tornam a ferramenta mais fácil de escolher corretamente.
Cada foto deste artigo começou como um prompt de texto: um painel de ferramentas, um painel telefônico, um fichário, uma bifurcação de trilha. Cada uma transforma uma ideia abstrata em algo que você pode ver, e a mesma receita funciona para seus próprios posts, documentações e apresentações.
Use esta estrutura: sujeito e ação, ambiente, iluminação, câmera e lente, detalhes de textura. Por exemplo: "Close-up de uma mão encaixando um cabo em um notebook sobre uma mesa de carvalho, luz suave de janela vinda da direita, lente macro de 100mm, profundidade de campo rasa, textura de alumínio escovado."
Abra o Picasso IA, escolha um modelo de texto para imagem na lista completa de modelos, cole um prompt nesse formato e execute. Mude um detalhe por vez, como a lente ou a direção da luz, e observe como o resultado muda. Se você já trabalha com a Claude, conecte o conector MCP do PicassoIA a partir da sua conta e peça imagens diretamente no chat. Teste três variações de uma ideia hoje e fique com a melhor.
Escolha seu idioma
