O MCP conecta o Claude Code a serviços e ferramentas externas. Em um teste relatado pelo The New Stack, uma sessão nova consultou registros da Bit Cloud e encontrou a entidade compartilhada de tickets e suas relações com um aplicativo e um serviço. O autor do relato, engenheiro da Bit Cloud, descreveu a demonstração em primeira mão.
O que a sessão encontrou
O ambiente começou sem código local nem histórico de conversa. Com duas chamadas — read_scope e read_components —, o Claude Code recuperou quatro componentes: um aplicativo em React, um serviço em Express com MongoDB, uma entidade compartilhada de tickets e um gateway. O aplicativo e o serviço dependiam da mesma versão da entidade.
Esse é um uso concreto dos registros versionados: ajudar a reconstruir relações entre componentes a partir de informações ligadas às versões, mesmo quando o código e a conversa anterior não estão na sessão. No caso descrito, os quatro componentes também dependiam de 16 componentes preexistentes; dez vinham do Bit Design Sparks.
Registros de dependências respondem a uma pergunta estrutural — qual versão depende de qual componente. Já a memória do Claude Code pode guardar instruções e decisões de projeto, como o motivo para descartar uma funcionalidade. São informações complementares: o mapa de dependências ajuda a localizar relações no sistema; a memória pode preservar a intenção por trás das escolhas. Para saber mais sobre memória persistente, veja também esta explicação sobre a memória do Claude Code entre projetos.
O que a alteração e os testes cobriram
Depois de importar os quatro componentes e inspecionar o código-fonte, o Claude Code implementou filtros por status e responsável no aplicativo. A mudança foi feita no lado do cliente e não alterou a entidade nem o serviço. O relato contabilizou 41 testes aprovados, incluindo nove novos testes de filtragem.
O autor informou que os testes de integração com MongoDB podiam ser ignorados caso o executor de CI não conseguisse iniciar o banco temporário. Ele também testou manualmente a persistência: criou um ticket, adicionou um comentário, reiniciou a plataforma usando o mesmo banco e verificou que os dois continuavam lá.
A referência de API do aplicativo listava rotas de um serviço fictício usado nos testes. O autor não comparou essas rotas com as do serviço real. Assim, a demonstração descreve a descoberta das dependências e uma alteração no aplicativo; a validação das rotas do serviço real ficou fora do teste relatado.
Como escolher o escopo de configuração
A Anthropic descreve três escopos para configurar conexões MCP no Claude Code: local, project e user. O escopo project compartilha a configuração com a equipe por meio de um arquivo .mcp.json na raiz do projeto; os outros dois se aplicam ao uso individual. A documentação de configuração da Anthropic define as opções desta forma:
| Escopo | Onde se aplica | Compartilhado com a equipe? |
local | Projeto atual na máquina do desenvolvedor | Não; fica restrito ao uso local |
project | Projeto, com configuração em .mcp.json na raiz | Sim |
user | Projetos daquele desenvolvedor | Não; aplica-se ao usuário |
Para experimentar uma conexão no projeto da própria máquina, local atende a esse escopo. Se a equipe precisa compartilhar a configuração no repositório, project é a opção descrita pela Anthropic. Já user mantém a configuração associada aos projetos de uma pessoa.
O que o MCP carrega no contexto
MCP é a forma de conectar o Claude Code a ferramentas e serviços externos; Skills oferecem conhecimento reutilizável ou fluxos de trabalho. A visão geral de recursos da Anthropic informa que os nomes das ferramentas MCP são carregados no início da sessão, enquanto os esquemas completos ficam para quando forem necessários. A Anthropic caracteriza como baixo o custo de contexto das ferramentas MCP ociosas.
