Give your AI assistant the context that lives outside the code
Requirements, pull requests, build failures and wiki pages live in Azure DevOps, not in your editor. MCP servers connect GitHub Copilot and Claude Code to those systems, so the assistant works from real, current information — with your permissions, and read-only by default.
The assistant only knows what you paste into it
Developers jump between the editor, Azure Boards, pull requests, pipeline logs and the wiki to gather what the assistant needs.
The pasted work item misses its acceptance criteria, linked bugs and comments. The assistant fills the gaps with guesses.
Build logs, test results and review threads change quickly. A copied snapshot is out of date by the time it is used.
A connector the assistant can use when it needs data
MCP (Model Context Protocol) is the open standard for connecting AI assistants to tools and data. The Azure DevOps server is hosted by Microsoft and uses your normal work sign-in.
- 1You ask in plain language
"Why did last night's build fail?" or "Summarise work item 4521 and its acceptance criteria."
- 2The assistant calls Azure DevOps
It reads the build log, work item, pull request or wiki page it needs — with your permissions, nothing more.
- 3It answers from real data
The answer is grounded in current information, and agents can use the same connector in their workflows.
What teams get
Ask for the work item, PR comments or failing test from the editor instead of opening four browser tabs.
Acceptance criteria, linked items and comments come straight from Azure Boards, so implementations match what was asked.
The assistant reads build logs and test results directly and explains the failure next to the code.
Plans, reviews and release notes reference real work item and pull request IDs.
Runs with your own Azure DevOps permissions and Microsoft Entra sign-in. The catalog config is read-only unless a team opts in to writes.
ADO Planner, Story Writer, Code Reviewer and Release Notes all use the same connector — set it up once.
Choose which areas are available (work items, repos, pipelines, wiki, test plans) so the assistant only sees what the team needs.
Hosted server for Copilot in VS Code and Visual Studio; local server for Claude Code — same tools, same server name.
Same question, with and without the connector
Prompt: Why did last night's build fail, and which change caused it?
Without
- You open Azure Pipelines and find the failed run
- You copy part of the log into chat
- The assistant guesses without seeing the full log or the changes
- You look up the commits and linked work items yourself
- Fifteen browser clicks later you have a theory
With the Azure DevOps MCP server
- The assistant finds the failed run and reads its log
- It lists the commits and work items in that build
- It points to the change that most likely caused the failure
- It explains the fix next to the code in your editor
- Everything stays read-only
Illustrative example. What the assistant can see depends on the configured toolsets and your permissions.
Safe to roll out
The server acts as you. It cannot see or change anything you could not see or change in Azure DevOps yourself.
The catalog config blocks all writes. Teams that want the assistant to create work items or comment on PRs opt in explicitly, and the assistant still asks before each change.
Only work items, repos, pipelines, wiki and test plans are enabled. Remove what a team does not need.
Content the assistant reads (for example a work item description) is sent to the AI model as context, like anything you paste into chat. Apply your organisation's rules on what data may be used with AI tools.
How to show it's working
Measure a baseline before rollout, then compare after a few sprints. These are the signals that move first — track them per team, not per person.
| Measure | Why it matters |
|---|---|
| Time to diagnose a failed build | The assistant reads logs and changes directly instead of waiting for copy-paste. |
| Rework caused by missed requirements | Acceptance criteria are read from the source, not from memory. |
| Tool switches per task | Ask developers in a short survey before and after rollout. |
| Teams with the connector configured | Adoption comes before impact — track it per team. |
Useful at every level of the team
Work items, PRs and build logs available from the editor, in plain language.
Test plans, cases and results summarised alongside the code under test.
Faster triage of failed builds and PR threads across the team.
Backlog and iteration questions answered without building queries.
Pick the mcp servers your team needs
Each item in the catalog has copy buttons and install steps for GitHub Copilot and Claude Code.