😰 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.
📝 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.
| Marcador | Exemplo do vídeo | Como preencher no seu caso |
|---|---|---|
| APP_E_WORKSPACE | Claude Desktop, aba Claude Code | App exato e onde dentro dele (workspace, projeto, aba). |
| NOME_DA_FERRAMENTA | MCP "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_ESPERADO | Título, link da fonte e três pontos úteis; a chamada visível; um ponto conferido na fonte | Condiçã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.
🔍 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.
✓ O que o relatório mostra quando a inspeção foi feita
- ✓"A ferramenta
search_lessonsfoi chamada comquery='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.
🔁 Follow-ups encadeados e o caso sem resultado
Como o agente encadeia
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.
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.
Follow-up 2, dependente do 1
"Existe outra aula que aprofunde esse ponto?" Testa se a ferramenta é chamada de novo com o contexto certo.
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.
⏱️ Conferir com a fonte e medir tempo sem inventar
| O que registrar | Como | Quando decompor |
|---|---|---|
| Entradas observadas | Os parâmetros exatos de cada chamada | Sempre |
| Saída | Registros devolvidos e o que o assistente usou deles | Sempre |
| Erros | Mensagem literal, tela onde apareceu | Sempre |
| Tempo decorrido | Do envio da pergunta à resposta completa | Sempre |
| Tempo do modelo × da ferramenta × configuração | Só se o app mostra marcações de tempo por etapa | Só 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.
📄 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.
💡 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
Próximo módulo:
2.3 - Um agente testa outro