O que é um servidor MCP? Tools, resources e prompts explicados | We.Inc
Um servidor MCP é um programa que oferece tools, resources e prompts a aplicações de IA pelo Model Context Protocol. Veja as mensagens JSON reais, passo a passo.
O que é um servidor MCP?
Um servidor MCP é um programa que dá às aplicações de IA algo com que trabalhar pelo Model Context Protocol: tools que elas podem chamar, resources que podem ler e prompts que os usuários podem escolher. A aplicação se conecta por um cliente MCP, e os dois lados trocam mensagens JSON-RPC 2.0 via stdio, localmente, ou via Streamable HTTP, remotamente.
As três coisas que um servidor pode oferecer
Primitiva
O que é
Quem decide usar
Métodos principais
Tools
Funções que executam uma ação, com um JSON Schema para a entrada
O modelo
tools/list, tools/call
Resources
Dados somente leitura identificados por uma URI, como um arquivo ou um schema
A aplicação
resources/list, resources/read
Prompts
Modelos de instrução reutilizáveis com argumentos
O usuário
prompts/list, prompts/get
Avance por uma troca real abaixo. Cada passo mostra o JSON que um cliente envia e o que o servidor responde, usando os formatos de mensagem da especificação atual (versão 2026-07-28). Ler as mensagens cruas é o jeito mais rápido de parar de ver um servidor como mágica.
Escolha um passo: descoberta, listagem de tools, chamada de uma tool ou recebimento de uma notificação de mudança.
Leia a requisição à esquerda e a resposta à direita.
Confira a nota abaixo do par para ver o campo que mais importa naquele passo.
Copie qualquer mensagem para comparar com o que o seu próprio servidor ou cliente envia.
Dê às tools nomes com um prefixo claro, como weather_current em vez de get. Um host pode carregar tools de muitos servidores ao mesmo tempo, e nomes vagos entram em conflito.
Escreva a descrição de cada tool para o modelo, não para uma pessoa passando os olhos por uma lista. Diga o que a tool faz e quando ela deve ser escolhida.
Exponha contexto somente leitura como resources em vez de tools. Resources deixam a aplicação decidir o que incluir, o que evita que o modelo busque dados de que não precisa.
Trate como arriscada toda tool que altera algo. O protocolo deixa a aprovação para o host, então projete tools que sejam seguras de confirmar uma chamada por vez.
Perguntas frequentes
Um servidor MCP é a mesma coisa que uma API?
Geralmente ele encapsula uma. Um servidor típico chama uma API ou um banco de dados existente e descreve essas operações de forma padronizada, para que qualquer aplicação compatível com MCP consiga descobri-las e chamá-las sem código de integração personalizado.
Um servidor MCP roda no meu computador ou na nuvem?
Nos dois. Um servidor local é iniciado pela aplicação e se comunica pela entrada e saída padrão. Um servidor remoto roda em outro lugar e é acessado via Streamable HTTP, onde pode atender muitos clientes.
Um servidor MCP contém um modelo de linguagem?
Não. O servidor só oferece tools, resources e prompts. A aplicação host é dona do modelo e decide o que enviar a ele. A especificação marca o sampling solicitado pelo servidor como obsoleto a partir da versão 2026-07-28.
O que mudou na versão 2026-07-28 do protocolo?
O protocolo passou a ser stateless: toda requisição leva a versão do protocolo e as capabilities no campo _meta, e os servidores respondem a uma requisição server/discover obrigatória. As notificações de mudança agora são opcionais, por meio de um stream subscriptions/listen.
Quem aprova uma chamada de tool?
O host. A documentação do protocolo sugere diálogos de aprovação, configurações de permissão e registros de atividade, mas aplicá-los é tarefa da aplicação, então um servidor nunca deve supor que uma pessoa conferiu a chamada.
Host, cliente e servidor
Três papéis aparecem em toda configuração. O host é a aplicação de IA que a pessoa usa. Para cada servidor a que se conecta, o host cria um cliente, e cada cliente mantém uma conexão dedicada com exatamente um servidor.
Então um host ligado a um servidor de arquivos e a um servidor de banco de dados mantém dois clientes. O servidor é simplesmente o programa que responde, onde quer que ele rode.
Duas camadas: dados e transporte
A camada de dados define as mensagens: requisições, respostas e notificações JSON-RPC 2.0 para descoberta, tools, resources e prompts. A camada de transporte leva essas mensagens e cuida do estabelecimento da conexão e da autorização.
Existem dois transportes padrão. Stdio passa as mensagens pela entrada e saída padrão entre processos na mesma máquina. Streamable HTTP usa HTTP POST do cliente para o servidor, com Server-Sent Events opcionais para streaming, e aceita bearer tokens, chaves de API e OAuth.
O que o cliente pode oferecer de volta
Os servidores também podem pedir coisas ao cliente. A elicitation permite que um servidor peça mais informações ou uma confirmação ao usuário pelo método elicitation/create.
O sampling, em que um servidor pede ao host uma resposta do modelo, e o logging no nível do protocolo estão obsoletos a partir da versão 2026-07-28. Servidores novos devem registrar logs em stderr no stdio ou usar OpenTelemetry.
Stdio ou Streamable HTTP?
Como escolher um transporte
Stdio
Streamable HTTP
Onde o servidor roda
Na mesma máquina, iniciado pelo host
Em qualquer lugar acessível pela rede
Como as mensagens trafegam
Streams de entrada e saída padrão
HTTP POST, com Server-Sent Events opcionais
Clientes típicos por servidor
Um
Muitos
Autenticação
Não é necessária, é um processo local
Bearer tokens, chaves de API, cabeçalhos personalizados; OAuth recomendado
Onde registrar logs
stderr (o stdout leva as mensagens do protocolo)
Os logs normais do seu servidor
Como é um resource template
Um resource template com um parâmetro na URI
Os clientes encontram templates com resources/templates/list, preenchem as chaves e leem o resultado com resources/read.
1. Descoberta
server/discover é opcional para o cliente, mas todo servidor precisa responder a ele. O objeto capabilities diz quais primitivas existem; listChanged significa que o servidor pode notificar sobre mudanças nas tools.
2. Listar tools
Cada tool tem um name, uma description e um inputSchema escrito em JSON Schema. O host passa isso ao modelo para que ele saiba o que pode chamar.
3. Chamar uma tool
O nome precisa corresponder exatamente à tool listada e os argumentos precisam se encaixar no inputSchema dela. Os resultados voltam como um array content, aqui com um único item de texto.
4. Notificação de mudança
Notificações não têm id, então ninguém responde a elas. O cliente só recebe esta porque abriu um stream subscriptions/listen pedindo toolsListChanged.