MCP vs CLI: o que é cada um, quando usar e quando não

Tem uma confusão recorrente em conversas sobre agentes de IA: as pessoas tratam MCP como sinônimo de "agente que usa ferramentas", quando na verdade MCP é só uma das formas de entregar ferramentas a um modelo — e nem sempre a melhor.

Este post é um overview prático: o que é MCP, como o fluxo client → server funciona, em que casos faz sentido usar, em que casos CLI ganha, e por que function calling puro (SDK) resolve grande parte dos chats embutidos sem precisar de nenhum protocolo a mais.

A frase de uma linha

MCP é um protocolo aberto para apps de IA descobrirem e chamarem ferramentas externas de forma padronizada — útil quando o client e o server são de donos diferentes.

Tudo abaixo é detalhe técnico sobre essa frase.

O que é MCP

MCP (Model Context Protocol) é um padrão aberto criado pela Anthropic (final de 2024) para conectar modelos de IA a ferramentas, dados e sistemas externos.

A analogia oficial:

MCP é como a porta USB-C da IA. Antes, cada integração tinha um cabo diferente. Agora, qualquer modelo compatível conversa com qualquer ferramenta compatível pelo mesmo protocolo.

Em vez de N modelos × M ferramentas integrações customizadas, você tem um protocolo único que ambos os lados falam.

O problema que MCP resolve

Um LLM sozinho só sabe gerar texto a partir do que recebe no contexto. Ele não acessa seu banco de dados, seus arquivos, sua agenda, a internet. Antes do MCP, cada integração entre um modelo e uma ferramenta era feita à mão, de um jeito diferente para cada combinação.

MCP padroniza essa ponte.

Arquitetura — quem fala com quem

• Host / Client: a aplicação de IA. É ela que fala MCP do lado do consumidor (Claude Desktop, Cursor, seu app embutido).
• MCP Server: um programa que expõe capacidades de um sistema externo seguindo o protocolo. Existe um oficial para GitHub, Postgres, Google Drive, sistema de arquivos, Playwright. E você pode escrever o seu.

A comunicação usa JSON-RPC e roda por stdio (local) ou HTTP/SSE (remoto).

As três primitivas de um MCP Server

Tools são o que mais aparece na prática.

O fluxo completo: do usuário ao banco e de volta

Vale visualizar passo a passo o que acontece quando alguém faz uma pergunta para um agente conectado a um MCP server:

Dois detalhes que pouco se diz em voz alta:

• O MCP server não gasta tokens. Ele é um servidor de dados comum. Quem queima token é o client, em dois pontos: enviar tools+prompt pro modelo, e mandar de volta o resultado da tool como input.
• Retorno gordo encarece tudo. Se a tool devolve uma lista de 500 registros em JSON, isso entra como input para o próximo turno do modelo. Por isso vale agregar no servidor (SELECT COUNT(*)) e devolver enxuto.

Como um cliente "se conecta" ao seu MCP server

Suponha que você expôs um MCP server pro seu produto (digamos, um SaaS de eventos). Um cliente final não "abre conexão MCP" — ele usa um app de IA que é o client. Os caminhos reais:

O fluxo do usuário final é literalmente:

1. Cola a URL do seu MCP.
2. Faz login → aparece tela OAuth ("Autorizar Claude a acessar sua conta?").
3. Clica "Permitir".
4. Conversa em linguagem natural — o client descobre as tools, o modelo escolhe quais chamar.

O protocolo é a porta padronizada. O OAuth + autorização do seu lado é a fechadura. Sem auth decente, qualquer um conecta e enxerga os dados de outro tenant.

Casos de uso reais (consumir e expor)

Há dois lados:

Consumindo MCP

Quando você quer que seu agente ganhe acesso a um sistema externo:

• MCP do Postgres — durante dev, o agente inspeciona schema e dados pra te ajudar a escrever queries (idealmente apontando para dev, nunca produção com escrita).
• MCP do GitHub — abrir/revisar PRs, ler issues, comentar sem sair do editor.
• MCP do Playwright — dirigir um navegador real pra validar fluxos (E2E orientado por agente).
• MCPs de integrações que você usa (Slack, Linear, Sentry, Google Drive) — o agente já chega ao debug com contexto.

Regra mental:

Toda vez que, pra eu te ajudar, você precisaria copiar e colar dados de um sistema externo (saída de query, status de cobrança, log de e-mail, conteúdo de issue) → esse sistema é candidato a virar MCP.

Expondo MCP (seu produto como provedor)

Se você faz um SaaS, seu produto pode fornecer um MCP server pros clientes usarem dentro do Claude / ChatGPT deles. Em vez de "tem chat dentro do meu app", você vira parte do agente que eles já usam.

Exemplos de mapeamento:

A grande vantagem técnica: se sua API já é tRPC / REST com Zod (ou schema validado), o MCP server é uma casca fina que mapeia tool → procedure existente. Você reaproveita auth, validação e regras de negócio.

server.tool(
  "listar_inscricoes",
  { eventoId: z.string(), status: z.enum(["paga","pendente"]).optional() },
  async ({ eventoId, status }, ctx) => {
    const data = await trpcCaller.inscricao.list({ eventoId, status });
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
);

Quando NÃO usar MCP

Esse é o ponto em que muito time tropeça. Três cenários onde MCP é overhead:

1. Você controla os dois lados (client e server)

Se o agente roda dentro do seu próprio produto (um chat no painel do usuário), você é dono do client e do server. Aí MCP é caro à toa: use o SDK do provedor + function calling direto.

// SDK Anthropic — tools definidas no código, sem MCP no meio
const tools = [{
  name: "listar_inscricoes",
  description: "Lista inscrições de um evento",
  input_schema: { /* zod → json schema */ }
}];
 
const msg = await anthropic.messages.create({ model, tools, messages });
// se msg pede a tool, VOCÊ chama seu tRPC e devolve o resultado

Mais simples, menos camadas, mesmo resultado.

2. Não há LLM no meio

MCP foi desenhado pra agente. Suas tools carregam descrições em linguagem natural, feitas pra um modelo entender. Sem IA orquestrando, é uma RPC com overhead desnecessário — sua API REST/tRPC normal resolve melhor.

3. A ferramenta já tem CLI conhecida pelo modelo

É aqui que entra a comparação com CLI — que vale a próxima seção inteira.

MCP vs CLI: por que CLI muitas vezes vence

Existe um custo escondido do MCP que poucos contam: o overhead permanente de declarar tools no contexto.

Cada tool de um MCP server injeta nome + descrição + JSON schema no prompt em toda requisição, mesmo que você não use. Um MCP server "rico" pode ter 20–40 tools → isso são milhares de tokens de input fixo só pra deixar as ferramentas disponíveis. Conecte 4–5 MCPs e você gastou dezenas de milhares de tokens antes do modelo ler uma linha do seu código.

CLI evita isso:

• Uma única tool: "rode este comando bash". Schema minúsculo.
• O modelo já conhece git, gh, kubectl, psql, docker, aws do treino. O "schema" das 200 operações do gh já está nos pesos do modelo, de graça.

MCP paga pra declarar ferramentas. CLI aproveita ferramentas que o modelo já conhece.

A tabela de trade-offs

Repara no detalhe que conecta com o ponto anterior: CLI economiza na declaração, mas pode estourar no retorno. Um gh pr list sem filtro despeja texto gigante que volta como input. A economia real depende de você usar a CLI com --json, --limit, grep etc.

A Anthropic inclusive escreveu sobre isso (artigos sobre code execution with MCP e o problema de "too many MCP tools eat the context window"). A direção é clara: em vez de expor 50 tools MCP, dê ao agente um ambiente onde ele escreve código e roda CLI quando faz sentido.

A regra de bolso

Tem analogia com RAG?

Sim, e é boa pra fixar o conceito.

Em ambos:

• a LLM não sabe o dado;
• a LLM recebe o dado de fora e só redige;
• o conhecimento mora no seu sistema (banco, arquivos, API).

Mas há três diferenças importantes:

Quando uma tool MCP só faz SELECT no banco e devolve, ela é literalmente um RAG com retrieval estruturado em vez de vetorial. Quando ela faz INSERT/UPDATE ou chama integrações externas, extrapola o RAG e vira automação / agente.

RAG é "G" com um "R" automático e semântico, sempre read-only. MCP é "G" com ferramentas que o modelo escolhe ativamente — podendo ler ou agir.

Se quiser ir fundo no R-A-G, deixei um post denso sobre RAG do começo ao fim.

Custos: quem paga pelo MCP?

Pergunta comum, resposta importante: o MCP server não gasta tokens de LLM. Quem fala com o modelo é o client.

Os dois cenários comuns:

• Claude/ChatGPT do cliente conecta no seu MCP → o cliente paga a IA dele. Você só mantém um servidorzinho de API. Financeiramente, é o cenário ótimo pra quem provê o MCP.
• Chat embutido no seu produto (SDK) → você chama a Claude API com sua API key. Os tokens saem do seu bolso. Normalmente isso é repassado pro cliente como parte do plano.

A regra mental:

Token é custo de quem roda o modelo (client). MCP server é só servidor de dados — não pensa, não gasta token.

Resumo — o mapa de uma página

Conclusão

MCP não é "a forma certa" de dar ferramentas a uma IA — é uma das três formas, junto com function calling puro (SDK) e CLI. Cada uma faz mais sentido num cenário:

• SDK + function calling: você é dono dos dois lados. Mais simples, sem overhead. É o que cabe em quase todo chat embutido.
• CLI: o modelo já conhece a ferramenta (git, gh, docker…). Quase grátis em tokens, brutalmente eficaz.
• MCP: você é provedor (SaaS expondo capacidades pra IAs de terceiros) ou consumidor de algo que não tem CLI conhecida.

O MCP é a porta USB-C — útil quando você precisa que qualquer cabo se conecte ao seu produto. Mas se você já tem o cabo na mão e o aparelho conhece o padrão antigo, não vale trocar tudo só porque o USB-C virou moda.

A pergunta decisiva, sempre: o modelo já conhece essa ferramenta? Eu controlo os dois lados? Responda e o caminho aparece.