ado-mcp-server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ado-mcp-server show me open pull requests in the main repository"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ado-mcp-server
MCP server local que dá ao Claude Code acesso controlado e seguro-por-padrão ao Azure DevOps Server on-premise: gestão completa de work items (epic, feature, PBI, task, bug — campos, hierarquia, links, discussão, anexos), pull requests e repos. Ver DESIGN.md para o modelo de arquitetura e SECURITY.md para o modelo de ameaças.
Instalação
git clone https://github.com/andrelopes-code/ado-mcp-server.git ~/dev/ado-mcp-server
cd ~/dev/ado-mcp-server
npm install
cp .env.example .env
# edite o .env (ver abaixo)Requer Node 20 ou superior.
Related MCP server: tfs-mcp-server
PAT de privilégio mínimo (obrigatório)
No Azure DevOps: User settings → Personal access tokens → New Token. Escopos:
Work Items — Read & Write
Code — Read & Write
Pull Request Threads — Read & Write
Nunca marque Full access nem escopos Manage. Use expiração curta. Cole em DEVOPS_PAT no .env.
.env
Var | Papel |
| base da coleção, ex. |
| projeto padrão de toda tool |
| o PAT mínimo acima |
| versão da REST API do DevOps on-prem (default |
|
|
| outros projetos alcançáveis pelo parâmetro |
| tipos que |
| area paths onde a escrita de work item é permitida, por prefixo (vazio = todo o projeto) |
| limite de tamanho por anexo em |
| extensões de anexo permitidas (vazio = todas) |
| repos permitidos, separados por vírgula (vazio = todos) |
| branches sob sinalização reforçada em |
| caminho da trilha de auditoria (relativo = a partir do diretório do server; default |
| timeout das chamadas HTTP em ms (default |
Registrar no Claude Code (user scope)
claude mcp add --scope user ado -- node ~/dev/ado-mcp-server/src/index.jsVerifique: claude mcp list deve mostrar ado.
Segurança — como não destruir o DevOps
Read-only por padrão. Mutações só com
ADO_MODE=writeno.env(fora do alcance do Claude).Preview → confirm. Toda escrita retorna um preview e só executa com
confirm: true. Emwit_create,wit_updateewit_linko preview é validado pelo próprio ADO (validateOnly=true): regra de processo violada aparece antes do confirm, sem persistir nada.Nada destrutivo existe. Sem delete/abandon/merge. O merge de PR é sempre manual no web UI.
Blast radius. Um projeto padrão, imposto no servidor em toda leitura de work item e em todo alvo de link; outros projetos só com
ADO_PROJECT_ALLOWLIST. Allowlists opcionais de repo, tipo de work item, area path e extensão de anexo.Concorrência.
expectedRevemite umtest /rev: se o card mudou entre a leitura e a escrita, o patch inteiro falha em vez de sobrescrever.Auditoria. Toda tentativa de escrita — aplicada, bloqueada ou falhada — vai para
ado-mcp-audit.log, que rotaciona ao passar de 5 MB.
Modo de escrita e permissões (recomendado)
O gate de aprovação por-ação numa sessão interativa é o prompt de permissão do próprio Claude Code — ele pergunta antes de cada tool. Postura recomendada:
Deixe
ADO_MODE=writefixo (sem editar arquivo no dia a dia).Não marque "don't ask again" nas tools de escrita (
wit_create/update/link/unlink/comment/attach,pr_create/update/add_reviewers/comment) — deixe-as perguntando. As de leitura pode liberar à vontade.Assim cada escrita para 2×: o preview do server + o seu "Yes" no Claude Code. Nada é enviado sem sua aprovação.
ADO_MODE=read é o backstop para sessões autônomas / auto-aprovadas (sem humano no loop). Como o modo é relido ao vivo do .env, virar para read antes de um run desatendido vale na próxima chamada, sem reiniciar.
Uso pelo Claude
Leitura (sempre): wit_query, wit_get, wit_tree, wit_comments, wit_history, wit_meta, pr_list, pr_get, repo_list, branch_list, commit_list, project_list.
Escrita (write + confirm): wit_create, wit_update, wit_link, wit_unlink, wit_comment, wit_attach, pr_create, pr_update, pr_add_reviewers, pr_comment.
Work items
Tool | Para quê |
| WIQL, preset ( |
| detalha ids com os campos pedidos ( |
| WIQL |
| discussão com autor e data (API de comments; cai para |
| revisões campo a campo, com valor anterior e novo |
|
|
| cria qualquer tipo com campos, tags, área, iteração, pai e links |
| campos, estado e tags de um id ou de um lote ( |
| hierarquia, |
| publica na discussão |
| sobe um arquivo local e o anexa ao card |
wit_meta é o caminho para descobrir tipos, estados e campos válidos antes de escrever — o processo do projeto define quais existem.
Pull requests
pr_update edita título, descrição, rascunho e branch de destino. Status fica de fora de propósito: o mesmo PATCH da API aceita abandoned (fecha) e completed (mergeia), e nenhum dos dois deve ser alcançável por uma tool de edição.
Reviewers em
pr_create/pr_add_reviewersusam ids (GUID) de identidade, não nomes.
Trocar de projeto sem subir outro server
Toda tool aceita project opcional. Sem ele vale DEVOPS_PROJECT. Qualquer outro nome precisa estar em ADO_PROJECT_ALLOWLIST (* libera a coleção inteira), senão a chamada falha antes de qualquer request. project_list mostra os projetos da coleção e quais estão liberados. O projeto efetivo entra no preview e na linha de auditoria de toda escrita.
Fluxo típico de escrita: o Claude chama a tool sem confirm → você lê o preview → ele repete com confirm: true.
Desenvolvimento
npm test # vitest
npm run lint # eslintdocs/PLAN.md guarda o plano de construção original.
Uma nota para quem for mexer nas dependências: stdout é o canal do protocolo MCP stdio. Qualquer biblioteca que escreva em stdout no import corrompe o transporte — é por isso que o dotenv é carregado com quiet: true. Use console.error para qualquer diagnóstico.
Licença
MIT — ver LICENSE.
Available Tools
22 toolsbranch_listB
Lista branches de um repo. Leitura.
Inputs: repo (required), filter, project.
commit_listA
Lista commits recentes de um repo/branch. Leitura.
Inputs: repo (required), top, branch, project.
pr_add_reviewersB
Adiciona reviewers a um PR. Escrita: write + confirm.
Inputs: prId (required), repo (required), reviewers (required), confirm, +1 more.
pr_commentB
Comenta num PR (abre thread). Escrita: write + confirm.
Inputs: prId (required), repo (required), text (required), confirm, +1 more.
pr_createA
Cria um pull request (NÃO faz merge). Escrita: write + confirm.
Inputs: repo (required), title (required), source (required), target (required), +6 more.
pr_getB
Detalha um pull request. Leitura.
Inputs: prId (required), repo (required), project.
pr_listB
Lista pull requests de um repo. Leitura.
Inputs: repo (required), status, target, project, +1 more.
project_listA
Lista os projetos da coleção e marca quais podem ser usados no parâmetro project das demais tools. Leitura.
Inputs: no named parameters.
pr_updateA
Edita título, descrição, rascunho ou branch de destino de um PR. NÃO altera status: abandonar e mergear não passam por aqui. Escrita: write + confirm.
Inputs: prId (required), repo (required), title, target, +4 more.
repo_listA
Lista repositórios do projeto. Leitura.
Inputs: project.
wit_attachB
Anexa um arquivo local ao work item (upload + relação AttachedFile). Escrita: write + confirm.
Inputs: id (required), filePath (required), comment, confirm, +1 more.
wit_commentA
Publica comentário na discussão do work item (API de comments, com fallback para System.History). Escrita: write + confirm.
Inputs: id (required), text (required), confirm, project.
wit_commentsB
Lê a discussão de um work item (autor, data, texto). Leitura.
Inputs: id (required), top, project.
wit_createA
Cria work item (epic, feature, PBI, task, bug...) com campos, tags, área, iteração, pai e links. Escrita: exige ADO_MODE=write e confirm:true.
Inputs: type (required), title (required), tags, fields, +6 more.
wit_getA
Detalha work items por id, com campos e relações opcionais. Leitura.
Inputs: ids (required), asOf, expand, fields, +1 more.
wit_historyC
Lê o histórico de revisões de um work item, campo a campo. Leitura.
Inputs: id (required), top, project.
wit_linkA
Cria link em um work item: hierarquia, relacionado, dependência, duplicado, hyperlink ou artefato de código (PR, commit, branch). Escrita: write + confirm.
Inputs: id (required), rel (required), url, repo, +6 more.
wit_metaA
Metadados do processo: types | states | fields | categories | relationtypes | areas | iterations | tags. Use antes de criar/atualizar para descobrir tipos, estados e campos válidos. Leitura.
Inputs: kind (required), type, depth, project.
wit_queryA
Busca work items via WIQL, preset (my_active | my_recent) ou query salva. Leitura.
Inputs: top, wiql, expand, fields, +3 more.
wit_treeA
Executa WIQL de hierarquia (FROM WorkItemLinks) e devolve a árvore epic → feature → item. Leitura.
Inputs: wiql (required), top, fields, project.
wit_unlinkB
Remove um link de um work item, resolvendo o índice da relação no momento da escrita. Escrita: write + confirm.
Inputs: id (required), rel (required), url, confirm, +3 more.
wit_updateB
Atualiza campos, estado e tags de um ou mais work items. Escrita: write + confirm.
Inputs: id, ids, tags, state, +4 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 22 tools
Tools are clearly grouped by domain prefix (wit_, pr_, repo_, branch_, commit_, project_) and each maps to a distinct resource or action. The only mild ambiguity is wit_comments (read) vs wit_comment (write), but their descriptions clearly separate discussion reading from comment posting.
The snake_case domain-prefixed naming is consistent and predictable overall, but verb placement varies: reads use both generic verbs (wit_get, pr_get) and resource nouns (wit_comments, wit_history, repo_list). This is a minor deviation rather than a chaotic mix.
At 22 tools, the server sits in the heavy 16-25 band, though the count is partially justified by covering work items, PRs, repos, branches, commits, and projects. Each tool appears non-redundant, so the set is broad rather than bloated.
Work item coverage is strong: query, get, tree, comments, history, meta, create, update, link/unlink, comment, and attach are all present. However, the PR lifecycle has a notable gap: pr_update explicitly cannot change status and there is no merge or abandon tool, leaving PRs incomplete after creation.
Maintenance
Related MCP Connectors
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Connect Claude to your Platform7n workspaces: chat, links, work and decks. One-click OAuth.
Connect Claude to your Platform7n workspaces: chat, links, work and decks. One-click OAuth.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Related MCP Servers
- FlicenseAqualityDmaintenanceBridges Claude Code with an on-premise Azure DevOps Server / TFS collection, enabling work item and Git operations via PAT authentication.121-
- FlicenseAqualityCmaintenanceConnects Claude to on-premise TFS (Team Foundation Server) via REST API, enabling read/write of work items, backlogs, sprints, and pull requests without manual copy-paste.8-
- FlicenseBqualityCmaintenanceEnables users to securely connect Claude Desktop to Azure DevOps for managing work items, metadata, comments, pull requests, and code reviews.15-
- AlicenseAqualityCmaintenanceEnables AI assistants to interact with an on-premise Azure DevOps Server 2022, allowing users to list, view, create, and update work items through natural language.4MIT