MCP: Conectando o Claude ao Mundo Externo

📚 Navegação da Série: O artigo anterior 21 Limites de Segurança e Risco ajudou você a entender "quando confiar no AI para mexer no seu código e sistema". Este artigo muda de direção—conectando o Claude ao mundo externo. Por padrão, ele só pode acessar seus arquivos locais e a linha de comando, sem conseguir tocar no seu banco de dados, Jira ou Figma. O MCP é a interface unificada que permite conectá-lo a vários serviços externos de uma só vez.

Primeiro, um obstáculo—quando instalei meu primeiro servidor MCP, passei quase uma hora lutando contra erros no terminal.

Na época, eu queria conectar um servidor que acessava um banco de dados e copiei um comando do README de algum repositório, que era mais ou menos assim: claude mcp add db -- npx server --transport stdio. Executei, mas não conectou. Primeiro suspeitei da rede, depois suspeitei que o pacote não estivesse bem instalado, então desinstalei e reinstalei várias vezes, com o npx baixando aquele pacote repetidamente, a barra de progresso indo e voltando—mas simplesmente não conectava.

Mais tarde, ao ler a documentação oficial, descobri que a posição dos parâmetros estava errada. A documentação oficial diz claramente: todas as opções (--transport, --env, --scope) devem vir "antes" do nome do servidor, e somente após -- (traço duplo) deve vir o comando de inicialização do servidor. No comando acima, --transport stdio ficou depois de --, sendo tratado como um parâmetro passado para o servidor, o que naturalmente não foi reconhecido. Além disso, como stdio é o transporte padrão, nem precisa ser escrito—a forma correta seria claude mcp add db -- npx server, conectando instantaneamente.

Mencionei esse obstáculo para que você evite perder essa hora: o MCP em si não é difícil, o difícil são os detalhes como "posição", "escopo" e "necessidade de aprovação". Hoje vamos resolver esses problemas um por um e, finalmente, guiar você para rodar um servidor real passo a passo.

Ao terminar este artigo, você obterá:

• Uma explicação simples sobre o que é o MCP e qual lacuna do Claude ele preenche
• Quando usar cada um dos três tipos de servidor (stdio local, HTTP remoto e o obsoleto SSE), explicados em uma tabela clara
• A sintaxe correta do comando claude mcp add e a diferença entre os três escopos: local, project e user
• Como as ferramentas aparecem para o Claude após adicionar um servidor e se a primeira chamada requer sua aprovação (conectando com o tema de permissões e segurança do artigo anterior)
• Um guia prático passo a passo com saídas esperadas: conectando e testando o servidor da documentação oficial em 5 minutos

---

01 Primeiro entenda: Qual lacuna o MCP realmente preenche

Conclusão direta: Por padrão, o Claude Code é um assistente que "só trabalha localmente", e o MCP é a porta de entrada unificada para ele se conectar a vários serviços externos.

Pense no que o Claude esteve fazendo nos vinte e um artigos anteriores—lendo seus arquivos, alterando seu código, executando seus comandos. Tudo local. Por mais inteligente que ele seja, não consegue acessar aquele card no Jira da sua empresa, não se conecta aos dados do seu banco de dados de produção e não vê o layout que o designer desenhou no Figma. Ele não consegue alcançar essas informações, então você precisa copiar e colar manualmente para ele.

Analogia: Um hub/adaptador com várias portas. Seu notebook está cada vez mais fino, talvez com apenas uma ou duas portas Type-C, e você não consegue conectar HDMI, cabo de rede, pendrive ou leitor de cartão. O que fazer? Conectar um hub—um único cabo conectado e o HDMI, cabo de rede, USB e energia começam a funcionar. O MCP é para o Claude o que esse hub é para o notebook: conecte uma vez, e todas as ferramentas de serviços externos estarão disponíveis para ele.

A definição oficial é:

O Claude Code pode se conectar a centenas de ferramentas externas e fontes de dados através do Model Context Protocol (MCP), um padrão de código aberto para integração de ferramentas de IA. Os servidores MCP fornecem ao Claude Code acesso às suas ferramentas, bancos de dados e APIs.

Aqui há uma palavra-chave: padrão de código aberto. O MCP (Model Context Protocol, um protocolo aberto que define "como a IA chama ferramentas externas") não é um protocolo proprietário fechado da Anthropic, mas sim um padrão público. A vantagem é "conectar uma vez, usar em qualquer lugar"—um servidor MCP que você escreve para um banco de dados pode ser usado pelo Claude Code e também por qualquer outro cliente compatível com MCP.

Quando você deve se lembrar dele? A regra da documentação oficial é bem simples:

Quando você se pegar copiando dados de outra ferramenta (como um gerenciador de tarefas ou painel de monitoramento) para o chat, conecte um servidor.

Aqui estão alguns cenários comuns que você provavelmente enfrentará, para entender o que é possível fazer depois de conectado:

• "Implemente a funcionalidade descrita no card ENG-4521 do Jira e abra um PR no GitHub"—ele lerá o card sozinho, sem que você precise explicar
• "Com base no nosso banco de dados PostgreSQL, encontre os e-mails de 10 usuários que usaram o novo recurso este mês"—ele consultará o banco diretamente, sem precisar que você exporte um CSV e cole aqui
• "Atualize o modelo de e-mail de acordo com a nova versão de design no Figma"—ele lerá o arquivo de design diretamente, sem que você precise enviar capturas de tela

💡 Resumo em uma frase: Por padrão, o Claude só acessa arquivos e comandos locais, sem alcançar seus bancos de dados, tarefas ou designs; o MCP é a interface unificada de conexão que traz todas as ferramentas de serviços externos para ele.

---

02 Três formatos de servidor: Rodando localmente ou conectando à nuvem

Existem diferentes tipos de servidores MCP. Entender as diferenças ajuda você a saber como modificar os comandos copiados. A questão central é: este servidor está rodando na sua própria máquina ou está hospedado em algum endereço web?

Analogia: Dispositivos conectados a um hub, alguns na mesa, outros do outro lado da parede. Um pendrive ou leitor de cartões são dispositivos locais conectados ao hub bem ao seu lado; a outra ponta do cabo de rede se conecta a um servidor em um datacenter distante. Os servidores MCP também se dividem nessas duas categorias—uma rodando como um processo local na sua máquina, e outra hospedada remotamente onde você se conecta.

A documentação oficial fornece vários métodos de transporte (o meio de comunicação entre o Claude Code e o servidor), mas você só precisará de dois no dia a dia, além de um que foi descontinuado:

Formato	Onde roda	Como adicionar	Adequado para
stdio (processo local)	Na sua máquina, iniciado como subprocesso	claude mcp add <name> -- <comando>	Ferramentas que precisam ler arquivos locais diretamente, controlar navegadores locais ou se conectar a sockets de bancos de dados locais
HTTP (hospedagem remota)	Em um endereço web	claude mcp add --transport http <name> <url>	Serviços em nuvem (Sentry, Notion, GitHub, etc.), recomendado oficialmente
SSE (remoto, descontinuado)	Em um endereço web	claude mcp add --transport sse <name> <url>	Encontrado apenas em configurações antigas; prefira HTTP sempre que possível

Aqui estão alguns pontos comuns onde iniciantes costumam errar:

Servidores stdio não usam --transport. Como os processos locais usam o transporte padrão stdio, não há necessidade de especificá-lo. O ponto principal é a sequência de comandos após --—que instrui o Claude Code sobre "como iniciar este servidor". Por exemplo, o caso do Playwright (uma ferramenta que permite ao Claude interagir com navegadores):

claude mcp add playwright -- npx -y @playwright/mcp@latest

O trecho npx -y @playwright/mcp@latest após -- é o comando de inicialização, onde -y diz ao npx para instalar diretamente sem pedir confirmação. Um servidor stdio é equivalente a "o Claude iniciar um programa secundário em segundo plano para você", portanto, ele depende de você ter o ambiente correspondente instalado na sua máquina (este exemplo do Playwright requer um ambiente Node.js recente; consulte a documentação correspondente para versões específicas).

HTTP é a escolha preferida para conectar a serviços em nuvem. Citação oficial:

Servidores HTTP são a opção recomendada para conectar a servidores MCP remotos. Este é o transporte mais amplamente suportado para serviços em nuvem.

Para Sentry, Notion, GitHub, etc., você não precisa instalar nada localmente, basta fornecer uma URL para conectar:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Basta conhecer o SSE (Server-Sent Events), não o utilize para novas conexões. A documentação oficial o marca claramente como "descontinuado":

O transporte SSE (Server-Sent Events) está descontinuado. Por favor, use servidores HTTP onde disponíveis.

O SSE geralmente só é visto ao lidar com arquivos .mcp.json antigos de terceiros; use sempre HTTP para novos servidores.

💡 Resumo em uma frase: Use stdio para ferramentas locais (comando de inicialização após --, sem especificar transporte) e HTTP para serviços em nuvem (fornecendo uma URL, recomendado oficialmente); SSE está descontinuado, substitua-o sempre que encontrar.

---

03 Como adicionar um servidor: Comandos, escopos e aquele detalhe importante

Agora que conhecemos os formatos, vamos ver como adicionar. Dois comandos resolvem tudo, o resto são detalhes.

Para adicionar um servidor HTTP remoto—use --transport http, dê um nome e forneça a URL:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Para adicionar um servidor stdio local—não defina o transporte e coloque o comando de inicialização após --:

claude mcp add airtable -- npx -y airtable-mcp-server

É aqui que ocorre o erro mencionado no início, enfatizado oficialmente em um bloco Note, algo que você deve guardar com atenção:

Todas as opções (--transport, --env, --scope, --header) devem vir antes do nome do servidor. Depois, o -- (traço duplo) separa o nome do servidor do comando e argumentos passados para o servidor MCP.

Em resumo: todos os parâmetros do próprio claude mcp add devem vir antes, e tudo após -- é destinado ao servidor. Uma única posição errada fará o comando falhar.

Três escopos: Em quais projetos este servidor pode ser usado

Ao adicionar um servidor, há outra escolha inevitável: este servidor é apenas para o projeto atual, compartilhado com toda a equipe ou para todos os seus projetos? É disso que o "escopo" cuida, especificado com --scope.

Analogia: Como uma impressora é compartilhada no escritório. Algumas impressoras estão conectadas apenas ao seu computador e só você pode imprimir (local); outras são compartilhadas com o departamento e registradas na lista de ativos, para que toda a equipe possa usá-las (project, rastreada no git); e há a sua própria impressora portátil que você carrega para qualquer estação de trabalho ou sala de reuniões (user, multi-projeto). Os três escopos representam exatamente isso.

As diferenças entre os três escopos fornecidos oficialmente são apresentadas nesta tabela:

Escopo	Em quais projetos é carregado	Compartilhado com a equipe?	Onde é salvo
local (padrão)	Apenas no projeto atual	Não, privado para você	~/.claude.json (sob a entrada deste projeto)
project	Apenas no projeto atual	Sim, via controle de versão	.mcp.json na raiz do projeto
user	Todos os seus projetos	Não, privado para você	~/.claude.json (em mcpServers global)

Como escolher? Lembre-se destas três regras:

• Experimentos pessoais ou configurações com credenciais que você não quer versionar → local (padrão, é usado se você omitir --scope)
• Se quiser que toda a equipe use a mesma configuração → project, que salva no .mcp.json para ser enviado ao git, ficando disponível para os colegas ao baixarem o projeto
• Uso diário pessoal em múltiplos projetos → user, adicione uma vez e use em qualquer projeto

# Para usar em todos os projetos (escopo user)
claude mcp add --scope user --transport http sentry https://mcp.sentry.dev/mcp

# Para compartilhar com a equipe (escopo project, salva no .mcp.json)
claude mcp add --scope project --transport http github https://api.githubcopilot.com/mcp/

Com base na minha experiência, criei um hábito: para serviços de uso diário pessoal como Sentry e GitHub, uso sempre user—configuro apenas uma vez no primeiro projeto e eles ficam disponíveis automaticamente nos novos, evitando reconfigurações. No início, eu usava o padrão local por comodidade, mas tinha que reconfigurar toda vez que trocava de projeto, até perceber que o ideal era usar user. Só uso project para salvar no .mcp.json quando "o servidor é exclusivo deste projeto e precisa ser compartilhado com os colaboradores".

Você também pode escrever diretamente no .mcp.json

O arquivo de escopo project também pode ser escrito manualmente. Ele é essencialmente um JSON com campos diferentes para servidores HTTP e stdio:

{
  "mcpServers": {
    "claude-code-docs": {
      "type": "http",
      "url": "https://code.claude.com/docs/mcp"
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

HTTP usa url, enquanto stdio usa command e args. Ao incluí-lo no repositório, você fornece à equipe uma abordagem de "configuração como código"—qualquer um que clonar o projeto e iniciar o Claude Code lerá essa configuração. Observe um aviso importante da documentação oficial: você deve sair e reiniciar a sessão após alterar o .mcp.json para que as mudanças façam efeito, pois o Claude Code só lê esse arquivo na inicialização.

💡 Resumo em uma frase: Use --transport http com URL para HTTP e -- seguido do comando para stdio, colocando todas as opções antes do nome do servidor; lembre-se das três regras de escopo—local para experimentos pessoais, user para uso multi-projeto e project (salvo no .mcp.json) para compartilhar com a equipe.

Esta imagem representa o papel do MCP como o "hub" intermediário: à esquerda estão as ferramentas locais integradas do Claude Code (leitura/escrita de arquivos, execução de comandos) e à direita está o mundo externo que ele normalmente não alcançaria (GitHub, Jira, PostgreSQL, Figma, Sentry)—a camada MCP no meio usa conexões stdio e HTTP para uni-los, fazendo com que as ferramentas de serviços externos fiquem acessíveis diretamente para o Claude.

---

04 Após a configuração: Como as ferramentas aparecem e se a chamada requer aprovação

Com o servidor configurado, o que acontece a seguir conecta-se diretamente com o gerenciamento de permissões do artigo anterior.

Primeiramente, como as ferramentas "aparecem". Cada servidor MCP traz um conjunto de ferramentas (por exemplo, o servidor do GitHub traz recursos para "ler PRs" ou "abrir issues"). Uma vez adicionadas, essas ferramentas são registradas no Claude, que passa a poder chamá-las como se fossem nativas. Como você confirma se a conexão foi feita e quais ferramentas estão disponíveis? Use estes dois comandos:

# No terminal: lista todos os servidores configurados e seus status de conexão
claude mcp list

# Dentro da sessão do Claude: exibe o status de cada servidor e suas ferramentas
/mcp

O comando claude mcp list exibirá o status de cada servidor. É importante conhecer estas marcações (pois elas mostram por que seu servidor pode não estar funcionando):

Status	Significado
✓ Connected	Conectado e pronto para uso
! Needs authentication	Conectado, mas requer login (OAuth ou token); faça a autenticação usando /mcp
✗ Failed to connect / Connection error	Falha ao conectar (o servidor não responde ou o comando falhou); verifique o comando ou URL
⏸ Pending approval	Servidor de projeto vindo do .mcp.json que ainda não foi aprovado por você

Esse status ⏸ Pending approval representa a primeira etapa de aprovação. O design oficial é bastante cauteloso:

Por razões de segurança, o Claude Code solicitará aprovação antes de usar servidores de escopo de projeto definidos no arquivo .mcp.json.

Por que isso é necessário? Pense bem: você clona o repositório de outra pessoa, e o .mcp.json dela contém instruções para "iniciar um servidor local ao iniciar". Se ele rodasse automaticamente sem o seu consentimento, seria equivalente a um repositório externo iniciar um processo silenciosamente na sua máquina. Essa etapa de aprovação impede isso—conectando com o tema de segurança do artigo anterior, quando algo vier de uma origem desconhecida, o sistema para e aguarda sua confirmação. (Se você rejeitar algo sem querer, pode redefinir as opções com claude mcp reset-project-choices.)

A segunda etapa de aprovação ocorre quando uma ferramenta é chamada pela primeira vez. A documentação oficial menciona no guia de início rápido:

A primeira vez que o Claude chamar um servidor, ele solicitará permissão para usar a nova ferramenta. Aprove para continuar.

Ou seja, configurar o servidor não significa que o Claude pode usar as ferramentas livremente. Na primeira vez que ele precisar chamar uma ferramenta MCP específica, ele irá parar e pedir sua permissão—o que segue o mesmo mecanismo de permissão visto nos capítulos anteriores para alteração de arquivos e execução de comandos. Ele só agirá se você aprovar.

Há também um detalhe prático para "verificação": quando o Claude chama uma ferramenta MCP, o nome do servidor correspondente é exibido ao lado da chamada da ferramenta no console. Essa é a sua evidência de que "a resposta realmente veio do serviço externo, em vez de ser gerada por ele". Por exemplo, após conectar ao Sentry, ver o rótulo sentry ao lado da chamada garante que ele consultou um erro real, em vez de alucinar um resultado.

💡 Resumo em uma frase: As ferramentas MCP configuradas são expostas ao Claude, mas contam com duas barreiras de aprovação—o servidor do .mcp.json precisa de aprovação ao ser carregado pela primeira vez, e cada ferramenta precisa de aprovação na primeira chamada; a presença do nome do servidor na saída serve como prova de que a resposta veio do serviço externo.

---

05 O problema da confiança em servidores de terceiros: Não conecte qualquer coisa

Esta seção é a mais curta, mas é a mais importante de não ser ignorada—ela se conecta diretamente aos limites de segurança do artigo anterior.

Primeiramente, vejamos este aviso de atenção original da documentação oficial:

Antes de conectar a qualquer servidor, certifique-se de que confia nele. Servidores que obtêm conteúdo externo podem expor você a riscos de injeção de prompt.

Em termos simples: servidores MCP contêm códigos e serviços escritos por terceiros, e a Anthropic não realiza auditorias de segurança para você. As conexões listadas no diretório oficial (Anthropic Directory) passam por uma triagem básica, mas para qualquer servidor fora do diretório, você deve avaliar a confiabilidade por conta própria.

Analogia: Adicionar uma biblioteca de terceiros a um projeto de produção. Você não executaria simplesmente um npm install para um pacote desconhecido, cujo autor você não sabe quem é, e o colocaria no seu código de produção—primeiro você pesquisaria quem o mantém, quantas pessoas usam e sua reputação. Um servidor MCP funciona essencialmente como essa "dependência de terceiros": avalie a origem antes de instalar, especialmente se ele for ler dados externos (páginas da web, tarefas, e-mails).

Por que servidores que acessam conteúdo externo oferecem mais riscos? Porque eles são terrenos férteis para injeções de prompt (prompt injection)—um problema detalhado no artigo anterior. Simplificando: a página web ou o card do gerenciador lido pelo servidor pode conter instruções maliciosas ocultas "destinadas à IA", fazendo o Claude desviar do comportamento esperado. Quanto menos confiável for a fonte dos dados lidos pelo servidor, maior será o risco.

Aqui estão algumas diretrizes práticas para conectar servidores que você pode seguir:

Cenário	Conectar ou não
Conectores avaliados no diretório oficial (Anthropic Directory)	✅ Dê prioridade a estes
Servidores oficiais de grandes empresas (como GitHub, Sentry, Notion)	✅ Relativamente seguros
Servidores de terceiros no GitHub com poucas estrelas	⚠️ Analise o código-fonte antes de conectar
Dar permissão de escrita em banco de dados de produção a um servidor	❌ Use acesso somente leitura sempre que possível; evite dar permissão de escrita

A última regra é de suma importância. No exemplo de banco de dados oficial, a DSN especifica claramente readonly (conta somente leitura)—usar credenciais de somente leitura em vez de escrita é a forma mais prática de minimizar riscos.

💡 Resumo em uma frase: Servidores MCP usam códigos de terceiros que a Anthropic não audita; valide a confiabilidade antes de conectar, priorize servidores do diretório oficial ou de grandes empresas, cuidado com injeções de prompt em servidores que leem dados externos e use sempre contas somente leitura para bancos de dados.

---

06 Prática: Conectando e testando um servidor real em 5 minutos

A teoria sem a prática de nada vale. Vamos conectar o servidor da documentação oficial—um servidor HTTP remoto que não exige login nem configurações complexas, sendo ideal para treinar. O processo não depende de nenhum ambiente local complexo.

Este servidor é um serviço HTTP hospedado remotamente, portanto requer conexão com a internet.

Passo 1: Adicionar o servidor (no terminal externo, não dentro da sessão claude)

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

Saída esperada: Uma linha de confirmação como Added HTTP MCP server claude-code-docs with URL: https://code.claude.com/docs/mcp to local config. Ver Added = Configuração salva (observe que indica local config, ou seja, o escopo local padrão que afeta apenas o projeto atual).

Passo 2: Verificar o status de conexão

claude mcp list

Saída esperada: O servidor claude-code-docs aparecerá listado com a marcação ✓ Connected. Ver este símbolo verde = Conexão estabelecida com sucesso. Se exibir ✗ Failed to connect, o motivo provavelmente é falha de conexão de rede.

Passo 3: Entrar na sessão e solicitar o uso desse servidor

claude

Inicie a sessão e digite (mencionando explicitamente o servidor para garantir que ele use o MCP em vez da busca nativa na web):

Use o servidor claude-code-docs para verificar a função da variável de ambiente MCP_TIMEOUT

Saída esperada: O Claude irá parar e solicitar aprovação na primeira chamada deste servidor (como visto na Seção 04)—aprove a chamada. Em seguida, ele retornará a explicação para MCP_TIMEOUT (usada para configurar o tempo limite de inicialização do servidor MCP) e o console mostrará a identificação claude-code-docs ao lado da ferramenta chamada. Ver esse rótulo confirma que a resposta veio diretamente do servidor da documentação.

Passo 4: Limpeza (opcional)

Para remover o servidor após o teste:

claude mcp remove claude-code-docs

Saída esperada: Confirmação de remoção no terminal. Ao rodar claude mcp list novamente, claude-code-docs não constará mais na lista.

Vale destacar uma dica oficial: cada servidor conectado consome uma parte da janela de contexto (suas definições de ferramentas e descrições são carregadas em todas as sessões). Como vimos no artigo anterior, o excesso de informações pode prejudicar a assertividade do modelo—remova os servidores que não estão em uso para liberar espaço de contexto.

Ao concluir estes quatro passos, você terá testado todo o fluxo básico: "adicionar servidor → verificar status → aprovar chamada → remover". Qualquer outro servidor MCP seguirá o mesmo fluxo básico, variando apenas o nome, URL/comando, parametrização de --scope ou credenciais.

💡 Resumo em uma frase: Treinar com o servidor da documentação oficial é a forma mais segura—adicione com add, verifique com list, chame explicitamente no chat aprovando a permissão, e limpe com remove; testar esse fluxo na prática ensina muito mais do que memorizar comandos.

---

07 Resumo

Neste artigo, conectamos o Claude ao mundo externo—deixando de ser "apenas local" para acessar diversos serviços externos por uma única porta unificada, graças ao MCP.

Revisão rápida dos pontos principais:

O que você quer fazer	O que usar	Ponto-chave
Entender o papel do MCP	Um padrão de integração aberto	O Claude nativamente não acessa serviços externos; o MCP serve como ponte unificada
Conectar ferramentas locais	stdio	claude mcp add <name> -- <comando>, sem especificar transporte
Conectar serviços em nuvem	HTTP	--transport http com URL (recomendado oficialmente)
Definir onde usar o servidor	Escopo	local para uso único, user para uso global pessoal e project (salvo no .mcp.json) para a equipe
Confirmar status e ferramentas	claude mcp list / /mcp	Identificar os status como ✓ Connected e ⏸ Pending approval
Controlar permissão de ferramentas	Duas etapas de aprovação	Aprovar na primeira carga do servidor do projeto e na primeira chamada de cada ferramenta

Agora você deve ser capaz de: Entender qual lacuna o MCP preenche no Claude, diferenciar como adicionar servidores stdio e HTTP, configurar o escopo correto com --scope, usar claude mcp list e /mcp para validar o status, compreender as duas etapas de aprovação exigidas e adotar cautela antes de conectar servidores de terceiros. Essa capacidade de integração externa é a chave para transformar o Claude de um assistente de código local em um agente capaz de operar toda a sua infraestrutura de ferramentas.

Essa interface resolve o problema inicial daquela perda de tempo de uma hora—lembrar de "colocar as opções antes do nome do servidor e o comando após --" evitará que você cometa erros comuns.

---

No próximo artigo, 23 "Subagentes (Subagents)"—o MCP expande muito o que um único Claude pode realizar. Contudo, quando há muitas tarefas, um único Claude pode ficar sobrecarregado e ter sua janela de contexto esgotada. O próximo artigo trará uma nova abordagem: em vez de sobrecarregar um único Claude, você aprenderá a delegar tarefas a uma equipe de subagentes focados com contextos independentes—onde o agente principal delega e os subagentes executam suas partes sem misturar seus contextos. Imagine: delegar "verificar logs", "escrever testes" e "executar compilação" para três subagentes trabalharem simultaneamente e sem interferência mútua, não seria muito mais eficiente do que alternar o foco do Claude o tempo todo?

---

Leitura Recomendada

• GitHub Actions: Mencionando com @ em um PR para deixar o Claude trabalhar sozinho
• Modo de Voz (Voice Mode): Falando os seus prompts em vez de digitá-los
• Conectando modelos de terceiros e locais