——|—–|———–|
| Task não precisa de MCP | `–bare` | Zero overhead, sem MCP |
|---|---|---|
| Task precisa de MCP | `MCP_CONNECTION_NONBLOCKING=true` | MCP disponível, sem bloqueio |
| Task precisa de MCP + nada mais | `–bare –mcp-config servers.json` + `MCP_CONNECTION_NONBLOCKING=true` | Startup mínimo + MCP non-blocking |
O --bare (já cobri isso aqui) elimina hooks, skills, plugins, MCP, auto memory, CLAUDE.md. É o modo cirúrgico. Mas se sua task precisa de MCP servers, você pode combinar: --bare pra eliminar todo o resto, --mcp-config pra carregar só os servers que precisa, e MCP_CONNECTION_NONBLOCKING=true pra não esperar eles conectarem.
É configuração granular. Cada segundo conta em pipeline.
Por que isso importa para sua Software House
O imposto invisível do MCP
Toda SH que adotou MCP servers está pagando um imposto que ninguém contabiliza: tempo de startup.
Você configurou um MCP server pro banco de dados (pra Claude consultar schemas). Outro pro Jira (pra ler tickets). Outro pro Slack (pra notificar resultados). Cada um adiciona 300ms a 2s no startup de cada execução claude -p.
O problema escala rápido:
| MCP Servers | Cold start médio | Execuções/dia | Overhead/dia | Overhead/mês |
|---|---|---|---|---|
| 2 | 800ms | 50 | 80s | 40min |
| 3 | 1.2s | 100 | 120s | 60min |
| 5 | 1.5s | 200 | 300s | 2.5h |
E isso é só o overhead de conexão. Não conta processamento, não conta rate limits, não conta nada útil. É tempo puro desperdiçado esperando handshakes.
O efeito cascata em agent teams
Se você usa Agent Teams — múltiplos agentes trabalhando em paralelo — o problema multiplica. Cada subagent que precisa de MCP servers paga seu próprio overhead de startup. Um orquestrador com 4 subagents, cada um com 3 MCP servers de 1s, são potencialmente 12 segundos de overhead só de conexão.
Com MCP_CONNECTION_NONBLOCKING=true, cada subagent começa imediatamente. Os MCP servers vão conectando em background enquanto o agente já está analisando código, lendo arquivos, pensando no problema. Quando ele precisa de uma ferramenta MCP, ela provavelmente já está disponível.
Performance como feature de produto
Não é sobre segundos. É sobre percepção. Uma pipeline que responde em 3s passa a impressão de que a IA está funcionando. Uma que fica 8s parada antes de fazer qualquer coisa passa a impressão de que quebrou.
Na minha experiência mentorando software houses, quando a automação “parece lenta”, a equipe para de confiar nela. E quando a equipe não confia, ela desliga. Cada segundo de startup é um voto contra a adoção de IA na sua empresa.
O ecossistema de performance do Claude Code
A Anthropic tem construído um arsenal de otimizações para -p mode ao longo das últimas versões:
1. --bare (v2.1.81) — elimina tudo que não é essencial, startup mínimo
2. Startup paralelo — setup() roda em paralelo com carregamento de slash commands e agents
3. HTTP/SSE MCP otimizado — ~600ms economizados para servers não autenticados
4. MCP_CONNECTION_NONBLOCKING (v2.1.89) — conexão MCP non-blocking
5. Bounded timeout 5s — nunca mais pipeline travada por server morto
Cada uma dessas otimizações ataca uma fatia diferente do startup. Juntas, uma pipeline que levava 8-10s pra iniciar pode cair pra 1-2s.
Segundo benchmarks recentes de MCP servers, caching pode reduzir latência de tool calls de 2.485ms para 0.01ms — uma melhoria de 41x. Combinado com non-blocking connections, o overhead de MCP em pipelines se torna quase imperceptível.
O que eu penso
Essa feature é daquelas que parece óbvia depois que existe. “Por que esperava tudo conectar?” É a pergunta que todo mundo faz. Mas implementar non-blocking connections com garantia de que as ferramentas ficam disponíveis no momento certo, sem race conditions, sem erros silenciosos — isso é engenharia séria.
O que me anima é a direção. A Anthropic está tratando claude -p como infraestrutura de produção, não como uma curiosidade de dev. --bare, non-blocking MCP, bounded timeouts, defer hooks — cada feature dessas é um sinal de que IA em pipeline não é mais experimento. É produção.
E se você ainda está rodando claude -p sem --bare, sem MCP_CONNECTION_NONBLOCKING, sem hooks configurados — você está usando 30% do potencial. É como ter um Ferrari e só andar na primeira marcha.
Conclusão
MCP_CONNECTION_NONBLOCKING=true é uma variável de ambiente. Uma linha. Mas representa uma mudança de mentalidade: sua pipeline não precisa esperar o que não precisa esperar.
Se sua software house usa MCP servers em automações com Claude Code — e se não usa, deveria — adicione essa variável hoje. No GitHub Actions, no GitLab CI, no script local. Onde quer que você rode claude -p.
Combinada com --bare para tasks que não precisam de MCP, e com o bounded timeout de 5s para proteção contra servers mortos, sua pipeline fica rápida, resiliente e previsível. Que é exatamente o que produção exige.
Se você quer implementar esse nível de otimização de IA na sua software house e não sabe por onde começar, vem conversar. A gente já ajudou centenas de SHs a transformar IA de brinquedo em infraestrutura de verdade.
Sou Thulio, mentoro 300+ SHs desde 2016.
