Resources e prompts no MCP: o que há além das ferramentas

Resources e prompts no MCP: o que há além das ferramentas

No Model Context Protocol (MCP), tools são ações que o modelo decide chamar, resources são dados que a aplicação expõe para leitura e prompts são modelos de instrução que a pessoa escolhe usar. A diferença importa porque quem controla cada peça muda o risco: um resource entrega contexto sem executar nada, enquanto uma tool pode alterar sistemas. Quando o objetivo é só dar informação ao modelo, expor um recurso costuma ser mais seguro do que criar uma ferramenta.

Principais pontos

• Tools, resources e prompts têm donos diferentes: o modelo aciona tools, a aplicação decide como usar resources e a pessoa escolhe prompts.
• Resource é leitura identificada por um endereço (URI). Não executa ação e, por isso, tem superfície de risco menor do que uma tool.
• Se a necessidade é consultar informação estável (política, catálogo, manual), comece por um recurso. Reserve tools para o que precisa escrever, enviar ou calcular sob demanda.
• Prompts do MCP padronizam instruções recorrentes da equipe, com argumentos, em vez de cada pessoa improvisar o seu texto.
• Recurso não elimina riscos: conteúdo lido pode conter instruções maliciosas e dados pessoais continuam sujeitos à LGPD.

Qual é a diferença entre tools, resources e prompts no MCP?

A documentação oficial do Model Context Protocol descreve o MCP como um padrão aberto para conectar aplicações de IA a sistemas externos. Dentro dele, um servidor pode oferecer três tipos de capacidade, e a forma mais útil de separá-las é perguntar quem as controla.

• Tools: controladas pelo modelo. O modelo enxerga a lista de ferramentas, decide qual chamar e com quais argumentos. Exemplos: criar um chamado, enviar uma mensagem, consultar um pedido por filtro.
• Resources: controlados pela aplicação. O servidor expõe dados identificados por URI, e o cliente (a aplicação que hospeda o modelo) decide quais incluir no contexto. Exemplos: um documento, um registro, um arquivo de configuração.
• Prompts: controlados pela pessoa. São modelos de mensagem reutilizáveis, com argumentos, que o usuário seleciona de forma explícita.

Essa divisão é o que torna a escolha de projeto uma decisão de governança, não só técnica. Quanto mais autonomia o modelo tem sobre uma capacidade, mais limites, logs e aprovações ela exige. Se você ainda está montando o ambiente, o texto sobre configurar MCP no Claude Code explica em que escopo cada servidor deve viver.

O que é um resource, na prática?

Um resource é um conteúdo que o servidor MCP disponibiliza para leitura, com um identificador no formato de URI. Pode ser algo fixo, como o manual de atendimento da empresa, ou algo parametrizado por um modelo de URI, como o registro de um produto a partir do seu código.

Três características definem o uso:

• É leitura. O protocolo de recursos serve para obter conteúdo, não para provocar efeitos em outros sistemas.
• Quem decide incluir no contexto é a aplicação ou a pessoa, e não necessariamente o modelo por conta própria. Isso depende do cliente que você usa, então vale conferir na documentação da versão em uso como ele trata recursos. Em clientes como o Claude Code, por exemplo, recursos e prompts de servidores MCP costumam aparecer para a pessoa escolher, mas o comportamento exato pode variar entre versões.
• O conteúdo tem tipo e descrição. Isso ajuda a aplicação a mostrar o que existe e a filtrar o que faz sentido para cada tarefa.

Na prática, pense em recurso como uma estante com etiquetas. A pessoa ou o aplicativo pega o que precisa daquela prateleira, e o modelo trabalha com o material entregue. Nada na estante sai andando e mexe no sistema.

Quando expor dados como recurso é mais seguro do que criar uma ferramenta?

Principalmente quando a necessidade é de contexto e não de ação. Muitos servidores MCP nascem com uma ferramenta genérica do tipo "buscar_qualquer_coisa" ou "executar_consulta" só para o modelo conseguir ler informação. Esse desenho dá mais poder do que o problema pede.

Os motivos para preferir recurso:

• Menor superfície de ação. Um recurso não tem efeito colateral por definição de uso, então não há risco de duplicar envio, apagar registro ou gastar crédito por engano.
• Escopo explícito. Você publica exatamente os documentos e registros que a tarefa precisa, em vez de dar uma ferramenta que consulta tudo e depende de o modelo se comportar.
• Revisão mais simples. É mais fácil auditar uma lista de URIs expostas do que o comportamento de uma ferramenta com muitos parâmetros livres. O guia para auditar um servidor MCP antes de instalar detalha esse tipo de verificação.
• Controle de quem decide. Como a aplicação ou a pessoa seleciona o que entra no contexto, existe um ponto humano ou determinístico antes de o modelo ver o dado.

Cenário ilustrativo: uma empresa de serviços quer que o assistente interno responda dúvidas sobre política de reembolso e prazos de atendimento. A primeira ideia é criar uma ferramenta "consultar_base" com busca livre no drive inteiro. A alternativa mais segura é publicar como recursos apenas dois ou três documentos revisados (política de reembolso, tabela de prazos, roteiro de escalonamento). O assistente responde com base neles, e nenhum outro arquivo fica ao alcance. Se amanhã surgir a necessidade de abrir um chamado, aí sim entra uma ferramenta pequena, com aprovação humana, separada da leitura.

A regra de bolso: se a pergunta que o modelo precisa responder é "o que diz a regra?", use recurso. Se a pergunta é "faça isto agora", você está falando de ferramenta.

Para que servem os prompts do MCP?

Prompts são modelos de instrução publicados pelo servidor, com nome, descrição e argumentos. A pessoa escolhe um deles, preenche os argumentos e o cliente monta a mensagem. É o MCP oferecendo fluxos de trabalho prontos, em vez de cada usuário digitar o próprio texto.

Bons usos:

• Padronizar tarefas repetidas, como "resumir este chamado no formato da equipe" ou "preparar resposta de reclamação com tom institucional".
• Combinar instrução e contexto. Um prompt pode já referenciar recursos, de modo que a pessoa só informa o argumento (por exemplo, o código do pedido).
• Reduzir variação entre pessoas. Quem escreve a instrução é quem entende o processo, e não cada atendente na hora.

Há uma ligação com outros recursos que a equipe talvez já use. Em ambientes de código, o equivalente conceitual são as skills no Claude Code: instruções reutilizáveis que carregam o método da equipe. Para atendimento, o texto sobre como escrever instruções para atendimento com IA ajuda a decidir o que entra no modelo de instrução.

Um cuidado: prompt não é controle de segurança. Uma instrução bem escrita orienta o comportamento, mas não impede uma ação que a ferramenta permita. Limites reais ficam em permissões, validação e aprovação, como descrito em guardrails para agentes de IA.

Guia de decisão: tool, resource ou prompt?

Use esta sequência de perguntas ao desenhar ou avaliar um servidor MCP.

• O modelo só precisa ler uma informação que já existe? Exponha como resource.
• A informação muda por consulta (por exemplo, o pedido de um cliente específico)? Use um modelo de URI com parâmetro restrito ou uma tool de leitura com filtros fechados, e registre cada acesso.
• A tarefa cria, altera, envia ou apaga algo? Use tool, com permissão mínima, validação de argumentos e aprovação humana para ações sensíveis.
• A dificuldade é que cada pessoa pede a mesma coisa de um jeito diferente? Crie um prompt com argumentos.
• O dado contém informação pessoal ou sigilosa? Antes de escolher o tipo, defina quem pode ver, por quanto tempo e o que fica em log.
• Está em dúvida entre dois tipos? Comece pelo menos poderoso (resource ou prompt) e promova para tool só quando houver necessidade comprovada.

Se a dúvida for mais ampla, sobre qual integração usar com sistemas como CRM, o texto sobre integrar IA ao CRM com API, webhooks ou MCP compara os caminhos.

Quais riscos continuam existindo com recursos?

Expor um recurso reduz o risco de ação, mas não o zera. Três pontos merecem atenção.

• Injeção de prompt por conteúdo. Se o recurso contém texto escrito por terceiros (e-mails, avaliações, mensagens de clientes), esse texto pode trazer instruções disfarçadas. A folha de referência da OWASP sobre prevenção de prompt injection trata o conteúdo recuperado como entrada não confiável, e essa é a postura correta aqui também. Recurso com texto de terceiros não deve acompanhar ferramentas de ação sem barreiras.
• Dados pessoais. Um recurso com nome, telefone ou histórico de compra continua sendo tratamento de dados sob a LGPD. Publique o mínimo necessário, mascare o que não for preciso e confirme com o responsável jurídico a base de tratamento. A ANPD é a referência oficial para orientações.
• Excesso de exposição. Um servidor que lista recursos demais volta a ser um acesso amplo, só que com outro nome. Revise a lista de URIs como revisaria uma permissão de acesso, seguindo o princípio de privilégio mínimo descrito na referência de autorização da OWASP.

Também vale lembrar que MCP e outros protocolos resolvem problemas diferentes. Se a dúvida é como agentes conversam entre si, veja a comparação entre A2A e MCP.

Como aplicar isso com o método mapear, limitar, pilotar e transferir

O método de trabalho do Juan Carlo para sistemas de IA se encaixa bem no desenho de um servidor MCP.

• Mapear: liste as perguntas e tarefas reais do processo e classifique cada uma como leitura, ação ou instrução recorrente. Essa lista vira o inventário de resources, tools e prompts.
• Limitar: publique somente os recursos necessários, com dados mínimos, e dê às tools permissões estreitas e aprovação humana nas ações sensíveis.
• Pilotar: rode um único fluxo real, com logs do que foi lido e do que foi acionado e uma métrica de sucesso combinada antes. Só depois decida expandir.
• Transferir: entregue a documentação da lista de recursos, dos prompts e das permissões, para que a equipe saiba revisar e manter. Ao final, a decisão é expandir, ajustar ou parar.

O resultado esperado é um servidor pequeno e explicável, em que cada capacidade tem um motivo e um responsável.

Perguntas frequentes

Resource do MCP é a mesma coisa que RAG? Não. RAG é uma técnica de recuperar trechos relevantes e entregá-los ao modelo, enquanto resource é um mecanismo do protocolo para expor conteúdo identificado por URI. Um servidor MCP pode usar recursos como parte de uma solução de recuperação, mas os dois conceitos não são equivalentes.

Posso usar só tools e ignorar resources e prompts? Pode, e muitos servidores fazem isso, mas você perde formas mais controladas de entregar contexto e de padronizar instruções. Além disso, é comum que leituras simples acabem implementadas como ferramentas amplas, com mais poder do que o necessário. Avaliar se cada leitura caberia como recurso é um bom exercício de revisão.

O modelo consegue ler qualquer recurso sozinho? Depende do cliente e da configuração. O protocolo coloca os recursos sob controle da aplicação, o que significa que ela decide como e quando incluí-los no contexto. Confira na documentação do cliente que você usa como isso funciona e teste antes de assumir um comportamento.

Prompt do MCP substitui a política de uso de IA da empresa? Não. O prompt padroniza uma tarefa, mas regras sobre que dados podem ser usados, por quem e com qual revisão pertencem à política interna. Elas devem ser definidas antes e refletidas nos limites técnicos do servidor.

Fontes

• Model Context Protocol: introdução
• OWASP: prevenção de prompt injection
• OWASP: guia de autorização
• Anthropic: Writing effective tools for agents