covdbg MCP

Servidor MCP

• Seção: Documentação > Integrações > Servidor MCP
• Canônico: https://covdbg.com/docs/integrations/mcp/

---

O servidor MCP covdbg permite que um agente de codificação de IA meça a cobertura de C++ nativo no Windows e leia os resultados por meio de ferramentas estruturadas.

Iniciar o servidor

O servidor faz parte do executável covdbg:

covdbg mcp

Configure seu cliente MCP para iniciar covdbg com o argumento mcp, usando seu projeto como diretório de trabalho. O servidor usa entrada e saída padrão, com um objeto JSON por linha. Não é um serviço HTTP. discover pesquisa o diretório em que o servidor foi iniciado; passe --workspace <dir> quando o cliente não puder iniciá-lo dentro do projeto.

Para um cliente que lê um arquivo .mcp.json do projeto:

{
  "mcpServers": {
    "covdbg": {
      "command": "covdbg",
      "args": ["mcp"]
    }
  }
}

O executável deve estar no PATH do cliente, ou command deve indicar o caminho completo. Os nomes dos arquivos de configuração e as etapas de registro dependem do cliente.

Claude Code

Registre o servidor stdio local a partir do diretório do seu projeto:

claude mcp add covdbg -- covdbg mcp

Verifique a ajuda do cliente instalado para opções de escopo suportadas e inspecione as configurações MCP existentes antes de alterá-las. Após conectar, chame guide antes de iniciar uma execução de cobertura. Para obter ajuda com a configuração, use o prompt de início rápido de IA.

Pré-requisitos para uma execução

• Windows e um executável existente com símbolos de depuração PDB.
• Um login de desenvolvedor por meio de covdbg login, ou COVDBG_PROJECT_TOKEN no ambiente do servidor para CI.
• Um .covdbg.yaml ao lado do executável de destino, ou um config_path explícito na chamada run.

Leia o guide do servidor antes de medir. Sem um topic, ele explica o fluxo de trabalho. Os tópicos config, excludes, baseline, merging, uncovered, children e libraries cobrem a escrita de um .covdbg.yaml, a manutenção do CRT e do Windows SDK fora do relatório, código de biblioteca estática que nenhum binário de teste vincula, medição de uma suíte inteira, localização de código morto com SQL, alvos que fazem seu trabalho em um processo filho e código que vive em uma DLL. Uma configuração mal delimitada pode produzir cobertura enganosa.

O ciclo de melhoria

1. Chame guide e depois discover para encontrar executáveis e bancos de dados existentes.
2. Chame run com um alvo e configuração. Ele retorna uma sessão de execução imediatamente.
3. Chame wait_run até que termine. Cada chamada retorna após no máximo 30 segundos. Um resultado bem-sucedido inclui um ID de sessão de cobertura.
4. Chame files para classificar arquivos não cobertos e depois code para ler os segmentos não cobertos de um arquivo com contexto.
5. Faça o agente editar testes usando suas próprias ferramentas de codificação, execute os testes e meça novamente.
6. Revise tanto o resultado do teste quanto a mudança de cobertura. Feche as sessões quando terminar.

O servidor MCP não edita código-fonte nem gera testes por conta própria. Ele fornece as medições e o contexto que o agente de codificação conectado pode usar.

Referência de ferramentas

Ferramenta	Finalidade	Principais entradas
guide	Ler orientações de fluxo de trabalho e configuração	topic opcional
discover	Encontrar executáveis e bancos de dados de cobertura	root opcional
run	Iniciar uma execução de cobertura	target; target_arguments, config_path, output_path, follow_children opcionais
wait_run	Aguardar brevemente ou coletar o resultado concluído	session_id; timeout_seconds opcional
cancel_run	Encerrar uma execução	session_id
open_coverage	Abrir um banco de dados existente somente leitura	path
files	Classificar arquivos por linhas não cobertas	session_id; limit, max_coverage_percent opcionais
code	Ler segmentos de código-fonte não cobertos com contexto	session_id, file_path
query	Executar uma instrução SQL somente leitura	session_id, sql; max_rows opcional
merge	Combinar bancos de dados	input_paths, output_path
close	Liberar uma sessão de execução ou cobertura	session_id

Passe um filePath retornado por files diretamente para code. Código-fonte ausente é relatado explicitamente. query rejeita gravações e instruções como ATTACH que acessam fora do banco de dados aberto.

Defina follow_children em run quando o alvo for um lançador: um host de script, um shell ou um executor de testes que gera o processo que faz o trabalho real. Sem isso, apenas o lançador é medido. Ele fica desativado por padrão porque cada filho é instrumentado, e um alvo que faz chamadas externas repetidamente paga por cada uma; o tópico do guia children explica o custo. Ele tem o mesmo efeito que --follow-children na linha de comando ou settings.follow_children em .covdbg.yaml.

Sessões e saídas

Os IDs de execução começam com run-; os IDs de cobertura abertos começam com covdb-. As sessões duram enquanto o processo do servidor estiver ativo. Um wait_run bem-sucedido abre o banco de dados de saída automaticamente. O servidor mantém até 32 sessões de cobertura abertas e 8 execuções em andamento. Uma execução ocupa um slot apenas enquanto está em execução; uma execução concluída mantém seu resultado, mas não conta mais, então uma suíte com muitas execuções curtas não precisa de close entre elas.

Uma chamada wait_run bloqueia por no máximo 30 segundos, independentemente do que timeout_seconds solicitar, porque o servidor responde a uma chamada por vez e uma espera mais longa deixaria cancel_run inacessível. Se a resposta disser stillRunning, chame novamente. Os resultados concluídos distinguem success, no_functions_to_track, license_failure e error.

Por padrão, as execuções usam arquivos de saída temporários distintos. Um output_path explícito seleciona um destino. COVDBG_OUTPUT seleciona um local padrão fixo; evite reutilizar um local em uma suíte porque execuções posteriores podem sobrescrever resultados anteriores. Mescle os bancos de dados separados.

Limites importantes do fluxo de trabalho

• Sucesso de cobertura não é sucesso de teste. O código de saída do covdbg não propaga o código de saída do alvo. Verifique o resultado do executor de testes separadamente e leia a saída do alvo.
• Cancelamento perde a cobertura. O banco de dados é gravado quando a execução é concluída; cancelar uma execução não produz banco de dados de cobertura.
• O servidor inicia um alvo. Ele não pode anexar a um processo já em execução nem pausar em um ponto de interrupção para inspeção.
• O contexto do código-fonte é retornado ao seu cliente de IA. Um servidor MCP local não implica que o modelo do cliente processe esse contexto localmente.
• Esquemas de banco de dados incompatíveis mais antigos são rejeitados. Regere a cobertura com o build correspondente.

Para configurar com um agente de IA, consulte o início rápido de IA. Para relatórios compartilhados e CI, consulte relatórios de cobertura.