Você constrói servidores MCP. Talvez já tenha publicado alguns — um conector Postgres, uma bridge pro Slack, uma ferramenta de sistema de arquivos. Eles funcionam com o Claude, com o Cursor, com qualquer client que fale o protocolo. Em abril de 2026, o ecossistema já hospeda milhares de servidores feitos pela comunidade em registries como Smithery, Glama e mcp.so. O protocolo venceu. O open source venceu. Certo?
Olhe com mais cuidado.
Você já conhece a linha do tempo: a Anthropic lançou os Managed Agents em 8 de abril, Routines e a reformulação do Desktop em 14 de abril, e depois tudo caiu por três horas no dia 15 de abril. A OpenAI e o Google lançaram alternativas open-source e model-agnostic. O risco de lock-in é óbvio. O que é menos óbvio é a pergunta mais silenciosa: será que o design técnico do MCP favorece estruturalmente a empresa que o escreveu?
Três decisões na spec sugerem que sim.
Camada de transporte
O MCP foi lançado com stdio como transporte primário — standard input/output, o mecanismo que os pipes do Unix usam. Stdio é inerentemente local. Funciona melhor quando o client MCP roda na sua máquina como CLI ou app desktop. Percebeu alguma coisa? O Claude Code é exatamente isso: uma CLI local que spawna processos de servidores MCP. Que coincidência engraçada o transporte padrão do protocolo ser justamente aquele onde o produto da Anthropic joga em casa.
Transportes remotos (HTTP+SSE, depois Streamable HTTP) chegaram depois e funcionam bem, mas o centro de gravidade do ecossistema — as implementações de servidor mais testadas em batalha, as configurações padrão dos tutoriais, os guias de "getting started" — ainda assume um runtime local. A Anthropic não mandou usar stdio. Só transformou ele no caminho de menor resistência, e milhares de devs seguiram direitinho.
Sampling
A spec do MCP inclui uma capability chamada "sampling" — um servidor pode pedir ao client que faça uma chamada de LLM em nome dele. Seu conector de banco de dados pode dizer: "Preciso que a IA analise esse query plan — client, resolve aí." O client escolhe o modelo. A spec é model-agnostic na teoria.
Na prática, a spec literalmente permite que o servidor diga "ei client, chama sua LLM pra mim" — e aí todo mundo finge surpresa quando essa LLM é sempre o Claude. Desenvolvedores de servidores testam contra o client que usam todo dia. O client MCP mais polido e mais bem financiado é o Claude Code. Então os devs otimizam requests de sampling pro Claude, debugam no Claude, deployam assumindo Claude. O protocolo continua neutro. O ecossistema gravita. E gravidade, uma vez estabelecida, não se reverte porque alguém escreveu um post inflamado sobre neutralidade de vendor.
Governança da spec
Funcionários da Anthropic mantêm os SDKs oficiais de TypeScript e Python do MCP. Funcionários da Anthropic dirigem o repositório GitHub da spec. Quando o protocolo adicionou OAuth 2.1 na revisão de março de 2025, a Anthropic mapeou os design patterns limpinho pra sua própria infraestrutura cloud — e doze meses depois, os Managed Agents foram lançados com OAuth integrado. Que coincidência.
Não existe um órgão de padrões independente. Nenhum processo W3C, nenhum RFC da IETF, nenhum voto de consórcio. Uma empresa escreve a spec. A mesma empresa constrói a implementação mais lucrativa dessa spec. Se você não vê o problema, nunca leu o estatuto de um órgão de padronização — ou trabalha na Anthropic.
Você já viu esse filme antes
Se essa arquitetura parece familiar, talvez você lembre do USB.
A Intel co-projetou o Universal Serial Bus em meados dos anos 1990 e presidiu o USB Implementers Forum — o órgão que governa a spec até hoje. O padrão era aberto. Qualquer fabricante de chips podia implementar. Mas a Intel despachou os primeiros host controllers, escreveu as implementações de referência e integrou suporte USB nos seus chipsets antes dos concorrentes terem silício funcionando. Quando AMD e VIA alcançaram, os controllers da Intel já definiam o que "compatível com USB" significava na prática. A spec pertencia a todos. A vantagem de first-mover pertencia à Intel.
Ontem cobrimos a versão AOSP-pra-Play-Services desse playbook — a Anthropic executa ele uma camada mais fundo, no próprio protocolo.
O MCP é a spec USB da Anthropic. Claude Code, Routines, Managed Agents, Desktop — esses são os primeiros host controllers. A comunidade constrói milhares de servidores MCP. A Anthropic constrói o único client runtime totalmente integrado que empilha do protocolo à IDE à orquestração cloud. O Agents SDK da OpenAI — open-source sob MIT em 15 de abril, suportando mais de 100 modelos via LiteLLM — e o ADK do Google — open-source no Cloud Next em abril de 2025, suportando tanto MCP quanto o protocolo A2A de agent-to-agent — escolheram a arquitetura oposta: runtimes abertos, model-agnostic, sem acoplamento a cloud proprietária. Eles entenderam o jogo porque viram a Intel jogá-lo trinta anos atrás.
O que realmente te protege
Mantenha sua lógica de negócio em servidores MCP — esses são portáveis. Trate o client runtime como uma casca substituível. Se você configura uma Routine, documente ela bem o suficiente pra replicar como um cron job ou num orquestrador concorrente. Se você armazena sessions nos Managed Agents, garanta que seu schema de sessão exporta limpo. Se seu workflow de agente depende da sidebar multi-session do Claude Desktop, pergunte a si mesmo o que acontece quando um client melhor aparecer.
Construa na porta USB. Não solde ela num laptop só.
A Anthropic não apenas abriu o código de um protocolo e depois construiu produtos proprietários em cima. Ela projetou um protocolo cujo transporte padrão, gravidade de testes e estrutura de governança — tudo inclina na direção dos seus produtos. Isso não é hipocrisia. É arquitetura. E o playbook tem trinta anos de idade.
