Conectar uma IA a um servidor MCP não significa simplesmente “dar acesso ao servidor”. O Model Context Protocol separa o que um servidor oferece em três primitivas centrais: tools, resources e prompts. Elas representam superfícies diferentes: funções executáveis, dados usados como contexto e templates de interação.
Essa distinção importa porque o risco de uma integração não depende apenas do nome do serviço conectado. Um servidor de calendário, por exemplo, pode disponibilizar um recurso para consultar compromissos, uma tool para criar eventos e um prompt que organiza um fluxo de planejamento. Saber que o servidor “acessa o calendário” ainda não explica o que a IA poderá ler, executar ou ser orientada a fazer.
A referência usada aqui é a especificação MCP 2026-07-28, publicada em 28 de julho de 2026 e vigente na data desta revisão. Essa versão manteve tools, resources e prompts como primitivas centrais do servidor, embora tenha alterado outras partes importantes do protocolo.
Tools, resources e prompts não são três nomes para a mesma permissão
A própria documentação do MCP associa um modelo de controle diferente a cada primitiva. Tools são projetadas para serem controladas pelo modelo; resources, pela aplicação; prompts, pelo usuário. Isso descreve quem normalmente decide quando aquela capacidade entra em uso, não quem possui a autorização final sobre os sistemas externos.
| Primitiva | O que o servidor oferece | Controle típico | Pergunta principal ao revisar |
|---|---|---|---|
| Tools | Funções executáveis que podem consultar sistemas, chamar APIs, calcular ou produzir efeitos externos | Modelo, sujeito aos controles do cliente | O que esta função consegue fazer e quais dados recebe? |
| Resources | Dados e conteúdos que podem ser recuperados como contexto, identificados por URI | Aplicação | Que informação pode ser lida e colocada no contexto da IA? |
| Prompts | Templates de mensagens e instruções definidos pelo servidor e personalizáveis por argumentos | Usuário | Que instrução estou escolhendo e que outros recursos ela incorpora? |
Essa classificação é mais útil do que dividir MCP simplesmente entre “leitura” e “escrita”. Uma tool pode apenas consultar uma base de dados, sem modificar nada. Ao mesmo tempo, outra tool pode enviar um e-mail, criar um evento ou alterar um arquivo. O fato de ambas serem tools indica que são operações invocáveis, não que possuem o mesmo nível de risco.
Tools são operações que a IA pode solicitar
Uma tool é uma interface executável descrita pelo servidor. Ela possui nome, descrição, um esquema de entrada e, opcionalmente, um esquema para a saída. O modelo pode descobrir as tools disponíveis e solicitar uma execução por meio de tools/call.
É aqui que geralmente aparecem as capacidades mais fáceis de reconhecer como “ações”: criar um compromisso, enviar uma mensagem, modificar um arquivo ou chamar uma API. Mas tools também podem executar operações sem efeito de escrita, como pesquisar voos, consultar dados ou realizar cálculos. A pergunta correta, portanto, não é apenas “este servidor possui tools?”, e sim quais operações cada tool implementa.
A especificação chama esse modelo de model-controlled: a IA pode descobrir e invocar tools automaticamente de acordo com o contexto e com o pedido do usuário. Isso não significa que o protocolo exija execução irrestrita. A própria especificação recomenda manter uma pessoa capaz de negar chamadas e orienta aplicações a deixar claras as tools expostas, sinalizar execuções e apresentar confirmações.
Para operações sensíveis, a recomendação técnica vai além de um simples botão de “conectar”. Clientes devem considerar confirmação do usuário, exibir os dados que serão enviados para a tool antes da chamada, validar resultados e registrar o uso para auditoria.
Isso cria uma distinção importante: a existência de uma tool no catálogo do servidor não equivale, por si só, a autorização incondicional para usá-la. O host ou cliente MCP ainda pode aplicar suas próprias políticas, permissões e confirmações.
Resources são dados disponibilizados como contexto
Resources representam informação que o servidor disponibiliza para leitura: conteúdo de arquivos, registros, esquemas de banco de dados, documentação ou informações específicas de uma aplicação. Cada recurso possui uma URI que o identifica.
Ao contrário das tools, os resources são descritos como application-driven. A aplicação hospedeira decide como incorporar esses dados. Ela pode oferecer um seletor manual, permitir busca e filtragem ou até incluir contexto automaticamente usando heurísticas ou seleção assistida por IA. O protocolo não obriga uma única interface de uso.
Isso também significa que “resource” não deve ser entendido como “dado que a IA sempre verá”. O servidor pode disponibilizar um catálogo de recursos, mas cabe ao cliente decidir como recuperá-los e quando colocá-los no contexto do modelo.
A superfície de exposição, porém, continua relevante. Um resource pode representar um documento interno, um calendário, informações de uma API ou outro conteúdo sensível. A especificação exige validação das URIs e recomenda controles de acesso e verificação de permissões para recursos protegidos.
Resources podem ainda usar templates de URI. Em vez de apresentar somente endereços fixos, um servidor pode oferecer modelos parametrizados para recuperar diferentes conjuntos de dados. A documentação atual também prevê recursos de texto e binários, além de metadados que ajudam o cliente a decidir como utilizá-los.
Na análise de uma conexão, portanto, resources respondem principalmente à pergunta: que informação esse servidor pode entregar ao cliente e potencialmente colocar diante do modelo?
Prompts são templates fornecidos pelo servidor
No MCP, prompts não são apenas a mensagem que o usuário digita na conversa. São templates estruturados publicados pelo próprio servidor e recuperáveis pelo cliente. Eles podem aceitar argumentos para personalizar um fluxo, como um template para revisão de código, planejamento ou elaboração de uma mensagem.
Aqui existe uma nuance importante. Os prompts são descritos como user-controlled porque a intenção é que o usuário escolha explicitamente quando utilizá-los. O conteúdo do template, porém, é definido pelo servidor. A especificação faz essa distinção de forma explícita.
Um prompt também não precisa funcionar de forma isolada. Ele pode conter texto, imagens e outros tipos de conteúdo, além de referenciar ou incorporar resources. Isso permite criar fluxos em que o template já reúne instruções e contexto disponibilizado pelo servidor.
Além disso, um prompt pode orientar o modelo a trabalhar com determinadas tools. Por isso, classificá-lo como “apenas texto” pode minimizar sua importância. O prompt não executa uma tool por si mesmo, mas pode estruturar a interação que levará o modelo a solicitar uma ação disponível.
A especificação atual também determina que implementações validem entradas e saídas de prompts para reduzir riscos como injeção de instruções e acesso não autorizado a recursos.
As três primitivas podem aparecer combinadas
Tools, resources e prompts são categorias distintas, mas não formam compartimentos fechados.
Uma tool pode retornar conteúdo estruturado, links para resources ou até resources incorporados. Da mesma forma, mensagens de um prompt podem carregar referências ou conteúdos de resources.
Imagine um servidor conectado a e-mail e calendário. Ele poderia oferecer um resource para recuperar os próximos compromissos, uma tool para criar um novo evento e um prompt chamado “organizar minha semana”, que estrutura as instruções e incorpora informações relevantes.
Nesse cenário, avaliar apenas a tool que cria eventos deixaria parte da superfície de exposição de fora. O resource determina quais informações podem ser recuperadas; o prompt pode influenciar como essas informações e ferramentas serão combinadas.
Por isso, uma revisão técnica útil começa pelo catálogo completo de capacidades, e só depois passa para as permissões concedidas.
O que o servidor oferece e o que você autoriza são questões diferentes
A especificação permite que os conjuntos de tools, resources e prompts disponíveis variem conforme a autorização apresentada na requisição. Em outras palavras, o servidor pode possuir uma capacidade sem necessariamente entregá-la a todo usuário ou a todo token de acesso.
A documentação de segurança do MCP também recomenda minimizar escopos. Permissões excessivamente amplas aumentam o impacto de um token comprometido, tornam auditorias menos claras e podem permitir acesso a operações sem relação com a necessidade inicial. A orientação atual propõe um modelo progressivo de menor privilégio, com elevação de escopo quando uma operação realmente exigir mais acesso.
Isso ajuda a separar duas etapas que frequentemente são confundidas:
Primeiro, inventarie a capacidade técnica. Descubra quais tools podem ser chamadas, quais resources podem ser lidos e quais prompts o servidor publica.
Depois, avalie a autorização. Verifique quais dessas capacidades estarão disponíveis com as credenciais concedidas, quais dados externos elas alcançam e quais ações exigem confirmação.
Uma tela de consentimento genérica pode dizer que um serviço terá acesso ao calendário. O catálogo MCP pode revelar que, tecnicamente, existem operações bem diferentes sob esse mesmo rótulo: pesquisar eventos, ler detalhes, criar compromissos ou executar outros fluxos. O nível de revisão deve acompanhar a operação real, não apenas o nome da integração.
Como analisar um servidor MCP antes de conectá-lo
Ao revisar uma integração, comece verificando se o cliente permite enxergar o que o servidor oferece. Para tools, procure nomes, descrições, parâmetros de entrada e finalidade de cada operação. A especificação orienta aplicações a tornar claras as tools disponibilizadas ao modelo.
Em seguida, identifique os resources. O ponto não é apenas contar quantos existem, mas entender o domínio dos dados: arquivos locais, documentos corporativos, banco de dados, mensagens, calendário ou outra fonte. Recursos sensíveis devem possuir controles de acesso próprios.
Também examine os prompts disponíveis. Como o conteúdo é definido pelo servidor, um template merece ser tratado como parte da integração e não como um simples atalho de interface. Veja o que ele instrui, que argumentos recebe e se incorpora resources.
Por fim, compare esse inventário com o que está sendo pedido na autorização. A documentação oficial recomenda autorização para servidores que lidem com dados específicos do usuário ou operações que dependam de consentimento e destaca a minimização de escopos como medida de segurança.
O resultado dessa análise deve permitir responder perguntas mais concretas do que “confio neste MCP?”: quais dados ele consegue fornecer, quais operações ele oferece, quais templates podem orientar a interação e qual parcela de tudo isso estou efetivamente autorizando?
Depois de entender o que o servidor pode expor, a próxima decisão é quanto desse acesso deve ser concedido. Para essa etapa, consulte também “Antes de conectar um agente de IA ao seu e-mail, calendário e navegador: o que revisar” e revise permissões, confirmações e alcance das credenciais antes de concluir a conexão.
