ODANIGEEK

Minha operação com IA nunca usou MCP. O que isso me deu e o que me custa

O Dani Geek — arte original

Em 20 de setembro de 2026 uma thread chamada “Why MCP Was Always a Bad Idea” voltou ao topo do Hacker News. Aqui dentro o agente roda por linha de comando e fala com o Notion por API desde o começo, então dá pra descrever o desenho real, com a conta que ele cobra.

O que o protocolo foi anunciado pra resolver

A Anthropic anunciou o Model Context Protocol em 25 de novembro de 2024. O problema descrito no anúncio é de integração: modelos presos atrás de silos de informação e sistemas legados, com cada nova fonte de dados exigindo a própria implementação sob medida. A promessa era trocar N×M integrações por um protocolo só. O primeiro release do SDK TypeScript, a versão 0.4.0, apareceu no npm em 11 de novembro de 2024, duas semanas antes do anúncio público, segundo o levantamento do HackerNoon.

Registro isso porque a versão que circulou no HN é outra: a de que o MCP nasceu para modelos que ainda não sabiam escrever nem rodar código, e que envelheceu quando o modelo aprendeu a abrir um terminal. É uma leitura retrospectiva: o texto original justifica o protocolo pelo isolamento de dados.

A crítica já tinha seis meses quando chegou ao topo

O mesmo levantamento do HackerNoon mostra que a posição “um agente com terminal faz quase tudo que o MCP faz, com mais flexibilidade e por uma fração dos tokens” está registrada desde março de 2026. Os incômodos citados por quem defende essa posição:

A thread de 20 de setembro girou em torno de dois eixos, ponte JSON-RPC rasa e segurança, conforme o comentário do Simon Willison e o registro do agregador Alto. Antes dela o HN já tinha discutido “MCP is dead?” e “MCP is dead; long live MCP”. O ciclo se repete com frequência suficiente pra que mais um anúncio de óbito não informe muita coisa.

Como a operação roda aqui

Nenhum MCP server. O agente é chamado em modo headless, por linha de comando, e o comando é montado num único ponto do código. Quando a chamada nasce em cinco lugares, cinco lugares podem esquecer uma restrição.

As ferramentas que o agente pode usar vão numa flag que restringe de verdade o conjunto disponível. Existe uma flag parecida que apenas pré-aprova o que o modelo pedir, sem limitar nada, e trocar uma pela outra é o tipo de erro silencioso que só aparece quando o agente faz algo que ninguém esperava. Aqui a lista é curta e cabe numa linha que eu leio antes de rodar.

Notion é integração própria, em um módulo só, com o token fora do repositório. Buffer, Search Console e as APIs de métricas seguem o mesmo formato: um módulo por superfície externa, cada um removível numa manhã. Toda operação que muda estado escreve auditoria, e o padrão de qualquer coisa que age no mundo é dry-run, com opt-in explícito pra executar.

Não cheguei nesse desenho prevendo o destino do MCP; cheguei por restrição. Ferramenta a menos é superfície de erro a menos — e uso IA pesado aqui dentro: quem responde pelo que quebra é quem desenhou, então o conjunto de coisas que podem quebrar tem que caber na cabeça.

A conta que esse desenho cobra

Essa é a parte que costuma sumir dos textos que defendem CLI mais API, e é a parte que decide se o desenho serve pra você.

Não existe discovery. No MCP, um servidor se apresenta e o modelo descobre o que ele oferece. Aqui, cada integração é código meu. Quando eu quero que o agente faça algo novo com o Notion, eu escrevo a função, escrevo o teste e faço um commit. Ferramenta nova não é configuração, é release.

Servidor de terceiro não se pluga. Alguém publica um MCP server decente pra uma ferramenta que eu uso e eu não ganho isso de graça. Ou eu reimplemento a parte que interessa, ou eu fico sem.

Quando a API muda, o conserto é meu. Não existe camada intermediária absorvendo a mudança. Já paguei esse pedágio mais de uma vez.

Em troca: o contexto não carrega descrição de ferramenta que eu não uso, o conjunto de ações possíveis é pequeno o bastante pra caber na cabeça, e cada integração tem um dono óbvio no código quando o alerta toca às três da manhã.

O protocolo foi reescrito dois meses atrás

O argumento do envelhecimento esbarra numa data. Em 28 de julho de 2026 o MCP lançou uma release que quebrou compatibilidade e removeu o handshake e a camada de sessão, exatamente os pedaços que concentravam as reclamações de peso desnecessário. Segundo o HackerNoon, os obituários escritos em março foram sendo retratados sem alarde — em alguns casos por quem os escreveu. Quem quiser o outro lado do debate, com números de adoção, encontra em Is MCP Dead?, do Growth Method. A linha do tempo neutra está na Wikipédia.

Dizer que um protocolo envelheceu enquanto ele está sendo reescrito é uma avaliação sobre a versão que você conheceu.

As quatro perguntas que eu faria antes de instalar qualquer coisa

  1. Quantos clientes diferentes precisam falar com as mesmas fontes? Um cliente só, como no meu caso, tira quase toda a vantagem do protocolo.
  2. As ferramentas que você quer são de terceiros e estáveis, ou são suas e mudam toda semana? Reimplementar integração alheia é desperdício; proteger a sua com um protocolo genérico também.
  3. Quem autoriza o que o agente faz? Se a resposta ainda é “o modelo decide”, a escolha de transporte não resolve o problema.
  4. Você consegue listar de cabeça tudo que o agente pode executar? Se não consegue, você já perdeu uma coisa que vale mais do que conveniência.

O fio que fica

Se o modelo realmente descobre um CLI sozinho, o que resta pro protocolo é a camada chata: quem autoriza, quem registra, quem assina. E essa parte ninguém substitui por shell script. A pergunta que eu quero investigar na próxima peça é essa, autorização e auditoria em operações com agente, porque é onde o meu desenho também tem buraco: a auditoria aqui é minha, escrita por mim, e ninguém além de mim a revisa.

Quem roda MCP em produção há mais de seis meses tem uma informação que eu não tenho: o que quebrou na release de 28 de julho, e quanto trabalho deu consertar. Me conta no X, @odanigeek. Se der material, vira texto com o caso completo e o crédito de quem contou.

Fontes