azdevcreator-mcp-server

Servidor MCP para integracao com Azure DevOps, com foco em:

• Work Items (Feature, User Story, Task, Bug)
• Sprint/Iteration lookup
• Pull Request review (contexto, alteracoes e comentarios)

Visao Geral

Este servidor atua como um adaptador entre agentes de IA e Azure DevOps para reduzir erro operacional e padronizar fluxos.

Principais ganhos:

• validacao de regras de workflow;
• normalizacao de responsavel;
• defaults seguros na criacao;
• update sob demanda (sem alterar campos nao enviados);
• automacao de code review em PR.

Tools Disponiveis

Work Items

1. get_workflow_rules

• Retorna regras de workflow carregadas de docs/instructions/workflow-rules.md.

2. create_ado_item

• Cria item no Azure DevOps com validacoes por tipo.
• Tipos suportados: Feature, User Story, Task, Bug.

3. update_ado_item

• Atualiza item existente de forma parcial (apenas campos enviados).

4. get_ado_item

• Busca resumo de item por ID.

Sprints

5. list_sprints

• Lista sprints/iterations de um time no Azure DevOps.
• Suporta timeframe: current.

Pull Request Review

6. get_pull_request_context

• Metadados da PR + arquivos alterados da iteracao mais recente.

7. get_pull_request_changes

• Lista alteracoes da PR (filtro opcional por path).

8. create_pull_request_comment

• Cria comentario geral ou inline por arquivo/linha na PR.

Nuances de Create e Update

create_ado_item

• iterationPath:

  • se nao enviado, default: manutencao-squad.

• Para Task:

  • Custom.CategoriaDemanda: Modulos Tecnicos Datum
  • Custom.Cliente: Brasil
  • Custom.Projeto: valor de taskProject ou default Modulos Tecnicos Datum

Resumo:

• Create aplica defaults para reduzir falha de criacao.

update_ado_item

• Atualizacao parcial real: so altera campos enviados.

• iterationPath:

  • so atualiza se for enviado explicitamente.

• Campos de Task (Projeto e Cliente):

  • so atualizam quando taskProject e enviado.
  • ao enviar taskProject:
    • Custom.Projeto recebe o valor informado
    • Custom.Cliente recebe Brasil

Resumo:

• Update nao aplica defaults silenciosos nesses campos.

Arquitetura

src/
├── index.ts
├── config.ts
├── context/
│   └── workflow.ts
├── domain/
│   ├── types.ts
│   ├── validation.ts
│   └── assignees.ts
├── infra/
│   └── adoClient.ts
└── tools/
    ├── workflowRules.ts
    ├── createAdoItem.ts
    ├── updateAdoItem.ts
    ├── getAdoItem.ts
    ├── listSprints.ts
    └── pullRequestReview.ts

Instalacao e Execucao

Via npx (recomendado)

ADO_PAT_TOKEN=seu_token \
ADO_URL="https://dev.azure.com/Edenred-TicketLog" \
ADO_PROJECT="manutencao-squad" \
npx -y @mbnaysinger/azdevcreator-mcp-server

Variaveis de ambiente

• ADO_PAT_TOKEN ou ADO_PAT (obrigatorio)
• ADO_URL (opcional)
• ADO_PROJECT (opcional, default para Work Items)
• ADO_PR_PROJECT (opcional, fallback para PR review)
• ADO_REPOSITORY (opcional, fallback para PR review)

Observacao multi-repositorio:

• para PR review em varios projetos/repositorios, prefira enviar project e repositoryId em cada chamada.

Exemplo de Configuracao MCP (JSON)

{
  "mcpServers": {
    "azdevcreator": {
      "command": "npx",
      "args": ["-y", "@mbnaysinger/azdevcreator-mcp-server"],
      "env": {
        "ADO_PAT_TOKEN": "seu_token_aqui",
        "ADO_URL": "https://dev.azure.com/Edenred-TicketLog",
        "ADO_PROJECT": "manutencao-squad"
      }
    }
  }
}

Onboarding: Prompts Eficientes

Os prompts abaixo ajudam o agente a manter contexto e executar as tools corretamente.

1) Criar Feature

Crie uma Feature no Azure DevOps com:
- title: [FEATURE] Painel de acompanhamento de contestacoes
- description: objetivo, escopo, criterios de aceite e riscos
- status: New
- assignedTo: [email protected]
- tags: Datum, AI Tooling
- iterationPath: manutencao-squad\Datum Modulos Tecnicos\DatumMT - Sprint AbrQ2 2026

2) Criar User Story

Crie uma User Story vinculada a Feature 204000:
- title: [US] Exibir timeline de tratativa no detalhe da contestacao
- description: contexto funcional, regra de negocio e criterios de aceite
- status: Read For Dev
- parentId: 204000
- assignedTo: [email protected]
- originalEstimate: 8
- tags: Datum
- iterationPath: manutencao-squad\Datum Modulos Tecnicos\DatumMT - Sprint AbrQ2 2026

3) Criar Task

Crie uma Task filha da US 204321:
- title: [TASK] Ajustar validacao de filtro por data
- description: implementar ajuste no backend e garantir cobertura de testes
- status: New
- parentId: 204321
- assignedTo: [email protected]
- originalEstimate: 3
- taskProject: Modulos Tecnicos Datum
- tags: Datum
Se iterationPath nao for informado, use o default.

4) Criar Bug

Crie um Bug:
- title: [BUG] Falha ao enviar multiplos itens na contestacao
- description: ao enviar mais de um item, o array chega incompleto no backend
- status: New
- assignedTo: [email protected]
- tags: Datum, BACKLOG
- iterationPath: manutencao-squad\Datum Modulos Tecnicos\DatumMT - Sprint AbrQ2 2026

5) Update sob demanda (sem ruido)

Atualize o item 207103 apenas com:
- status: In Development
- comment: iniciado desenvolvimento com ajuste de payload
Nao altere iterationPath, projeto ou cliente.

6) Update de Task com Projeto/Cliente

Atualize a Task 207104 com:
- taskProject: Modulos Tecnicos Datum
- iterationPath: manutencao-squad\Datum Modulos Tecnicos\DatumMT - Sprint MaiQ1 2026
- comment: replanejada para proxima sprint

Prompt Orquestrado para Code Review (Recomendado)

Use este prompt para "amarrar" o fluxo e reduzir chance de o agente pular tools:

Quero um code review completo da PR {PR_ID} no projeto {PR_PROJECT} e repositorio {REPOSITORY_ID}.

EXECUCAO OBRIGATORIA (na ordem):
1) Chame get_pull_request_context com pullRequestId, project e repositoryId.
2) Chame get_pull_request_changes para obter arquivos alterados.
3) Classifique os arquivos em frontend, backend ou misto.
4) Leia obrigatoriamente os guias de boas praticas:
   - frontend: docs/americas/patterns/frontend.md
   - backend: docs/americas/patterns/backend.md
5) Compare as alteracoes da PR com o baseline local (branch {BASE_BRANCH}) e considere diferencas da branch remota da PR.
6) Gere findings ordenados por severidade (alta, media, baixa), com:
   - arquivo
   - impacto
   - recomendacao objetiva
7) Para findings de severidade alta/media, crie comentarios inline usando create_pull_request_comment (filePath + line).
8) Gere um comentario final consolidado na PR com:
   - resumo dos riscos
   - testes faltantes
   - checklist de aderencia aos guias

REGRAS:
- Nao pular etapas.
- Nao comentar pontos sem evidencia no diff.
- Se faltar contexto, explicitar a lacuna no resumo final.

Dica:

• ao usar multiplos repositorios/projetos no mesmo dia, sempre passe project e repositoryId nas chamadas de PR review.

Boas Praticas

• Em update_ado_item, envie apenas os campos que realmente devem mudar.
• Em PR review, prefira comentarios curtos, acionaveis e com referencia direta ao trecho.
• Em cenarios mistos (front/back), aplique os dois guias.

Versionamento

SemVer (MAJOR.MINOR.PATCH):

• PATCH: correcao sem quebra de contrato
• MINOR: nova tool/campo compativel
• MAJOR: breaking change

Fluxo sugerido:

npm run build
git add .
git commit -m "feat: descricao curta"
npm version patch
npm publish --access public
git push origin main --follow-tags

Seguranca

• Nunca commitar tokens em .env.
• Se token for exposto, revogue e gere novo imediatamente.