Why the Model Context Protocol exists, what it standardizes, and the two building blocks — resources and tools — that every MCP server is made of.
Quando construí um sistema de automação de suporte para triar tickets recebidos usando um modelo de IA, deparei imediatamente com um problema de fiação. A IA precisava de três coisas para fazer seu trabalho: ler de uma base de conhecimento de artigos, puxar o histórico recente de tickets e repassar decisões de roteamento ao backend do sistema de tickets. Cada conexão exigia seu próprio schema personalizado. A base de conhecimento usava um formato de consulta; o armazenamento de tickets usava outro; a ação de roteamento esperava uma estrutura de payload completamente diferente. Eu estava construindo e mantendo três camadas de integração separadas antes que a IA pudesse fazer qualquer coisa útil.
Pense nisso como ter que soldar um novo conector toda vez que você quer ligar um novo dispositivo na parede. Cada dispositivo funciona, mas cada conexão é feita sob medida — nenhum dispositivo pode usar o conector de outro.
Essa dor escala mal. Cada nova capacidade significa um novo protocolo personalizado. Cada nova aplicação de IA que quiser usar minhas fontes de dados precisa aprender cada protocolo do zero. O que eu realmente precisava era de uma interface padrão que tanto a IA quanto minhas fontes de dados pudessem falar.
É isso que o MCP é: o Model Context Protocol. Ele fornece um único padrão aberto que aplicações de IA usam para se conectar a fontes de dados e endpoints de ação, de modo que um host como o Claude possa falar com qualquer servidor MCP sem precisar saber o que está por trás dele.
Insight principal: O MCP não substitui suas APIs ou bancos de dados. Ele coloca uma superfície padrão na frente deles — a mesma superfície, independentemente do que esteja por trás dela.
Antes do MCP, o que você teria que construir para dar a um modelo de IA acesso à sua base de conhecimento e ao sistema de tickets? O que o MCP substitui nesse quadro?
Reserve um momento para pensar nisso antes de continuar a leitura. Você teria precisado de um schema de função personalizado para a base de conhecimento, um schema separado para o armazenamento de tickets e um terceiro para a API de roteamento — além de código de cola para conectar cada um ao modelo. O MCP substitui todo esse trabalho por integração com um único servidor que fala um protocolo para qualquer host compatível.
Pense no MCP como um adaptador universal para integrações de IA. Antes do USB-C, cada dispositivo tinha seu próprio conector de carregamento — telefones, tablets e laptops usavam conectores diferentes. O USB-C substituiu tudo isso com uma porta padrão. O MCP faz o mesmo para ferramentas de IA: um protocolo, qualquer fonte de dados ou endpoint de ação.
Quando um host de IA se conecta a um servidor MCP, toda conversa segue o mesmo formato. O host pergunta quais recursos o servidor expõe; o servidor os descreve com um schema padrão. O host pergunta quais ferramentas estão disponíveis; o servidor descreve essas também. O host então busca um recurso ou chama uma ferramenta usando o mesmo protocolo, independentemente do que esteja por trás do servidor.
Essa padronização foi o que tornou possível estender o sistema de automação de suporte posteriormente. Adicionar uma nova fonte de dados — uma lista de agentes ativos, um histórico de escalonamentos — significava escrever uma nova definição de recurso no servidor existente, não construir uma nova integração do zero.
O que isso desbloqueia: Como o MCP é um protocolo aberto, o mesmo servidor funciona com o Claude, com outros hosts compatíveis com MCP e com qualquer host futuro que implemente a especificação. Construa a integração uma vez; qualquer host compatível pode usá-la.
Todo servidor MCP é construído a partir de dois primitivos: recursos e ferramentas. Compreender a distinção entre eles é o conceito mais importante neste percurso.
Recursos são somente leitura. Pense em um recurso como uma prateleira em uma biblioteca. A IA pode se aproximar e pegar qualquer livro que quiser — navegar pelos títulos, ler os conteúdos — mas não pode reorganizá-los ou escrever neles. Nada na prateleira muda como resultado da leitura. No sistema de automação de suporte, os artigos da base de conhecimento e o histórico recente de tickets eram ambos recursos: a IA precisava lê-los para classificar um ticket, mas lê-los não tinha efeitos colaterais.
Ferramentas acionam ações. Pense em uma ferramenta como uma tomada de energia. No momento em que você conecta algo, a corrente flui — algo acontece no mundo real. Rotear um ticket o atribui a uma fila e notifica um agente. Escalonar um ticket aciona um humano. Ambas as operações alteram estado, e essa mudança não é revertida por qualquer outra coisa que a IA possa fazer. No sistema de automação de suporte, classify_ticket, route_ticket e escalate_ticket eram todas ferramentas porque alteravam estado real do mundo.
A regra de decisão: Se a operação retorna dados sem alterar nada, torne-a um recurso. Se ela muda estado no mundo real, torne-a uma ferramenta. Esse limite é o que permite que hosts e auditorias de segurança saibam quais operações são seguras de repetir e quais confirmam mudanças.
Antes de continuar: no exemplo de automação de suporte, por que o histórico de tickets foi exposto como um recurso e não como uma ferramenta?
Reserve um momento para raciocinar sobre isso. A resposta está na definição: ler o histórico de tickets não altera os tickets. A IA pode chamar esse recurso dez vezes seguidas e o estado do sistema é idêntico cada vez. Essa previsibilidade — sem efeitos colaterais — é exatamente o que o torna um recurso.
O restante deste percurso constrói um exemplo em execução, um servidor MCP de triagem de suporte, uma camada por vez. O Módulo 02 cria o esqueleto do servidor. O Módulo 03 adiciona dois recursos: artigos da base de conhecimento e histórico de tickets. O Módulo 04 adiciona três ferramentas: classify_ticket, route_ticket e escalate_ticket. O Módulo 05 integra tudo em um servidor completo e funcionando.
Antes de construir qualquer handler, ajuda ver a estrutura de que todo servidor MCP parte. Este esqueleto mostra as importações, a instanciação do servidor e a fiação do transport — nenhum handler de recurso ou ferramenta ainda. Esses vêm nos módulos que seguem.
Duas coisas a notar neste esqueleto. Primeiro, cada handler usa objetos de schema tipados — ListResourcesRequestSchema, CallToolRequestSchema — não literais de string como 'resources/list'. A forma tipada é a superfície de API correta para o SDK do MCP; qualquer exemplo que use registro baseado em string está usando um padrão descontinuado. Segundo, o servidor não faz nada até que server.connect(transport) seja chamado. O transport é o cabo de força que conecta o servidor ao host — sem ele, o servidor não consegue enviar ou receber nenhuma mensagem.
Por que stdio? StdioServerTransport é o transport padrão para servidores MCP locais: o host gera o servidor como um processo filho e se comunica via stdin e stdout. Outros transports (HTTP, SSE) existem para implantações em rede, mas stdio é o ponto de partida correto para um novo servidor.
Application-level questions about MCP concepts and the resource/tool distinction.
1. In the support-automation example, why was ticket history exposed as a resource rather than a tool?
2. Which of the following should be exposed as a TOOL rather than a resource?
3. Which argument should be passed to `server.setRequestHandler()` when registering a handler for listing available MCP resources?
4. The "power outlet" analogy for tools highlights which property?
5. An order-tracking server needs to expose three capabilities: (1) look up an order by ID, (2) list recent orders for a customer, and (3) cancel an order. How should these be classified?
6. What role does `StdioServerTransport` play in an MCP server?
7. Before `await server.connect(transport)` is called, what is true of the MCP server?
Aplique a distinção recurso/ferramenta a um novo domínio — nenhum código é necessário.
Uma empresa de e-commerce está adicionando suporte a MCP para que um assistente de IA ajude clientes a rastrear pedidos e a equipe de suporte gerencie re-entregas e cancelamentos. O sistema suporta cinco operações:
Para cada operação: classifique como recurso ou ferramenta, dê um nome seguindo as convenções MCP (URI para recursos, ex. orders://detail/{orderId}; verbo snake_case para ferramentas, ex. cancel_order), e escreva uma frase justificando sua escolha.
Dica: Para cada operação, pergunte — isso muda dados armazenados, ou apenas lê dados existentes sem efeitos colaterais? Se a IA pode chamar isso repetidamente sem consequências, é um recurso.
Solução
<CodeExample title="Solução" language="text"> Recursos (somente leitura, sem efeitos colaterais): - orders://detail/{orderId}: ler um registro não o modifica. - orders://recent/{customerId}: recuperar histórico não o altera. - orders://shipping-status/{orderId}: buscar status não tem efeitos colaterais.Ferramentas (confirmam mudanças de estado):
A regra de decisão: qualquer coisa que a IA pode chamar repetidamente sem consequências é um recurso. Qualquer coisa que confirme uma mudança é uma ferramenta.