Você disse não a MCP

Artigo original ↗ Discussão no Hacker News ↗

Pi, um harness minimalista de agente de programação, está revertendo sua posição anterior de “sem MCP” ao adicionar suporte integrado ao Model Context Protocol e uma nova camada de script “Codemode”, gerando debate sobre se isso enfraquece sua filosofia original. Os კომენტadores comparam MCP com CLIs tradicionais e APIs no estilo OpenAPI, discutindo composabilidade, segurança, governança empresarial e como as ferramentas devem ser expostas a LLMs e agentes. Muitos veem MCP e Codemode como compromissos pragmáticos que se alinham com a forma como os modelos modernos são treinados e com a forma como as equipes realmente operam, enquanto outros temem o aumento gradual de complexidade e a proliferação de padrões sobrepostos.

O que é MCP e por que é controverso

  • MCP (Model Context Protocol) é descrito como uma forma padronizada para agentes/LLMs descobrirem e chamarem ferramentas/APIs, incluindo autenticação, documentação e metadados estruturados de ferramentas.
  • Os apoiadores veem isso como “API + docs” ou “RPC autodescritivo”, o que torna as ferramentas descobríveis e mais fáceis para usuários comuns e UIs de “IA de consumo” (ChatGPT, Claude, etc.).
  • Os críticos argumentam que muito disso poderia ter sido feito estendendo OpenAPI ou IDLs existentes; alguns veem MCP como NIH e redundante com “CLI + skills” ou REST.

Mudança na filosofia do Pi: de “sem MCP” para MCP встроado

  • O Pi era originalmente valorizado como um harness de programação minimalista, altamente personalizável e no estilo yolo: sem modelo de permissões, sem MCP, núcleo muito básico com extensões para tudo.
  • Alguns usuários acolhem MCP no núcleo porque MCP se tornou comum em empresas e outros harnesses; usar extensões para uma capacidade tão central parecia estranho.
  • Outros temem que isso seja o início de um inchaço de funcionalidades e de uma mudança para longe de “este harness é seu” em direção a “produto de programação opinativo”, especialmente com outras ofertas comerciais ao redor.
  • Os mantenedores enfatizam que nada novo é habilitado por padrão; os recursos podem ser desligados ou mantidos como extensões/forks.

Codemode: por que não apenas Bash?

  • Codemode é um ambiente de scripts em sandbox (frequentemente JS/TS) para orquestrar chamadas de ferramentas e MCP no nível do harness.
  • Defensores:
    • Menos idas e voltas ao modelo, menos tokens, melhor paralelização.
    • Funciona em ambientes sem acesso ao shell e permite modelos de permissão distintos das contas do sistema operacional.
    • Permite que ferramentas MCP sejam compostas dentro de uma única sandbox, em vez de cada servidor MCP ter a sua própria.
  • Céticos:
    • Os modelos já encadeiam bash/Python extremamente bem; adicionar codemode parece reinvenção e complexidade.
    • Para agentes de codificação locais, um shell restrito em uma VM/container sandbox pode ser mais simples e transparente.
    • Codemode resolve principalmente problemas criados por MCP/pelo design do harness, não limitações inerentes.

MCP vs CLI/skills/OpenAPI e empresa vs local

  • Lado “equipe/empresa”:
    • MCP sobre HTTP fornece autenticação centralizada, fluxos OAuth, telemetria, skills/prompts revogáveis e distribuição/versionamento mais fácil de ferramentas entre muitos usuários.
    • Alguns usam prompts/recursos MCP para gerenciar centralmente comandos do tipo / e pequeno estado compartilhado.
  • Lado “local/usuário avançado”:
    • CLI + skills são mais fáceis de depurar, componíveis via bash e funcionam com qualquer harness que suporte ferramentas de shell.
    • MCP pode inflar o contexto, é implementado de forma inconsistente entre clientes e fica atrás em básicos como upload de arquivos.
  • Há concordância de que MCP está melhorando (HTTP sem estado, melhores ferramentas), mas discordância sobre se ele é fundamentalmente necessário ou apenas mais um estilo de API.

Subagentes, contexto e composabilidade

  • Alguns dependem fortemente de subagentes e sessões separadas para gerenciar contexto e custo; outros acham subagentes opacos, pouco amigáveis a cache e preferem sessões longas únicas com compactação personalizada.
  • “MCP não compõe” é debatido:
    • Uma visão: codemode mais sandboxes no nível do harness resolve em grande parte a composição de múltiplos MCPs.
    • Outra: design adequado de ferramentas e REST/HATEOAS poderiam fornecer melhor descoberta incremental e composição do que os padrões atuais de MCP.

Meta: ciclos de hype e influenciadores

  • Vários comentários criticam a onda anterior de “MCP morreu, CLI venceu” como hype dirigido por influenciadores, agora invertido à medida que a adoção de MCP cresce.
  • Alguns veem MCP vs CLI em parte como cultural: devs orientados a UNIX localmente vs usuários empresariais e sem terminal.
  • O sentimento geral: MCP não é mágica nem inútil; é uma troca que se encaixa melhor em algumas pilhas (especialmente empresariais/GUI) do que em outras (desenvolvimento local com shell).