Quando Você Não Precisa do MCP

O Problema

• As vagas de emprego continuam mencionando MCP, como se todos que trabalham com desenvolvimento de agentes tivessem que conhecê-lo
• Algumas pessoas dizem que MCP é muito pesado e quase ninguém realmente o usa
• Enquanto isso, muitos tutoriais dizem que uma interface unificada via MCP é ótima

A maioria dos tutoriais que você encontrará explica o que é MCP e por que você deve usá-lo. Depois de toda essa explicação, ainda é difícil ter uma noção intuitiva sobre as compensações. Então hoje eu vou inverter a pergunta: quando você não precisa de MCP? Essa é uma maneira melhor de construir intuição sobre isso.

O Que É MCP

MCP (Modelo Contexto Protocolo) é um protocolo aberto lançado pela Anthropic que permite que aplicações de IA (agentes como Claude Code, Claude Desktop, OpenClaw) descubram e chamem ferramentas externas, e leiam recursos externos, de uma forma unificada.

Essa é a definição clássica. Na prática, você pode pensar no MCP como uma espécie de recurso exposto a um agente. Antes do MCP existir, se você quisesse que uma aplicação de IA se conectasse a serviços como Google Drive, GitHub ou Slack, cada aplicação de IA tinha que escrever seu próprio código de integração para cada serviço externo.
O MCP é essencialmente um "soquete padrão" definido para essa conexão.

O Que Você Usaria em Vez de MCP

Se você pular o MCP, ainda terá muitas outras opções. As duas mais importantes:

Chamada de função: A OpenAI introduziu a chamada de função em 2023. É realmente simples — você passa uma assinatura de função para o LLM primeiro.

{
    "name": "get_weather",
    "description": "Obter o clima atual para uma cidade especificada",
    "input_schema": {
        ...
        "properties": {"city": {"type": "string"}},
    }
}

Uma vez que o LLM sabe que uma ferramenta existe, se ele decidir durante a execução que precisa chamar essa ferramenta externa, o content do resultado incluirá um objeto extra tool_use, e stop_reason também será definido como tool_use. Assim:

{
  "content": [
    {
      "type": "tool_use",
      "name": "get_weather",
      "input": {
        "city": "new york"
      }
    }
  ],
  "stop_reason": "tool_use"
}

Então você escreve o código você mesmo para realmente implementar a chamada da função.

if response.stop_reason == "tool_use":
    tool_use = response.content[-1]
    // ... chame a função de consulta do clima

Na prática, é obviamente menos rudimentar do que isso — você usaria um framework como LangChain.

CLI: Isso é realmente apenas outra forma de chamada de função — exceto que você expõe exatamente uma ferramenta, e informa ao LLM de antemão que é um shell bash, para que ele possa escrever qualquer comando que quiser. A vantagem é que você não precisa dizer ao LLM o que o bash pode fazer ou como usá-lo — o LLM já leu material suficiente para saber como escrever comandos bash por conta própria.

Mas usar um CLI vem com um risco real, já que o controle de permissões é difícil de acertar.

Da Perspectiva do Modelo

Primeiro, você precisa entender uma coisa: o modelo não tem ideia se você está chamando-o através do MCP ou através da chamada de função.
Por exemplo, quando você registra uma ferramenta de consulta do clima, se você registrá-la via MCP, aqui está o que o modelo vê em sua lista de ferramentas:

{
    "name": "get_weather",
    "description": "Obter o clima atual para uma cidade especificada",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {
                "type": "string"
            }
        }
    }
}

Se você usar a chamada de função em vez disso, aqui está o que o modelo vê:

{
    "name": "get_weather",
    "description": "Obter o clima atual para uma cidade especificada",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {
                "type": "string"
            }
        }
    }
}

Vamos jogar um li