MCP no Claude Desktop: teste com o Greeting Server
MCP já configurado: achar tools na UI do Claude Desktop e usar o Greeting Server como smoke test rápido e confiável do seu setup. na prática
Resposta direta
Com o MCP já configurado, o Claude Desktop (no relato: Cloud Desktop) lista o Greeting Server como ferramenta #1 e expõe Friendly Greeting. O smoke test confirma: Node sobe o servidor, a UI lista tools, o gatilho «saudação» pede autorização e devolve cumprimento com data/hora — no exemplo, domingo ~10h40. Em seguida, ao informar o nome «Fábio», o modelo passa o nome para a tool e volta saudação personalizada. Isso prova cliente ↔ servidor MCP de ponta a ponta.
MCP no Claude Desktop
No material, o fluxo começa depois da configuração: voltar ao Claude Desktop, abrir o botão de procurar ferramentas e ver o Greeting Server já disponível. O número 1 ao lado do servidor sinaliza que a listagem funcionou — o cliente encontrou o servidor e conseguiu enumerar o que ele oferece.
Ao clicar, aparece a tool Friendly Greeting. O relato deixa explícito o mecanismo: o Desktop, via Node, executou o servidor MCP e, com o servidor à disposição, listou as ferramentas expostas. Sem essa listagem, o restante do tutorial de tool complexa não tem base.
O pedido «Me ofereça uma saudação» ativa o gatilho: a palavra-chave «saudação» faz o Desktop identificar que precisa consultar uma ferramenta externa. Por segurança, pede autorização antes de chamar a tool — no relato, a resposta é autorizar sempre neste smoke test.
Achar tools na UI
Depois da autorização, a tool devolve a saudação observada no vídeo: «bom dia, amigo, é um prazer te cumprimentar», com dia e hora — domingo, exatamente 10h40 no exemplo. O ponto não é a frase em si; é a prova de comunicação cliente → servidor → resposta.
O material destaca que o mesmo canal poderia dar acesso a outras coisas além de saudação. Por isso o Greeting Server funciona como smoke test: se Friendly Greeting não aparece ou não responde, o MCP ainda não está plugado de verdade — corrija config antes de construir tool de produção.
Information gain
Ganho específico (1750957206001): UI lista Greeting Server #1 + Friendly Greeting; gatilho «saudação»; auth; output com data/hora.
Greeting Server como smoke test
O segundo prompt do relato: «Meu nome é Fábio. Me ofereça uma saudação personalizada.» O Desktop identifica o nome, inclui no output da ferramenta e ainda traz data/hora personalizadas. Ou seja: o modelo extrai informação do usuário e passa para a tool programada devolver a saudação com esse dado.
O autor marca que a solução «não é assim tão simples»: há handoff entre linguagem natural, escolha de tool, autorização e execução no servidor. Para quem está validando MCP, esse caminho curto (saudação genérica → saudação com nome) é o checklist mínimo de integração.
Se o nome não entra no output, o problema está no contrato da tool ou no mapeamento de argumentos — não em «prompt melhor». O transcript ancora o sucesso no fato de o nome Fábio ter sido incluído na resposta.
Próximo passo útil
Repita o smoke test no seu ambiente: (1) Greeting Server visível na UI; (2) Friendly Greeting listada; (3) pedido de saudação com autorização; (4) resposta com horário; (5) pedido com nome e verificação de que o nome volta no output. Só então troque o Greeting Server por tools do seu domínio.
Guarde o relato do domingo ~10h40 como referência de sucesso observável: não é métrica de produto, é evidência de que Node + MCP + Desktop conversaram. Sem essa evidência, qualquer tool nova vira debug cego.
Próximo passo acionável
Nas próximas 48 horas: rode o Greeting Server no Claude Desktop, grave screenshot da tool #1 e da autorização, e replique o par de prompts (saudação / saudação com nome). Se falhar em qualquer passo, pare e corrija a config MCP antes de escrever código novo de ferramenta.
Detalhe que muda a execução
O detalhe que o resumo rápido perde: a autorização de segurança entre gatilho linguístico e execução da tool. No transcript, o Desktop só chama Friendly Greeting depois do «sempre está autorizado». Sem esse passo, a demo não completa — e em produção o mesmo padrão de consentimento protege o usuário.
Segunda âncora: o modelo não «inventa» a saudação personalizada sozinho no exemplo — ele fornece o nome à ferramenta, e a ferramenta (programada) devolve a saudação incluindo a informação passada. Trate isso como contrato tool ↔ modelo, não como mágica de chat.
Perguntas frequentes
Qual mecanismo de «Achar tools na UI» não depende de moda de ferramenta?
Parta do mecanismo descrito: Depois da autorização, a tool devolve a saudação observada no vídeo: «bom dia, amigo, é um prazer te cumprimentar», com dia e hora — domingo, exatamente 10h40 no exemplo. O ponto não é a frase em si; é a prova de comunicação cliente → servidor → resposta.
Como usar «Greeting Server como smoke test» sem copiar o roteiro inteiro — no sentido de operação?
Critério do artigo: O segundo prompt do relato: «Meu nome é Fábio. Me ofereça uma saudação personalizada.» O Desktop identifica o nome, inclui no output da ferramenta e ainda traz data/hora personalizadas. Ou seja: o modelo extrai informação do usuário e passa para a tool. Segundo sinal: O autor marca que a solução «não é assim tão simples»: há handoff entre linguagem natural, escolha de tool, autorização e execução no servidor. Para quem está validando MCP, esse.
O que «Próximo passo útil» muda no próximo experimento?
Alerta do corpo: Repita o smoke test no seu ambiente: (1) Greeting Server visível na UI; (2) Friendly Greeting listada; (3) pedido de saudação com autorização; (4) resposta com horário; (5) pedido com nome e verificação de que o nome volta no output. Só então troque o Greeting. Ajuste ao contexto de `mcp-greeting-server-claude` antes de generalizar.
Qual hedge o texto faz em torno de «Próximo passo acionável»?
Resposta direta: Nas próximas 48 horas: rode o Greeting Server no Claude Desktop, grave screenshot da tool #1 e da autorização, e replique o par de prompts (saudação / saudação com nome). Se falhar em qualquer passo, pare e corrija a config MCP antes de escrever código novo de.