Entendendo o MCP: Ferramentas, Recursos e Prompts
O Model Context Protocol, ou MCP, é um protocolo aberto para conectar modelos de IA a ferramentas, dados e serviços externos.
Antes do MCP, cada integração entre um modelo e um sistema externo era um trabalho personalizado, conectado manualmente para um cliente e um backend de cada vez.
O MCP substitui essa conexão pontual por um contrato compartilhado, para que uma única implementação de servidor possa expor suas capacidades a qualquer cliente compatível com MCP sem reescrever a integração a cada vez.
Esse contrato é construído a partir de três primitivos, e entender para que serve cada um é o primeiro passo para projetar um bom servidor MCP.
Resumo
- Ideia Central: O MCP padroniza como um modelo de IA descobre e usa capacidades externas através de três primitivos: Ferramentas, Recursos e Prompts.
- Por que é Importante: Sem um protocolo compartilhado, cada integração modelo-sistema é personalizada, frágil e travada em um único cliente.
- Conceitos-Chave: Ferramentas (funções chamáveis), Recursos (dados legíveis, endereçados por URI), Prompts (modelos parametrizados reutilizáveis), design agnóstico ao cliente, descoberta.
- Quando Usar: Utilize o MCP quando uma capacidade precisar ser utilizável em mais de um cliente de IA, quando você desejar um contrato estável entre seus sistemas e qualquer modelo, ou quando estiver construindo um servidor destinado a durar mais que uma única integração.
- Limitações / Compromissos: O MCP adiciona uma camada de esquema e sobrecarga de protocolo em comparação com a conexão direta de uma chamada de função em um único aplicativo.
- Tópicos Relacionados: chamada de função, esquemas de ferramentas, URIs de recursos, modelos de prompt, seleção de transporte.
Fundamentos
Em sua essência, o MCP define um relacionamento cliente-servidor.
Um cliente MCP, como Claude Code, Claude Desktop, Cowork ou um aplicativo personalizado construído no Agent SDK, se conecta a um servidor MCP.
O servidor anuncia o que pode fazer, e o cliente (e o modelo por trás dele) decide quando e como usar essas capacidades.
O que o servidor anuncia se enquadra em exatamente três categorias.
Ferramentas são funções chamáveis.
Uma ferramenta tem um nome, uma descrição e um esquema que descreve suas entradas, e quando o modelo decide usá-la, o cliente envia uma chamada e o servidor retorna um resultado.
Isso é conceitualmente a mesma ideia que a chamada de função em uma API típica de LLM, apenas padronizada para que qualquer cliente MCP possa descobri-la e invocá-la da mesma maneira.
Recursos são dados legíveis, não ações.
Um recurso é qualquer coisa endereçável por um URI: um arquivo no disco, uma linha em um banco de dados, a resposta de uma API interna, um valor de configuração.
Em vez do modelo chamar uma função para buscar dados, o cliente pode ler um recurso diretamente, semelhante a como um navegador busca uma URL.
Prompts são modelos de prompt reutilizáveis e parametrizados.
Um modelo de prompt empacota instruções, talvez com placeholders para argumentos, para que vários clientes possam invocar o mesmo prompt bem testado, em vez de cada um improvisar sua própria formulação.
Pense em prompts como a maneira do servidor dizer "aqui está a maneira correta de pedir isso", compartilhada uma vez e reutilizada em todos os lugares.
Uma âncora mental simples: Ferramentas são verbos, Recursos são substantivos e Prompts são roteiros.
Mecânicas e Interações
A relação entre esses três primitivos fica mais clara quando se considera como um cliente realmente usa um servidor durante uma sessão.
Quando um cliente se conecta, ele pergunta ao servidor o que ele oferece, e o servidor responde com listas de suas ferramentas, recursos e prompts, cada um com metadados que o cliente pode apresentar ao modelo ou a um usuário.
Para ferramentas, esses metadados são um esquema: o nome da ferramenta, uma descrição em linguagem natural e uma definição estruturada de seus argumentos esperados.
O modelo lê essas descrições e esquemas para decidir, durante uma conversa, se chamar uma ferramenta específica ajudaria a responder à solicitação atual.
Para recursos, o cliente pode listar os URIs disponíveis e ler seus conteúdos, seja porque o modelo solicitou ou porque o aplicativo circundante escolheu anexar esse contexto diretamente.
Para prompts, o cliente (ou um usuário) seleciona um prompt nomeado, opcionalmente fornece argumentos e recebe de volta um conjunto completo de mensagens prontas para enviar ao modelo.
Um único servidor geralmente mistura os três.
Um servidor de documentação, por exemplo, pode expor uma ferramenta search_docs, um recurso docs://page/{id} para ler uma página individual e um prompt summarize_page que sempre pede ao modelo para resumir uma página da mesma maneira bem ajustada.
# Formato ilustrativo apenas - consulte as páginas "Definindo Ferramentas Chamáveis" e
# "Expondo Dados Legíveis como Recursos MCP" para o código completo do servidor.
server.tool("search_docs", handler=search_docs_handler)
server.resource("docs://page/{id}", handler=read_page_handler)
server.prompt("summarize_page", handler=summarize_prompt_handler)A distinção mecânica importante é quem inicia a troca e que tipo de resultado retorna.
Uma chamada de ferramenta é iniciada pelo modelo e retorna um resultado que se torna parte da conversa.
Uma leitura de recurso pode ser iniciada pelo modelo ou iniciada pelo cliente, e retorna dados, não um resultado computado.
Uma invocação de prompt é tipicamente iniciada pelo usuário ou cliente e retorna conteúdo de mensagem destinado a semear ou direcionar uma conversa, não dados brutos ou um efeito colateral.
Considerações Avançadas e Aplicações
A razão pela qual o MCP define três primitivos em vez de apenas "funções que o modelo pode chamar" é que a chamada de função comum cobre apenas o caso de Ferramentas, e o faz de uma maneira que está estritamente ligada a uma API e a um cliente.
Se você usou a chamada de função diretamente contra uma API de modelo, você já construiu algo como uma ferramenta MCP, apenas sem o formato de esquema padronizado, sem descoberta e sem portabilidade para outros clientes.
O MCP pega essa mesma ideia e adiciona um envelope de protocolo em torno dela, mais dois primitivos que a chamada de função sozinha não aborda bem: acesso a dados em massa ou estruturados (Recursos) e instruções compartilhadas e versionadas (Prompts).
Essa distinção importa mais assim que um servidor precisa atender a mais de um cliente.
Uma ferramenta implementada como uma função única dentro de um único aplicativo precisa ser reimplementada e pode sair de sincronia se um segundo aplicativo desejar a mesma capacidade.
Uma ferramenta MCP definida uma vez em um servidor está imediatamente disponível, com o mesmo esquema e comportamento, para qualquer cliente que se conecte a esse servidor, seja o Claude Code na máquina de um desenvolvedor ou um aplicativo personalizado do Agent SDK em produção.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Chamada de função comum | Simples, sem camada extra, mais rápido para prototipar | Ligado a um único cliente e integração de API | Um único aplicativo que nunca compartilhará a capacidade |
| Ferramenta MCP | Reutilizável em qualquer cliente MCP, esquema e descoberta padronizados | Requer execução ou conexão a um servidor, mais partes móveis | Capacidades que múltiplos clientes ou equipes precisam |
| Recurso MCP | Separação clara de "ler dados" de "tomar ação", cacheável | Não adequado para qualquer coisa que tenha efeitos colaterais | Arquivos, linhas de banco de dados, respostas de API que o modelo deve ler |
| Prompt MCP | Instruções consistentes e versionadas entre clientes | Outro artefato para projetar e manter | Fluxos de trabalho compartilhados onde a qualidade da redação importa |
Escolher o primitivo certo para uma determinada capacidade é em si uma decisão de design que vale a pena levar a sério.
Expor uma fonte de dados somente leitura como uma ferramenta em vez de um recurso funciona, mas oculta do cliente que a operação é segura para cache e não tem efeitos colaterais.
Inversamente, expor algo com efeitos colaterais, como enviar um e-mail, como um recurso seria enganoso, já que recursos são destinados a serem lidos, não executados.
Acertar essa classificação desde o início torna o comportamento de um servidor previsível para qualquer cliente que se conecte a ele posteriormente, incluindo clientes que você não construiu.
Conceitos Equivocados Comuns
- "Ferramentas MCP são apenas chamadas de função com etapas extras." A mecânica subjacente de chamada e resposta é semelhante, mas a camada de protocolo é o que torna uma ferramenta utilizável por qualquer cliente compatível, em vez de uma integração codificada manualmente.
- "Recursos e ferramentas são intercambiáveis se uma ferramenta puder simplesmente retornar dados." Uma ferramenta que apenas lê dados ainda carrega a implicação de uma ação; um recurso é explicitamente endereçável e cacheável de uma forma que uma chamada de ferramenta não é.
- "Prompts são extras opcionais que a maioria dos servidores ignora." Prompts importam mais exatamente quando a consistência entre clientes é importante, como um fluxo de trabalho de suporte compartilhado ou uma instrução padronizada de revisão de código.
- "Um servidor MCP tem que expor todos os três primitivos." Um servidor pode expor apenas ferramentas, apenas recursos, apenas prompts, ou qualquer combinação; nada exige todos os três.
- "MCP é um recurso específico do Claude." O MCP é um protocolo aberto; ele acontece de ser bem suportado pelo Claude Code, Claude Desktop e Agent SDK, mas qualquer cliente compatível com MCP pode usar um servidor em conformidade.
FAQs
Que problema o MCP realmente resolve que a chamada de função não resolve?
- A chamada de função vincula uma integração de modelo a um conjunto de funções escritas manualmente em um único aplicativo.
- O MCP padroniza o contrato (esquemas, descoberta, invocação) para que o mesmo servidor funcione em qualquer cliente compatível sem reescrever a integração.
As ferramentas MCP são a mesma coisa que chamada de função?
Conceitualmente sim, ferramentas são o equivalente MCP da chamada de função. A diferença é que o esquema e o comportamento de uma ferramenta são definidos uma vez em um servidor e descobertos por qualquer cliente, em vez de codificados diretamente no código de integração de um único aplicativo.
Quando algo deve ser um Recurso em vez de uma Ferramenta?
- Use um Recurso quando a operação for uma leitura sem efeitos colaterais, como buscar um arquivo, uma linha de banco de dados ou uma resposta de API.
- Use uma Ferramenta quando o modelo precisar tomar uma ação ou realizar um cálculo, mesmo que essa ação também retorne dados.
O que exatamente é um Prompt em termos de MCP?
Um Prompt é um modelo reutilizável e parametrizado que produz um conjunto de mensagens prontas para serem enviadas a um modelo. Ele permite que um servidor empacote uma instrução bem testada uma vez para que cada cliente que a invoca receba a mesma redação consistente.
Todo servidor MCP precisa definir todos os três primitivos?
Não. Um servidor pode expor apenas ferramentas, apenas recursos, apenas prompts, ou qualquer combinação dos três, dependendo das capacidades que ele precisa compartilhar.
Quem inicia uma leitura de recurso versus uma chamada de ferramenta?
- Uma chamada de ferramenta é iniciada pelo modelo durante uma conversa, com base na descrição e no esquema da ferramenta.
- Uma leitura de recurso pode ser iniciada pelo modelo ou diretamente pelo aplicativo cliente anexando contexto.
Um mesmo servidor MCP pode atender tanto ao Claude Code quanto a um aplicativo personalizado?
Sim. Esse design agnóstico ao cliente é um objetivo central do MCP: uma única implementação de servidor pode atender a Claude Code, Claude Desktop, Cowork e aplicativos personalizados do Agent SDK sem alterações.
O que acontece se eu expor uma operação com efeitos colaterais como um Recurso?
Funciona mecanicamente, mas engana qualquer cliente que assume que recursos são seguros para ler repetidamente ou cachear, já que recursos são destinados a representar dados legíveis, não ações com consequências.
Um Prompt é o mesmo que um prompt do sistema?
Não exatamente. Um Prompt MCP é um modelo nomeado e parametrizado que um cliente seleciona e invoca explicitamente, muitas vezes com argumentos, em vez de uma instrução fixa anteposta silenciosamente a cada conversa.
Por que a descoberta é importante para as ferramentas MCP?
- A descoberta permite que um cliente pergunte a um servidor quais capacidades ele oferece antes de usá-las.
- Sem descoberta, um cliente precisaria de conhecimento codificado de todas as ferramentas, recursos e prompts que um servidor suporta, o que anula o propósito de um protocolo compartilhado.
O MCP é útil apenas para ferramentas de desenvolvimento local?
Não. Servidores MCP podem ser executados localmente via stdio para ferramentas locais, ou remotamente via HTTP/SSE para servidores hospedados e compartilhados; o protocolo em si não assume um único estilo de implantação.
Como decido se uma nova capacidade deve ser incluída em meu servidor MCP?
- Pergunte se mais de um cliente ou fluxo de trabalho precisará dela; se sim, um primitivo MCP é uma boa opção.
- Pergunte se ela se encaixa claramente como uma ação (Ferramenta), dados legíveis (Recurso) ou uma instrução reutilizável (Prompt); se não se encaixar em nenhum dos três, pode não pertencer a este servidor.
Relacionados
- Noções Básicas dos Conceitos Principais do MCP - um guia prático definindo uma única ferramenta e conectando um cliente via stdio.
- Definindo Ferramentas Chamáveis em um Servidor MCP - como escrever esquemas e manipuladores de ferramentas em profundidade.
- Expondo Dados Legíveis como Recursos MCP - como servir arquivos, linhas e respostas de API como URIs de recursos.
- Comparação de Ferramentas vs. Recursos vs. Prompts MCP - uma comparação lado a lado para escolher o primitivo certo.
- Construindo Modelos de Prompt Reutilizáveis com Prompts MCP - empacotando prompts parametrizados para múltiplos clientes.
Versões da Stack: Escrito com base na linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5 - e a especificação atual do Model Context Protocol. Nomes de modelos, versões de SDK e a especificação MCP mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs e modelcontextprotocol.io antes de confiar neles.