MCP no Claude Desktop: teste com o Greeting Server

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.

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.