São Francisco (EUA), 30 de outubro de 2025 – A equipe de engenharia do GitHub apresentou o funcionamento de seu processo de avaliação offline para o GitHub MCP Server, base de vários fluxos do GitHub Copilot dentro e fora da plataforma. O objetivo é introduzir novos recursos sem provocar regressões, garantindo que modelos de linguagem escolham as ferramentas corretas e preencham os parâmetros adequadamente.
Três etapas de avaliação
O pipeline de testes é dividido em fulfillment, avaliação e sumarização:
- Fulfillment – Cada benchmark é executado em diferentes modelos, sempre com a lista de ferramentas MCP disponíveis. A saída registra quais ferramentas foram acionadas e quais argumentos foram enviados.
- Avaliação – Os dados brutos são processados e convertidos em métricas e pontuações.
- Sumarização – As estatísticas são agregadas e geram o relatório final.
Conjuntos de benchmark
Os testes utilizam bases de dados curadas contendo, para cada caso, o pedido em linguagem natural, as ferramentas esperadas e os respectivos argumentos. Entre os exemplos citados estão:
- Contar issues criadas em abril de 2025 no repositório github/github-mcp-server (ferramenta
list_issues). - Fazer merge da PR 123 em github/docs via squash merge (ferramenta
merge_pull_request). - Solicitar revisão de usuários específicos na PR 67 de team/project-alpha (ferramenta
update_pull_request). - Resumir comentários da discussão 33801 em facebook/react (ferramenta
get_discussion_comments).
Métricas de seleção de ferramenta
Quando há apenas uma chamada de ferramenta por entrada, o problema torna-se de classificação multiclasse. São calculados acurácia, precisão, revocação e F1-score. A equipe também monta uma matriz de confusão para identificar quais ferramentas costumam ser trocadas, como ocorria entre list_issues e search_issues.
Qualidade dos argumentos
Depois de confirmada a escolha da ferramenta, quatro indicadores verificam a correção dos argumentos:
Imagem: Internet
- Alucinação de argumentos – frequência de parâmetros inexistentes.
- Todos os argumentos esperados – presença de cada parâmetro previsto.
- Todos os argumentos obrigatórios – inclusão dos campos indispensáveis.
- Correspondência exata de valores – aderência total aos valores esperados.
Próximos passos
Os engenheiros reconhecem que a cobertura de benchmarks ainda é limitada e pretendem ampliar a quantidade de exemplos por ferramenta. Outra frente é avaliar cenários com chamadas sequenciais de múltiplas ferramentas, exigindo execução real ou simulação dos resultados durante os testes. A sumarização também deve evoluir para classificação multilabel, já que uma mesma entrada pode acionar diversos recursos.
Segundo o GitHub, o aperfeiçoamento contínuo da avaliação offline deve reduzir regressões, oferecer diagnósticos mais claros e garantir agentes mais confiáveis para desenvolvedores que utilizam o MCP Server.
Com informações de GitHub Blog
