MCP tools, resources y prompts: o que cada peça de um servidor MCP pode fazer
Publicado em 2026-10-26 por frfrand
Explicar o protocolo MCP e como escolher ferramentas, recursos e prompts
Quando conectás uma IA com ferramentas de servidores surge uma pergunta importante: o que ela pode fazer e o que só pode consultar? O MCP separa ferramentas que executam ações, recursos que fornecem contexto e prompts que estruturam interações.
Vamos colocar isso na prática: o que significa, como testar e o que acontece quando você usa com clientes ou informações reais. A maioria dos problemas não se resolve com um botão mágico, mas com passos que você pode repetir e medir.
O que são MCP tools, resources e prompts e por que isso importa
O Model Context Protocol define capacidades para que um cliente interaja com servidores MCP. As tools podem ter efeitos reais, como criar recursos; os resources expõem conteúdo identificável; e os prompts entregam modelos de mensagens. O suporte concreto varia de acordo com o cliente e o servidor.
Uma coisa é uma demonstração funcionar por cinco minutos e outra é manter um serviço todos os dias. Para isso, você precisa de limites, permissões, registros de atividade e procedimentos para resolver falhas sem improvisar.
Exemplo de implementação ou diagnóstico
// Ejemplo conceptual de herramienta MCP
{
"name": "listar_servicios_vps",
"description": "Consulta servicios sin modificarlos",
"inputSchema": {
"type": "object",
"properties": { "vps_id": { "type": "integer" } },
"required": ["vps_id"]
}
}É uma referência didática, não um modelo que você deve executar às cegas em produção. Substitua os valores de exemplo, escolha identidades com permissões mínimas e garanta que nenhuma chave sensível termine em um log ou repositório.
Como eu colocaria isso para funcionar
- Defina primeiro o que o agente precisa alcançar e quais informações são suficientes para ler.
- Crie ferramentas somente leitura para consultas frequentes e ações separadas para alterações.
- Descreva parâmetros, efeitos e erros em um esquema que o cliente possa entender.
- Peça confirmação para operações destrutivas ou de alto impacto, de acordo com o produto.
- Registre a identidade, o recurso afetado e o resultado de cada operação executada.
Após cada etapa, verifique um resultado concreto: uma ação autorizada, um status HTTP, uma tarefa processada, um custo registrado ou uma métrica estável. Se algo não funcionar, verifique qual foi a primeira falha antes de tentar novamente em loop.
Um exemplo que pode aparecer em um projeto real
Uma agência pergunta a uma IA quais apps estão em seu VPS. Listar serviços pode ser uma ferramenta de consulta. Reiniciar uma API é outra ferramenta distinta, com permissões, confirmação e logs. Misturá-las em uma ferramenta genérica de terminal aumenta o risco.
Se esse aplicativo tiver vários clientes, separe contextos e recursos. É especialmente importante quando um chatbot ou um agente pode consultar dados: a facilidade de conectar ferramentas não deve pular os limites de privacidade e autorização.
O erro mais comum
Não pense que, por colocar a palavra «somente leitura» na descrição, uma ferramenta é segura: o backend deve aplicar permissões reais. Um recurso com segredos também não deve ser acessível a qualquer cliente conectado.
Uma configuração com bons padrões ajuda, mas não elimina a necessidade de testes. Para serviços que gravam dados ou disparam ações, considere retentativas, duplicatas e falhas no meio do caminho.
Onde entra o ArduMaker?
O MCP do ArduMaker permite administrar recursos da plataforma por meio de agentes compatíveis. Projete quais operações cada identidade pode realizar e verifique suas permissões, especialmente em ambientes multiempresa.
Com o ArduMaker você pode hospedar o backend em um VPS, implantar a partir do Git, configurar domínio HTTPS e utilizar ferramentas de bases de dados, serviços e MCP de acordo com o projeto. Isso facilita reunir operações em um ambiente, embora as regras de negócio e de segurança continuem sendo responsabilidade do software.
O que mediria para saber se melhorou
Não mediria apenas «funciona/não funciona». Também revisaria consumo de recursos, erros, tempos de resposta ou gasto de API, conforme a funcionalidade. Defina uma medida de sucesso antes da mudança e compare com o mesmo cenário depois.
Se um dado parecer estranho, verifique a amostra e a janela temporal. Uma média pode esconder casos extremos, e uma única execução bem-sucedida não demonstra que uma automação suporte milhares de solicitações.
Perguntas frequentes
Preciso de uma infraestrutura grande para começar? Não necessariamente. Primeiro resolva o problema com uma arquitetura simples e meça o ponto em que começa a ficar aquém.
O que acontece se o provedor externo falhar? Você precisa de timeouts, política de tentativas e uma resposta útil para o usuário. Não assuma que as APIs externas estão sempre disponíveis.
Como mantenho o controle? Registre eventos importantes, separe permissões e conserve um procedimento testado para desfazer alterações ou recuperar informações.
Referências para seguir
A ideia final: automatizar e medir vale a pena quando você também sabe detectar um erro, limitar seus efeitos e se recuperar.