MCP sempre foi uma má ideia?

Artigo original ↗ Discussão no Hacker News ↗

Críticos do Model Context Protocol (MCP) argumentam que ele foi supervalorizado e frequentemente desperdiça tokens em comparação com simplesmente deixar agentes de IA usarem APIs HTTP ou ferramentas de CLI bem projetadas, especialmente agora que os modelos entendem melhor interfaces. Defensores respondem que o MCP ainda resolve problemas importantes de autenticação, acesso com menor privilégio, sandboxing, auditabilidade e descoberta padronizada de ferramentas — particularmente em ambientes corporativos e multiusuário, onde não dá para simplesmente conceder shell access ao agente ou chaves de API brutas. A discussão destaca uma divisão mais ampla: fluxos de trabalho solo ou locais geralmente favorecem CLIs e APIs diretas, enquanto casos de uso organizacionais e de agentes na web tendem cada vez mais a adotar padrões no estilo MCP e variantes emergentes como WebMCP.

MCP vs CLI / APIs Diretas

  • Muitos argumentam que CLIs e REST/OpenAPI já resolvem a maioria dos problemas que o MCP tenta atacar; CLIs são familiares, composáveis e muitas vezes mais baratas em tokens.
  • Outros dizem que MCP é, na prática, “REST para agentes”: uma interface padronizada e detectável para ferramentas, mais alinhada com a forma como os agentes chamam ferramentas hoje.
  • Alguns veem servidores MCP como invólucros finos sobre APIs/CLIs existentes (“batom num porco”), adicionando infraestrutura extra sem novas semânticas.

Segurança, Autenticação e Menor Privilégio

  • Há forte apoio ao MCP em torno de auth: ele pode esconder credenciais dos agentes, centralizar autenticação e expor apenas operações estreitas e validadas.
  • Críticos respondem que um bom design de API, tokens de curta duração e escopo restrito, proxies ou CLIs em sandbox podem alcançar o mesmo objetivo — o MCP não é, por si só, mais seguro.
  • Há preocupação de que depender do MCP para controle de acesso crie uma falsa sensação de segurança; controles e auditoria no lado do servidor ainda são necessários.

Uso de Tokens, Contexto e Desempenho

  • Vários relatam que MCPs consomem mais tokens do que o uso direto de CLI/API (especialmente os mal implementados); outros dizem o contrário quando os schemas de MCP são enxutos.
  • O antigo design do MCP que carregava demais para o contexto é amplamente criticado; variantes mais novas “stateless / progressivas” são vistas como melhorias.
  • O overhead de inicialização de processo para CLIs é geralmente considerado negligenciável em comparação com a latência do LLM ou da rede.

Empresa, Governança e Uso no Mundo Real

  • MCP é visto como mais valioso em ambientes corporativos e multiusuário: controle centralizado, logs de auditoria, revogação/rotação de segredos, interface uniforme entre runtimes.
  • Lojas de plugins MCP em grandes apps de chat impulsionam a adoção entre usuários não técnicos; alguns veem isso como parte de uma bolha de IA.

Padrões, Alternativas e WebMCP

  • Vários argumentam que padrões existentes (REST, OpenAPI/Swagger, SOAP/WSDL, cabeçalhos HTTP, documentação .well-known) poderiam ter sido estendidos em vez de inventar o MCP.
  • WebMCP é elogiado como uma abordagem mais simples e alinhada para apps web, potencialmente substituindo o “MCP clássico” nesse contexto.
  • Alternativas mencionadas: harnesses centrados em CLI, sandboxes/VMs personalizados, AXI e ferramentas genéricas de “fazer requisição HTTP” com boas especificações.

Sentimento Geral

  • Consenso: MCP não é universalmente ruim, mas é supervalorizado e mal utilizado.
  • Heurística aproximada do debate: para desenvolvimento solo/local, CLIs+APIs geralmente são suficientes; MCP se torna atraente quando você precisa de padronização entre ferramentas, acesso remoto e governança centralizada.