Usando o aplicativo como um servidor MCP
O aplicativo pode consumir um servidor MCP ou expor seu próprio servidor a um cliente externo.
O que você aprenderá
- Explique: host, cliente e servidor
- Aplique a ideia em um exemplo: Usando a aplicação como servidor MCP
- Reconheça as limitações e verifique o resultado do exercício
O aplicativo pode consumir um servidor MCP ou expor seu próprio servidor a um cliente externo. Estas são direções opostas.
Estas etapas referem-se aos recursos identificados no código do aplicativo. Este material não foi validado em uma instância ativa; verifique a documentação e as opções da sua versão.
Como funciona, passo a passo
Host, cliente e servidor
MCP é um protocolo que conecta aplicativos de IA a recursos externos. O host fornece a experiência, o cliente gerencia a conexão e o servidor expõe ferramentas, recursos ou prompts de acordo com o suporte. As ferramentas executam operações; os recursos fornecem conteúdo endereçável; prompts fornecem modelos. Nem todo servidor implementa todos os três. O transporte transporta mensagens, a autenticação identifica os chamadores e a autorização controla o acesso. Verifique a revisão do protocolo e as extensões suportadas em ambas as extremidades. A compatibilidade não pode ser inferida apenas a partir de um rótulo “MCP”.
Verifique o acesso antes de usar
As permissões devem ser aplicadas pelos servidores e pela camada de dados. Não deixe o modelo decidir se um usuário pode ver um documento. Filtre as fontes antes que elas entrem no contexto, não depois de gerar a resposta. Use credenciais de acesso mínimo, mantenha-as fora de prompts, capturas de tela e códigos do navegador e alterne as chaves expostas. Uma lista de permissões de domínio de widget não substitui a autenticação de API. A autenticação identifica você; a autorização determina as operações e os dados que você pode usar. Teste o acesso negado também.
O modelo propõe, a ferramenta executa
A chamada da ferramenta produz uma solicitação de chamada com nome e argumentos. A aplicação valida o esquema, as permissões e os limites antes da execução. O resultado retorna ao contexto para a próxima etapa. Por exemplo, get_product_stock pega um SKU e retorna uma quantidade; sua descrição deverá explicar que não reserva produtos. Distinguir resultados vazios, erros de validação, falta de acesso e tempos limite. JSON válido não prova que os argumentos estão corretos ou que a ação está autorizada. Para efeitos externos, considere também a execução duplicada.
O esquema explicativo
Siga as setas sólidas para o fluxo principal. As setas azuis tracejadas fornecem dados ou contexto; setas rosa tracejadas mostram feedback ou retorno de resultados. Cores e formas distinguem modelos, lojas, decisões e resultados. Em telas pequenas, role na horizontal para acompanhar o esquema completo.
Um exemplo completo
O /api/mcp local é protegido por uma chave configurada para implantação. As ferramentas expõem administração de agente, RAG, fluxo de trabalho, widget e servidor MCP; alguns criam ou excluem dados.
Experimente você mesmo
- Configure um cliente de teste com o segredo fornecido pelo administrador e inspecione as ferramentas antes das chamadas.
- Registre a entrada, a fonte e o resultado esperado antes de executar o experimento. Use apenas os dados fictícios do exemplo.
- Siga as etapas do diagrama. A cada passo registre quais informações são recebidas e produzidas; não confunda o resultado intermediário com o resultado final.
- Repita após remover as informações necessárias ou tornar a entrada ambígua. Verifique se o sistema esclarece, interrompe ou inventa uma resposta.
- Compare com a solução explicada. Guarde a configuração, data, resultado e explicação das diferenças. Mude uma coisa e teste novamente.
Uma solução explicada
Comece com descobertas e leituras; verifique os argumentos da organização/projeto e não assuma uma chave de usuário comum. Um exercício bem-sucedido permite mostrar a conexão entre entradas, etapas e resultados. Quando falta informação, uma resposta cautelosa é mais útil do que detalhes inventados. Compare mais do que estilo: verifique também as condições, fontes e operações.
Quando esta abordagem ajuda e quais são seus limites
O servidor local anuncia ferramentas; não assuma recursos, prompts ou OAuth completo. Escolha esta abordagem quando ela melhorar uma necessidade medida. Mantenha uma linha de base simples e compare os resultados usando dados idênticos. Um exemplo de sucesso não estabelece confiabilidade em todas as situações.
Verifique o que aprendeu
Um servidor com ferramentas oferece recursos e prompts automaticamente?
Não. Os recursos são opcionais e devem ser descobertos e verificados.
Por que remover uma fonte privada depois de responder tarde demais?
Os dados já entraram no contexto do modelo e podem ser divulgados.
Que resultado este exercício deve produzir?
Comece com descobertas e leituras; verifique os argumentos da organização/projeto e não assuma uma chave de usuário comum.
Termos para lembrar
- Servidor MCP: um serviço que expõe recursos por meio do Model Context Protocol.
- Autorizar / Autorização: Verificando o direito de acesso a uma operação ou recurso.
- Chamada de ferramenta: uma solicitação estruturada para usar um recurso externo.
Fontes e sua próxima etapa
- Model Context Protocol — Specification
- OWASP — Injeção de prompt
- LangGraph — Fluxos de trabalho e agentes
Para preparar: M04 — Construindo um servidor MCP mínimo