MCP é o protocolo aberto que liga apps de IA a ferramentas e dados. Veja papéis, primitivas, transportes e segurança com um laboratório isolado.
O Model Context Protocol (MCP) é um protocolo aberto que permite a um aplicativo de IA conversar com ferramentas e dados externos de um jeito padrão. Antes do MCP, cada app de IA que queria ler arquivos, consultar um banco ou abrir um chamado precisava de uma integração própria. O MCP coloca um contrato único entre o app e aquilo a que ele se conecta. Um app que fala MCP pode usar qualquer servidor que fala MCP, e um servidor escrito uma vez funciona com todo cliente que implementa o protocolo.
Se você já entende uso de ferramentas, conhece o ciclo principal. O modelo vê uma lista de funções, pede para chamar uma delas com argumentos e recebe um resultado. O MCP não substitui esse ciclo. Ele padroniza de onde vem a lista de funções, por onde a chamada passa e o que mais um servidor pode oferecer além de funções.
O protocolo está especificado na revisão 2026-07-28, que é a que a página de especificação indica quando este artigo foi escrito. A especificação é a referência para nomes de campos e regras. Este artigo explica o modelo por trás dela, para que você leia a especificação e o código dos servidores com uma imagem clara.
Três motivos tornam o MCP útil de aprender.
O primeiro é o reúso. Um servidor de sistema de arquivos, um servidor do GitHub ou um servidor de banco de dados pode ser instalado por qualquer host compatível. Você deixa de escrever a mesma cola para cada aplicativo.
O segundo é a descoberta. O cliente pergunta ao servidor o que ele oferece, e o servidor responde com nomes, descrições e esquemas de entrada. O modelo pode então escolher entre capacidades que ninguém fixou no código do aplicativo.
O terceiro é o risco. Assim que um modelo consegue acessar seus arquivos, repositórios ou contas, a camada de ferramentas vira superfície de ataque. Muitos problemas de segurança em IA vêm de um servidor que faz mais do que a descrição diz, ou de um host que chama ferramentas sem perguntar a ninguém. O MCP deixa essas perguntas visíveis. Ele não responde por você.
A arquitetura tem três participantes. A especificação e a visão geral da arquitetura usam os mesmos nomes.
O host é o aplicativo de IA em que o usuário trabalha. Claude Desktop, Claude Code e uma IDE com assistente são hosts. O host decide a quais servidores se conectar e quais ferramentas o modelo pode usar.
O cliente é um componente dentro do host. O host cria um cliente por servidor, e cada cliente mantém uma conexão dedicada com exatamente um servidor. Se um host se conecta a três servidores, ele executa três clientes.
O servidor é um programa que expõe capacidades. Pode rodar no seu notebook como processo filho ou em uma máquina remota atrás de uma URL. Servidores locais costumam atender um cliente. Servidores remotos costumam atender muitos.
Um desenho simples:
Host (seu app de IA)
├── Cliente A ── stdio ──> servidor de arquivos (processo local)
├── Cliente B ── stdio ──> servidor de banco (processo local)
└── Cliente C ── HTTPS ──> servidor de chamados (remoto)Cada seta transporta mensagens JSON-RPC 2.0. O protocolo tem duas camadas. A camada de dados define as mensagens e o que elas significam. A camada de transporte define como as mensagens se movem.
As primitivas definem o que um servidor pode oferecer. A especificação nomeia três recursos do lado do servidor.
Tools (ferramentas) são funções que o modelo pode chamar. Uma ferramenta tem nome, descrição, um esquema de entrada em JSON Schema e um handler no servidor. Listar ferramentas usa tools/list. Executar uma usa tools/call. É nas ferramentas que as ações acontecem: escrever um arquivo, enviar uma requisição, rodar uma consulta.
Resources (recursos) são dados que o aplicativo pode ler por URI. Um recurso pode ser um arquivo, uma linha de banco ou uma resposta de API. Recursos são contexto. Ler um recurso não executa ação, e o host decide como colocar esse conteúdo diante do modelo.
Prompts são modelos de mensagem reutilizáveis que o servidor publica, muitas vezes com argumentos. O usuário escolhe um prompt como escolhe um comando, e o host preenche e envia ao modelo.
Os clientes também têm recursos próprios. Elicitation permite que um servidor peça ao usuário mais informações durante uma operação, como uma confirmação ou um valor que falta. Dois recursos antigos do lado do cliente, sampling e logging, estão marcados como obsoletos na revisão 2026-07-28. Sampling permitia que um servidor pedisse uma completação ao modelo do host. A visão geral da arquitetura diz que novas implementações devem integrar diretamente com as APIs dos provedores de modelo, e que o log deve ir para stderr no stdio ou usar OpenTelemetry.
Toda primitiva segue um padrão: um método */list para descoberta, um */get ou */read para leitura e um método de chamada quando a primitiva é uma ação. As listas podem mudar em tempo de execução. Um cliente que abre uma assinatura pode receber notificações de mudança, então atualiza sem ficar consultando.
Transporte é o caminho por onde as mensagens viajam. A visão geral da arquitetura cita dois.
stdio inicia o servidor como processo filho. O host escreve mensagens JSON-RPC na entrada padrão do servidor e lê as respostas na saída padrão. Não há porta de rede. É o transporte usual para servidores locais, e é o que você usa no laboratório. A regra mais importante: no stdio, a saída padrão pertence ao protocolo. Um print perdido na stdout corrompe o fluxo. Diagnósticos vão para stderr.
Streamable HTTP roda o servidor atrás de um endpoint HTTP. O cliente envia mensagens com HTTP POST, e o servidor pode devolver respostas ou notificações em streaming usando Server-Sent Events. É o transporte para servidores remotos. Como ele fica exposto na rede, traz os problemas comuns de HTTP: autenticação, TLS, verificação de origem e limites de taxa. A visão geral da arquitetura recomenda OAuth para obter tokens.
A camada de dados é a mesma nos dois. Uma chamada de ferramenta é igual, passe ela por um pipe ou por um socket.
Esta é a sequência para um host que se conecta a um servidor local. As mensagens exatas dependem da revisão do protocolo, então confira a especificação antes de construir algo sobre ela.
server/discover, que todo servidor precisa implementar. Chamá-la é opcional, porque cada requisição traz o que o servidor precisa. O servidor responde com as versões de protocolo que suporta, suas capacidades e sua identidade. Na revisão 2026-07-28, toda requisição leva a versão do protocolo e as capacidades do cliente num campo _meta. O protocolo é sem estado: cada requisição traz o que o servidor precisa para processá-la, então o servidor não depende do que aconteceu antes na conexão.tools/list, resources/list e prompts/list para as funcionalidades que o servidor declarou.tools/call. O servidor executa o handler e devolve um resultado com um array content, que pode trazer texto, imagens ou recursos embutidos. Uma chamada que falha devolve um resultado de erro que o modelo consegue ler.subscriptions/listen recebe uma mensagem notifications/tools/list_changed e pode pedir a lista de novo.O host fica entre os passos 4 e 5. É o componente que pede sua aprovação, se pedir. Esse ponto volta na seção de segurança.
O próprio MCP não impõe segurança. A especificação diz isso na seção de confiança e segurança, e lista os princípios que quem implementa precisa aplicar. Leia a lista como um checklist para a sua configuração.
Usuários precisam consentir explicitamente com os acessos e operações que um servidor realiza, e entendê-los. Hosts precisam obter consentimento explícito antes de expor dados do usuário a um servidor e antes de invocar qualquer ferramenta. A especificação também diz que as descrições das ferramentas, incluindo as anotações, não são confiáveis, a menos que venham de um servidor em que você confia. Um servidor pode dizer que uma ferramenta é somente leitura. Isso é uma afirmação em uma string, e um servidor com bug ou malicioso pode torná-la falsa.
Na prática, são quatro hábitos.
Trate um servidor como código que você executa. Um servidor stdio é um programa na sua máquina, com as permissões da sua conta de usuário. Instalar um é como instalar qualquer pacote. Leia o código-fonte ou pelo menos o README, veja quem publica e fixe a versão que você usa. Os servidores de referência do repositório oficial são um bom ponto de partida, mas leia o que cada um faz antes de ativá-lo.
Limite o acesso. Dê ao servidor só as pastas, contas e escopos de que ele precisa. O servidor de sistema de arquivos do laboratório recebe um diretório permitido como argumento, e tudo fora dele é recusado. Servidores remotos devem receber os escopos OAuth mais restritos disponíveis e tokens que você possa revogar.
Exija aprovação para ações. Ferramentas de leitura e ferramentas que escrevem, apagam, enviam ou gastam são categorias diferentes. Configure o host para perguntar antes de qualquer ferramenta que altere estado, e leia os argumentos antes de aprovar.
Observe o que volta. Resultados de ferramentas e conteúdos de recursos são dados. Podem conter texto que parece instrução para o modelo, copiado de uma página web ou de um arquivo. O host não deve tratar esse texto como ordem, e você também não. Essa é a raiz da injeção de prompt por meio de ferramentas, que terá um artigo próprio.
Este laboratório usa o servidor de referência de sistema de arquivos do repositório oficial modelcontextprotocol/servers e o MCP Inspector oficial. Você não precisa de modelo, chave de API nem conta paga. Precisa do Node.js. O Inspector exige Node 22.19.0 ou mais novo, então use uma versão LTS atual. Você vai criar uma pasta, iniciar o servidor com essa pasta como único diretório permitido e verificar o que ele deixa fazer.
Rode estes comandos no terminal onde quer fazer o laboratório. No Git Bash, Linux ou macOS:
mkdir mcp-sandbox && echo 'hello from the sandbox' > mcp-sandbox/note.txtNo PowerShell, o mesmo resultado vem de:
New-Item -ItemType Directory mcp-sandbox | Out-Null
Set-Content -Path mcp-sandbox\note.txt -Value 'hello from the sandbox'Inicie o Inspector com o servidor como alvo:
npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-filesystem ./mcp-sandboxO Inspector imprime uma URL local com um token válido para esta execução, e a abre no navegador. Deixe o terminal aberto, porque o servidor roda como processo filho do Inspector enquanto você usar. A primeira execução pode demorar porque o npx baixa os pacotes. Se a conexão falhar enquanto os pacotes ainda estão sendo baixados, espere um minuto e tente de novo. No modo CLI, --connect-timeout aumenta o limite, e os comandos abaixo o usam.
Na página web, clique em Connect. Depois abra a aba que lista as ferramentas do servidor e execute a ação de listar. Os rótulos mudam entre versões, então procure a aba e o botão que mostram as ferramentas. Você deve ver as ferramentas de sistema de arquivos. Na versão que testei, o servidor de referência expôs dezesseis ferramentas, entre elas list_directory, read_text_file, write_file e list_allowed_directories. read_file continua existindo e aparece como obsoleta em favor de read_text_file.
Execute list_allowed_directories primeiro. Ele mostra o que o servidor vai aceitar. O resultado traz um caminho só, a localização absoluta de mcp-sandbox. Nada além disso é alcançável.
Selecione list_directory e passe . como caminho, que significa o próprio diretório permitido. O resultado deve listar uma entrada: [FILE] note.txt.
Selecione read_text_file e passe note.txt como caminho. O resultado deve conter o texto que você escreveu, hello from the sandbox.
Repare no caminho. É note.txt, não ./mcp-sandbox/note.txt. O servidor resolve caminhos relativos a partir do diretório permitido, e não da pasta onde você abriu o Inspector. Eu cometi esse erro na primeira tentativa. O servidor devolveu um erro de "arquivo não encontrado" para um caminho que ele tinha resolvido como mcp-sandbox\mcp-sandbox\note.txt. A mensagem de erro mostrou qual caminho o servidor realmente usou, e por isso vale ler o texto do erro com atenção.
Crie um arquivo na pasta pai, um nível acima de mcp-sandbox:
echo 'this file is outside the sandbox' > outside.txtDe volta ao Inspector, chame read_text_file com o caminho ../outside.txt. Espere um resultado de erro, não o conteúdo do arquivo. Na minha máquina, o servidor devolveu este texto, com o caminho encurtado:
Access denied - path outside allowed directories: ...\mcplab\outside.txt not in ...\mcplab\mcp-sandboxDepois tente um caminho absoluto para o mesmo arquivo. O resultado deve ser a mesma recusa. A verificação roda dentro do servidor, sobre o caminho já resolvido, então a requisição falha não importa como você escreva o caminho.
É isso que o escopo significa na prática. O servidor é código rodando na sua máquina com as permissões do seu usuário, e mesmo assim não consegue ler a pasta pai, porque foi iniciado com um diretório permitido e aplica essa lista. Teste mais caminhos se quiser, como .. sozinho ou uma pasta que não existe, e compare os textos de erro.
Rodei as mesmas chamadas pelo modo CLI do Inspector, que envia as mesmas mensagens JSON-RPC do cliente web:
npx @modelcontextprotocol/inspector --cli --connect-timeout 120000 npx -y @modelcontextprotocol/server-filesystem ./mcp-sandbox --method tools/call --tool-name read_text_file --tool-arg path=note.txtA resposta voltou como JSON, e o conteúdo de texto foi hello from the sandbox seguido de uma quebra de linha. O mesmo comando com --tool-name list_allowed_directories mostrou o único caminho permitido. A chamada ../outside.txt devolveu a recusa mostrada acima. As versões dos pacotes no dia da execução foram @modelcontextprotocol/inspector 2.14.0 e @modelcontextprotocol/server-filesystem 2.2.0. O servidor imprimiu Secure MCP Filesystem Server running on stdio no stderr, que é a regra do stdio em ação. A saída padrão ficou reservada para mensagens do protocolo.
Rodei isso no Windows 11 com Git Bash e Node 24, e não usei a página web nessas execuções. Suas versões e caminhos serão diferentes, e a lista de ferramentas pode mudar entre lançamentos.
Tratar o MCP como um recurso do modelo. O MCP é um protocolo entre host e servidor. O modelo vê só o que o host repassa. O mesmo servidor pode se comportar de forma diferente em dois hosts, se um deles mostra melhor as descrições das ferramentas ou pede aprovação em outro ponto.
Confundir um servidor publicado com um servidor auditado. Instalar um servidor roda o código dele. Um pacote em um registro público não diz nada sobre segurança.
Dar acesso de escrita por padrão. Comece somente leitura. Adicione escopos de escrita só quando uma tarefa precisar.
Imprimir na stdout em um servidor stdio. Logs e prints de depuração escritos na stdout quebram o protocolo. Use stderr.
Confiar nas anotações das ferramentas. Uma ferramenta marcada como somente leitura ainda executa o código que o servidor contém.
Construir a partir de um resumo da especificação. As revisões mudam nomes de métodos e itens obsoletos. Confira a revisão que o seu SDK implementa, e leia a especificação para os nomes exatos dos campos antes de escrever código.
Esperar que o Inspector faça auditoria. O Inspector mostra o que o servidor devolve ao cliente. É uma visão de depuração, não uma revisão de segurança.
Leia primeiro a visão geral da arquitetura, depois as páginas de conceitos de servidor e de cliente. Elas explicam as primitivas com mais exemplos. Depois, leia as seções de protocolo base e de segurança da especificação, pois elas definem as regras que todo servidor e todo host precisa seguir.
Abra o código-fonte do servidor de referência de sistema de arquivos. É curto e mostra como um handler verifica caminhos e devolve erros. Depois escreva um servidor pequeno seu, com uma ferramenta que devolve uma string fixa, usando um SDK oficial, e inspecione-o com o Inspector antes de adicionar qualquer coisa que toque nos seus arquivos.
Mantenha a pasta do laboratório pequena e descartável, e apague-a quando terminar. O próximo artigo desta trilha, o que é injeção de prompt em aplicações com LLM, trata do ataque que os resultados das ferramentas tornam possível. Para o contexto que este artigo supõe, comece por o que são agentes de IA e uso de ferramentas.
Agentes de IA para segurança
Como funciona o uso de ferramentas: o modelo devolve uma chamada estruturada, o programa executa a ferramenta e regras de aprovação decidem o que roda.