Medi MCP versus um CLI para busca de agentes. O MCP usou 17x mais tokens por chamada.

Rodei a mesma busca no Google pelo servidor serpapi-mcp oficial da SerpApi e pelo serp, o pequeno CLI open-source (MIT) que construí para o mesmo trabalho. Antes de ter buscado qualquer coisa, o MCP já tinha colocado 771 tokens no contexto do modelo. O CLI colocou zero. Quando busquei, o MCP retornou 6.047 tokens e o CLI retornou 351. Mesma query, mesma biblioteca serpapi por baixo, mesma máquina.

Esses 771 tokens de custo fixo são uma categoria diferente do custo por chamada. O custo por chamada você paga quando o agente busca. O custo fixo você paga em todo turno do modelo, busque o agente naquele turno ou não. Um loop que leva 20 turnos para concluir uma tarefa e só busca em três deles custa 771 × 20 = 15.420 tokens em schema antes de contar um único resultado. O CLI não custa nada nos outros 17 turnos.

TL;DR: para busca stateless dentro de um loop de agente, um CLI custa aproximadamente 0 tokens fixos contra ~771 por turno de uma ferramenta MCP, e ~351 por chamada contra ~6.047. A lógica de compactação dos dois lados é idêntica; o CLI projeta só os campos que você pediu e fica fora do contexto quando ocioso. Escolha o transporte que serve à chamada.

Custo fixo, pago a cada turno

	SerpApi MCP	CLI serp
Schema da ferramenta em contexto, por turno	771 tokens	~0 (binário no PATH)
Metadados da skill	n/a	~110 tokens, e só até disparar

O MCP injeta o schema da ferramenta search, todos os 771 tokens, em toda requisição ao modelo. Não só quando o agente busca. Toda requisição, porque o schema precisa estar presente para o modelo saber que pode buscar. O CLI não injeta nada. É um binário no PATH; o agente aprende que ele existe uma vez, de uma skill que custa ~110 tokens até disparar, e depois chama ele como qualquer outro comando.

Conecte dez servidores MCP em vez de um e você vai carregar alguns milhares de tokens de schema sempre carregado antes de o agente ter feito qualquer chamada. Esse é o número que a demo não mostra.

Custo de descoberta, pago uma vez

	SerpApi MCP	CLI serp
Aprender a interface	recurso de engine (google.json) = 5.816 tokens	--help = ~290 tokens

Os dois são sob demanda. Para aprender os parâmetros de uma engine pelo MCP você lê o recurso correspondente; google.json tem 5.816 tokens. Para aprender o CLI você lê o --help, cerca de 290. Não é custo por turno, então não acumula da mesma forma, mas aparece pelo menos uma vez por sessão fria.

Por chamada, a mesma query do google, byte a byte

Resposta	Tokens
MCP complete (o padrão)	6.047
MCP compact	4.577
CLI --format complete	5.321
CLI compact, sem --fields	3.940
CLI --fields title,link	351

O modo padrão do MCP é complete, então de fábrica uma busca derruba cerca de 6.000 tokens no seu contexto. O CLI tem padrão compact e deixa você especificar exatamente quais campos quer de volta, então os mesmos dez resultados voltam em 351 quando você pede só title,link. É aproximadamente 17x menor que o padrão do MCP, e 13x menor que o próprio modo compact do MCP.

Por que o CLI custa 13x menos

A parte honesta primeiro: a lógica de compactação dos dois lados é idêntica. Os dois descartam os mesmos cinco blocos de metadados: search_metadata, search_parameters, search_information, pagination, serpapi_pagination. O MCP da SerpApi é um bom software, e 771 tokens para uma única ferramenta universal que cobre todas as engines de busca que suporta é um schema razoável, não inchaço. Não estou batendo nele.

Vale dizer explicitamente o que esses cinco blocos contêm. search_metadata carrega dados de processamento e temporização, incluindo ID da requisição e créditos de API consumidos. search_parameters ecoa de volta exatamente o que você mandou na requisição. search_information é texto de display para construir uma UI. Os dois objetos de paginação são para humanos navegando entre páginas. Um agente sintetizando uma resposta a partir dos resultados não precisa de nada disso.

A diferença depois de remover esses cinco blocos vem de três coisas que o CLI faz e o MCP não. Primeiro, projeção de campos: --fields title,link reduz cada resultado às chaves que você nomeou. O modo compact do MCP remove os metadados mas ainda devolve todos os campos de todos os resultados, incluindo snippet, data, sitelinks, knowledge graph e o que mais a engine incluiu. Só isso é a maior parte dos 13x. Segundo, minificação: o MCP faz pretty-print com indent=2, que por si só é cerca de 15% mais caracteres que a saída compacta. Terceiro, custo zero em repouso: não tem schema sentado no contexto entre chamadas.

A medição

Tokens são caracteres / 4 ao longo de tudo, mesmo proxy dos dois lados. Confie mais nas razões que nos números absolutos; qualquer erro sistemático no proxy cancela na comparação.

Para o custo fixo: peguei o payload real de tools/list do serpapi-mcp rodando em FastMCP e contei os campos que um cliente de fato recebe: name, description e inputSchema. São 771 tokens para a única ferramenta search. O servidor também expõe 107 recursos de engine; listar todos eles custa cerca de 4.300 tokens, e ler google.json especificamente custa 5.816.

Para por chamada: uma busca live no Google para uma query fixa, puxada pela mesma biblioteca Python serpapi que o MCP usa internamente. Serializada de dois jeitos: json.dumps(indent=2) para casar com o que o MCP entrega ao modelo, e minificada com projeção de campos para casar com o que o CLI produz. Os números exatos dessas duas serializações são os da tabela acima.

A compactação foi espelhada dos dois lados de propósito, mesmos cinco blocos removidos antes de serializar, então a comparação é equivalente nessa dimensão. A diferença que sobra é projeção e minificação.

Outras pessoas mediram o mesmo efeito, com mais força

O princípio não é meu. O enquadramento da Anthropic é que a janela de contexto é um bem público, e dois benchmarks publicados apontam na mesma direção. O artigo deles sobre code-execution-with-MCP levou um fluxo de Drive-para-Salesforce de cerca de 150.000 tokens para cerca de 2.000 ao chamar ferramentas como código em vez de carregar suas definições, um corte de 98,7%. O benchmark OnlyCLI mediu uma tarefa do GitHub em 44.026 tokens pelo MCP contra 1.365 por um CLI, cerca de 32x. São cenários grandes de ponta a ponta com muitas ferramentas e estado intermediário substancial. Meus 13-17x em uma única busca são a versão pequena e conservadora do mesmo mecanismo.

Quando você quer o MCP

Isso não é “CLI ganha do MCP.” É escolher o transporte que serve à chamada.

Vá de MCP quando a conexão é a parte difícil: OAuth ou autenticação multi-usuário que o agente não deveria gerenciar sozinho, governança de quota e rate-limit no servidor, um endpoint hospedado compartilhado por muitos clientes em máquinas diferentes, ou uma sessão que precisa manter estado entre etapas. A SerpApi roda o serpapi-mcp e uma versão hospedada em mcp.serpapi.com. É aí que ele se justifica: uma conexão gerenciada com a SerpApi cuidando de auth e quotas, acessível a qualquer cliente MCP sem distribuir uma chave.

Vá de CLI quando a chamada é stateless e você controla as duas pontas. Query entra, resultados saem, um passo, uma chave no ambiente, um payload gordo que você quer cortar antes de chegar ao modelo. Uma busca é o caso clássico. Você lê o --help uma vez por sessão, e toda chamada depois disso retorna só o que você pediu. Sem servidor para gerenciar, sem schema fixo no contexto, sem complexidade de auth.

Uma heurística que segura: se a conexão é o problema, use MCP. Se o payload é o problema, use um CLI.

O que é o serp

Ele envolve o endpoint REST da SerpApi e compila para um único binário com bun build --compile, sem dependências de runtime. O modo compact descarta os cinco blocos de metadados, --fields projeta cada resultado para as chaves que você nomeia, e as flags de geo (--location, --gl, --hl) só vão para a rede quando você as define. A saída é JSON minificado no stdout, porque o leitor é uma máquina. A chave é lida de SERPAPI_API_KEY com fallback para SERP_API_KEY.

As partes que valem testar são funções puras: o construtor de URL, o parser de argumentos, o formatador de resultados. A chamada de rede e o ponto de entrada run() recebem um fetch injetado e streams injetados, então a suíte completa, 37 testes, roda offline sem chave e sem requisições reais. Essa é a parte com que estou realmente satisfeito.

Tem uma skill do Claude Code ao lado, searching-with-serpapi, que guarda o procedimento: qual engine serve a qual intenção, compact versus complete, operadores, quando deduplicar e citar, quando não buscar nada. A skill custa cerca de 110 tokens até disparar. Capacidade vem do CLI (ou do MCP), o como-fazer vem da skill.

Duas ressalvas que eu gostaria se estivesse lendo isto

Prompt caching estreita a diferença de custo fixo em sessões quentes onde o conjunto de ferramentas não muda, porque o bloco de schema estático é amortizado ao longo dos turnos. O número de 771-por-turno morde com mais força em cold starts e sempre que você adiciona ou troca uma ferramenta. A diferença por chamada não depende de caching; você a paga fresca em toda busca.

Code execution é uma alavanca maior que tudo isso. É de onde vêm os 98,7%. Mas precisa de um sandbox real com limites de recursos e monitoramento, que uma chamada simples de CLI pula. Tradeoff diferente, vale nomear.

Conclusão

Combine o transporte com a chamada. Para busca stateless em um loop de código, um CLI pequeno mais uma skill é mais barato em contexto (cerca de 0 fixo contra 771 por turno, cerca de 350 por resultado contra 6.000) e a economia fixa acumula conforme você adiciona ferramentas. Para uma conexão hospedada, governada e multi-cliente, o MCP é a escolha certa.

Se você roda agentes com uma pilha de servidores MCP, o custo fixo vale medir no seu próprio setup. O método está no apêndice, fácil de reproduzir. Eu gostaria genuinamente de saber que números você obtém.

O repositório é open-source e MIT: github.com/aryrabelo/serpapi-agent-toolkit. O CLI e a skill vêm juntos, ambos complementos ao serpapi-mcp da SerpApi.

Apêndice: como eu medi

Tokens são caracteres / 4, consistente dos dois lados, então confie mais nas razões que nos números absolutos.

O custo fixo do MCP é o payload real de tools/list do serpapi-mcp rodando em FastMCP, contando os campos que um cliente de fato recebe (name, description, inputSchema): 771 tokens para a única ferramenta search. O servidor também expõe 107 recursos de engine; listar todos eles é cerca de 4.300 tokens, e ler google.json especificamente é 5.816.

Os números por chamada vêm de uma busca live no Google para uma query fixa, puxada pela mesma biblioteca Python serpapi que o MCP usa internamente, depois serializada de dois jeitos: json.dumps(indent=2) para casar com a saída do MCP, e minificada com projeção de campos para casar com o CLI. Contagens exatas: MCP complete 6.047, MCP compact 4.577, CLI complete 5.321, CLI compact 3.940, CLI --fields title,link 351. O custo fixo do CLI e o --help vêm do texto da v0.1.0, cerca de 110 e 290 respectivamente.

Fontes: “Code execution with MCP”, “Writing tools for agents” e “Effective context engineering” da Anthropic; o benchmark de custo de tokens OnlyCLI; os repositórios serpapi-mcp e serpapi-javascript da SerpApi.

---

A lição atrás dos números é chata de propósito: decida pela medição, não pela demo. Se a sua empresa escolhe ferramenta de IA pelo que impressiona na demonstração e depois paga a conta da escolha errada, é esse rigor que falta. Traga a decisão que está na mesa e a gente mede antes de você comprar. Conversa comigo.

Se esse é o tipo de problema que te interessa, escrevo sobre isso toda semana na Em Paralelo: IA, dev tooling e performance, com números reais e sem hype. Assine a Em Paralelo.