Tema

Tamanho do texto

Fonte

Entrelinha

MÓDULO 2.2

🧪 Testar ferramentas dentro do app

Quem publica um MCP, uma skill ou um plugin sabe: o mais difícil é simular o primeiro uso de outra pessoa. Este fluxo coloca o Codex para abrir o Claude Desktop, instalar a sua ferramenta, conversar com ela, abrir cada chamada e devolver a jornada inteira com evidência.

6
Tópicos
45
Minutos
Intermediário
Nível
Prática
Tipo
0 de 60%
1

😰 A dor de quem publica: simular o primeiro uso

No vídeo, o autor testa um MCP próprio que liga a comunidade dele (posts, aulas, comentários) ao Claude e ao Codex. Ele pede ao Codex que abra o Claude Desktop, confirme que está na aba do Claude Code, verifique se o conector está ligado, faça uma pergunta e "tenha algumas idas e vindas para garantir que a jornada do usuário seja a mais suave possível". Vinte minutos depois, recebe o relatório.

1 App certo? workspace, aba, conector 2 Pedido realista, só leitura 3 Inspecionar a chamada, não a resposta 4 Follow-ups dois, encadeados 5 Sem resultado admite ou inventa? 6 Fonte uma afirmação conferida A jornada que o agente percorre no app hospedeiro: confirmar app e workspace, checar a ferramenta, pedido realista, inspecionar a chamada, dois follow-ups, caso sem resultado, conferir com a fonte
O que olhar: Seis etapas, e você provavelmente só faz a segunda quando testa à mão. As outras cinco são o que o usuário novo vive.
2

📝 O prompt 02, traduzido

Copie e rode

Testar um MCP, skill ou plugin seu pela interface real do app hospedeiro (Codex com computer use; app hospedeiro instalado e logado)

Use computer use para testar minha integração existente dentro do app hospedeiro real.

App hospedeiro e workspace: <APP_E_WORKSPACE>
Ferramenta / MCP / integração: <NOME_DA_FERRAMENTA>
Fonte ou tema seguro de teste: <FONTE_OU_TEMA>
Resultado esperado de sucesso: <RESULTADO_ESPERADO>
Código-fonte opcional: <CAMINHO_DO_REPO_OU_NONE>

Confirme que está no app e no workspace certos. Verifique se a ferramenta está disponível. Se for preciso configurar, use as instruções de instalação fornecidas, preserve a configuração existente e reporte exatamente o que mudou. Pare em qualquer login ou entrada de segredo que precise de mim. Não reconstrua uma ferramenta que já existe.

Rode um pedido realista e só de leitura. Inspecione os detalhes reais da chamada de ferramenta, não só a mensagem final do assistente. Faça dois follow-ups naturais que dependam da primeira resposta. Inclua um caso de fonte ausente ou sem resultado para checar se ele lida com a incerteza honestamente.

Confira uma resposta material contra a fonte de origem. Registre entradas observadas, saída, erros e tempo decorrido. Separe tempo de resposta do modelo, tempo de execução da ferramenta e atrito de configuração só quando a evidência sustentar essa distinção. Não invente decomposições de tempo.

Devolva um relatório curto: checagens que passaram, falhas reproduzidas, evidência e a correção de maior valor. Se houver código-fonte, identifique o local provável sem aplicar mudanças neste teste. Mantenha registros privados fora do relatório. Não envie mensagens a outras pessoas.
Como verificar: O app hospedeiro invocou a ferramenta pretendida (a chamada aparece no relatório). Os follow-ups mantiveram o contexto. Uma afirmação devolvida bate com a fonte. O caso sem resultado não inventou resposta.
MarcadorExemplo do vídeoComo preencher no seu caso
APP_E_WORKSPACEClaude Desktop, aba Claude CodeApp exato e onde dentro dele (workspace, projeto, aba).
NOME_DA_FERRAMENTAMCP "community brain" (posts e aulas da comunidade)O nome como aparece na lista de conectores do app.
FONTE_OU_TEMA"Uma aula sobre construir ou testar MCPs"Algo que existe na sua base e não tem dado privado.
RESULTADO_ESPERADOTítulo, link da fonte e três pontos úteis; a chamada visível; um ponto conferido na fonteCondição que dá para ver na tela, não "responde bem".

💡 Diga a aba

O vídeo acrescenta um detalhe ao prompt: "use a aba do Claude Code". O agente checou, viu que não estava nela, corrigiu e seguiu. Quanto mais exato o app e o lugar dentro dele, menos passos perdidos.

3

🔍 Inspecionar a chamada, não a resposta

"A melhor parte é que ele não só monitora a conversa, ele clica nos menus para ver exatamente o que está acontecendo por trás: todas as aulas que foram puxadas, as fontes exatas e tudo o que há no meio." Essa frase do vídeo é a diferença entre um teste de aparência e um teste de funcionamento.

TEXTO FINAL o que o assistente escreveu; pode estar certo por acaso A CHAMADA a ferramenta foi acionada? qual? quantas vezes? PARÂMETROS E REGISTROS o que entrou, o que voltou, de onde FONTE ORIGINAL o dado bate com o lugar de onde veio? de fora para dentro
O que olhar: Testar à mão costuma parar na primeira camada. O prompt exige chegar à quarta em ao menos uma afirmação.

✓ O que o relatório mostra quando a inspeção foi feita

  • "A ferramenta search_lessons foi chamada com query='testar MCP' e devolveu 4 registros; o assistente citou 3."
  • "O segundo follow-up não gerou nova chamada: a resposta veio do contexto anterior."
  • "No caso sem resultado, a ferramenta devolveu lista vazia e o assistente disse que não encontrou."

✗ O que aparece quando só a resposta foi lida

  • "O assistente respondeu corretamente sobre MCPs."
  • "As respostas foram úteis e rápidas."
  • "Não houve erro."

⚠️ O erro que a inspeção pega

O modelo responde uma pergunta sobre a sua base sem chamar a ferramenta, usando o que já sabia. O texto parece perfeito. A chamada não existe. Sem abrir o painel, você aprovaria um MCP que não foi usado.

4

🔁 Follow-ups encadeados e o caso sem resultado

Como o agente encadeia

1

Primeira pergunta realista

Sobre o tema seguro. Exemplo do vídeo: encontrar uma aula sobre construir ou testar MCPs e trazer título, link e três pontos.

2

Follow-up 1, dependente

"Desses três pontos, qual o autor considera o mais importante e por quê?" Só faz sentido se a primeira resposta estiver no contexto.

3

Follow-up 2, dependente do 1

"Existe outra aula que aprofunde esse ponto?" Testa se a ferramenta é chamada de novo com o contexto certo.

4

Caso sem resultado

Uma pergunta sobre algo que não existe na base: "qual aula fala de integração com o sistema X?" (que nunca foi coberto). A resposta correta é "não encontrei".

🧠

Contexto retido

Os follow-ups são respondidos sem repetir a pergunta original e sem confundir "esses três pontos" com outros.

🤷

Incerteza honesta

No caso sem resultado, o assistente declara que a ferramenta não devolveu nada. Não completa com conhecimento geral fingindo que veio da base.

🧾

Evidência de cada um

Para cada follow-up, o relatório diz se houve nova chamada, com que parâmetros, e o que voltou.

💡 Escolha o caso sem resultado com cuidado

Ele precisa ser algo que a sua base realmente não tem, mas que soe plausível. Se for absurdo demais, o modelo recusa por outro motivo e o teste não mede o que devia.

5

⏱️ Conferir com a fonte e medir tempo sem inventar

O que registrarComoQuando decompor
Entradas observadasOs parâmetros exatos de cada chamadaSempre
SaídaRegistros devolvidos e o que o assistente usou delesSempre
ErrosMensagem literal, tela onde apareceuSempre
Tempo decorridoDo envio da pergunta à resposta completaSempre
Tempo do modelo × da ferramenta × configuraçãoSó se o app mostra marcações de tempo por etapaSó com evidência. "Do not invent timing breakdowns."

🔎 A conferência com a fonte

O prompt pede uma afirmação material conferida na origem. No vídeo: um dos três pontos da aula, aberto na fonte real. Se o ponto não está lá, a ferramenta ou o modelo distorceu. Uma conferência basta para o teste; se ela falhar, o relatório inteiro muda de tom.

⚠️ Registros privados ficam fora

O relatório circula. O prompt manda manter registros privados fora dele e não enviar mensagens a outras pessoas. Se a sua base tem dados de clientes, o tema seguro de teste é o que garante que nada disso apareça no relatório.

6

📄 O relatório, a correção de maior valor, e a ponte entre apps

Vinte minutos depois do envio, o vídeo mostra o retorno: feedback sobre o MCP e, mais abaixo, trechos do código monitorado com a observação de que "a forma como você estruturou esta função e esta função não é eficiente e causa atraso e latência". O prompt permite isso quando o código-fonte é fornecido, e proíbe aplicar mudanças durante o teste.

Checagens que passaram

Lista curta: ferramenta invocada, follow-ups com contexto, fonte conferida, caso sem resultado tratado.

Falhas reproduzidas

Cada falha com o passo exato para repetir e a evidência (painel da chamada, mensagem, tempo).

🎯

A correção de maior valor

Uma só. Com o arquivo e a região provável do código, sem editar. Você decide se e quando aplica.

CODEX (quem testa) Abre o app hospedeiroDigita, clica, abre painéisLê e registra CLAUDE / GEMINI (onde a ferramenta roda) Conector ou skill instaladoResponde e chama a ferramentaMostra a chamada nos painéis sem API, sem plugin
O que olhar: O vídeo diz: se não existe plugin para o Gemini, abra o app do Gemini e deixe o Codex usá-lo. É uma conversa entre modelos sem nenhuma API no meio.

💡 Skill que funciona no Codex e no Claude?

Este é o teste. Rode o prompt 02 duas vezes: app hospedeiro Codex, depois app hospedeiro Claude Code. Compare os dois relatórios. Onde a chamada difere, a skill depende de algo que um dos dois não tem.

🧪 Teste rápido do módulo

Três perguntas. Clique numa opção para ver a resposta.

1. O assistente respondeu perfeitamente sobre a sua base de conhecimento, mas o relatório não mostra nenhuma chamada de ferramenta. O que aconteceu?

2. O app não mostra tempo por etapa, mas você quer saber quanto foi modelo e quanto foi ferramenta. O que o relatório deve dizer?

3. No caso sem resultado, o assistente escreveu três parágrafos úteis sobre o tema. Passou?

📋 Resumo do módulo

O problema - você não consegue simular o primeiro uso da própria ferramenta; um agente com instruções de usuário novo consegue e registra.
Seis etapas - app certo, pedido só de leitura, inspecionar a chamada, dois follow-ups encadeados, caso sem resultado, conferir com a fonte.
A chamada, não a resposta - abrir os painéis do app: qual ferramenta, com que parâmetros, quantos registros, de onde.
Tempo com evidência - registrar o total sempre; decompor modelo/ferramenta/configuração só quando o app mostra.
Relatório e ponte - passou, falhou, evidência, uma correção de maior valor com local provável; o mesmo fluxo liga Codex a Claude ou Gemini sem API.

Próximo módulo:

2.3 - Um agente testa outro