QA de Lançamento do MCP

Teste o servidor que os usuários executarão. Uma revisão de esquema ou um teste unitário aprovado não são evidências de tempo de execução.

Esta habilidade complementa a revisão de segurança. Ela foca no comportamento do protocolo, desvios no contrato publicado, correção de transporte e evidências de lançamento reproduzíveis.

Regras

• Execute verificações contra um processo de servidor novo, construído a partir da revisão candidata.
• Mantenha initialize, notifications/initialized, descoberta e invocação na mesma sessão. Um novo processo é uma nova sessão STDIO.
• Trate registros de origem como verdade de implementação e documentação pública como um contrato que deve corresponder a eles.
• Registre comandos exatos e respostas brutas. Não substitua evidências ausentes por "parece correto".
• Não invoque ferramentas com capacidade de mutação contra dados de produção. Use fixtures, um sandbox, ou pare e nomeie o ambiente de teste seguro ausente.
• Derive o inventário de capacidade esperado da origem candidata em cada execução.

1. Estabelecer a superfície de lançamento

Identifique:

• commit candidato e comando de build;
• ponto de entrada e transporte do servidor: STDIO, HTTP Streamable ou SSE;
• versões do protocolo MCP suportadas;
• arquivos de origem que registram ferramentas, recursos, modelos de recursos e prompts;
• catálogos gerados, manifestos, tabelas README e instruções de instalação;
• comandos existentes de protocolo, integração e smoke-test.

Prefira comandos nativos do repositório. Inspecione package.json, pyproject.toml, Makefile, fluxos de trabalho de CI e instruções de contribuidor antes de inventar um harness de teste.

2. Iniciar um servidor limpo

Construa o candidato e inicie o ponto de entrada documentado com configuração segura para testes. Capture:

• o comando exato;
• SHA do commit;
• nomes de variáveis de ambiente, com valores redigidos;
• stdout, stderr e status de saída;
• o endpoint ou transporte de processo filho usado pelo cliente.

Para STDIO, stdout é apenas para o protocolo. Logs, banners e traces de pilha pertencem ao stderr. Para transportes HTTP, registre o status, cabeçalhos MCP relevantes e o tratamento do identificador de sessão sem imprimir credenciais.

Se o servidor não puder ser iniciado a partir de suas instruções documentadas, relate isso como uma falha de lançamento e preserve o erro de inicialização literalmente.

3. Exercitar uma sessão completa

Execute esta sequência através de um cliente MCP real ou do harness de integração do repositório:

1. initialize com uma versão de protocolo que o servidor afirma suportar.
2. Confirme a versão negociada e as capacidades anunciadas.
3. Envie notifications/initialized.
4. Chame ping.
5. Chame cada método de descoberta suportado:
   • tools/list
   • resources/list
   • resources/templates/list
   • prompts/list
6. Exercite pelo menos um item representativo somente leitura de cada classe de capacidade anunciada.
7. Siga a paginação até que nenhum cursor permaneça quando um método de lista for paginado.

Não envie requisições pós-inicialização através de processos separados de uso único. Isso testa acidentalmente várias sessões incompletas em vez de uma sessão válida.

4. Provar paridade de inventário

Construa quatro inventários a partir de evidências atuais:

Compare por identificador estável. Relate:

• entradas de origem ausentes em tempo de execução;
• entradas em tempo de execução ausentes em metadados ou documentação;
• nomes, descrições, argumentos, URIs ou parâmetros de prompt desatualizados;
• comandos de instalação documentados que não iniciam o servidor candidato.

Regenere arquivos derivados com o comando de build do próprio repositório, e falhe se a árvore de trabalho ainda contiver alterações geradas inexplicadas.

5. Verificar contratos publicados

Para cada item descoberto, verifique a definição em tempo de execução contra sua origem:

Ferramentas

• Nome e descrição são estáveis e específicos.
• inputSchema define tipos, campos obrigatórios, enums e limites onde necessário.
• Propriedades desconhecidas são rejeitadas quando o contrato da ferramenta é fechado.
• Anotações de mutação, idempotência, somente leitura e mundo aberto correspondem ao comportamento.
• Chamadas bem-sucedidas conformam-se a outputSchema quando uma é publicada.
• Erros são erros de protocolo ou falhas estruturadas da ferramenta, não traces de pilha vazados.

Recursos e modelos

• URIs e tipos MIME correspondem às definições registradas.
• Recursos estáticos são legíveis.
• Parâmetros de modelo são validados antes da resolução.

…