Azure DevOps | The .NET Blog

Azure DevOps MCP Server April Update: WIQL Queries, PAT Auth, and Experimental MCP Apps

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

The Azure DevOps MCP Server keeps getting better. Dan Hellem’s April update covers both the local and remote servers, and there are some genuinely useful additions here — especially if you’ve been using Copilot to navigate boards and repos.

WIQL Query Support

The headline feature: a new wit_query_by_wiql tool that lets you run Work Item Query Language queries directly from your MCP client.

If you’ve used Azure Boards for any length of time, you know WIQL. It’s the SQL-like query syntax for work items: SELECT [System.Id], [System.Title] FROM WorkItems WHERE [System.AssignedTo] = @Me AND [System.State] = 'Active'. Having that available as an MCP tool means your Copilot sessions can now pull precise work item sets without you manually filtering or clicking through board views.

One caveat: on the remote MCP Server, this tool currently requires the Insiders feature flag while they validate query performance at scale. It’ll come to everyone once the telemetry looks good.

Personal Access Tokens on the Local Server

The local MCP Server now supports PAT authentication. This sounds like a minor quality-of-life fix, but it’s actually important for integration scenarios — specifically when you’re running the MCP server in a context where interactive authentication isn’t available, or when you’re connecting from external clients and automation.

Setup is documented in the Getting Started guide.

MCP Annotations on the Remote Server

Annotations are metadata tags on MCP tools that tell LLMs how to use them safely. The Azure DevOps MCP Server is now implementing annotations for:

Read-only tools — the LLM knows these are safe to call without user confirmation
Destructive tools — the LLM knows to be cautious and confirm before proceeding
Open-world tools — the LLM understands these may return unpredictable results

This is foundational for agent reliability. Without annotations, the LLM has to guess from the tool name whether it’s safe to call. With annotations, the behavior is explicit and the agent can make better decisions.

Wiki Tool Consolidation

The remote server is starting to consolidate related tools into fewer, more capable ones. The wiki tools are the first to get this treatment:

New Tool	Replaces
`wiki` (read-only)	`wiki_get_page`, `wiki_get_page_content`, `wiki_list_pages`, `wiki_list_wikis`, `wiki_get_wiki`
`wiki_upsert_page`	`wiki_create_or_update_page`

Fewer tools = better LLM performance. This is a consistent pattern across MCP server design — smaller, focused tool sets work better because the LLM doesn’t have to reason about which of five similarly-named tools to pick.

Experimental: MCP Apps

This is the most interesting addition, and it’s clearly experimental. MCP Apps are packaged workflows that run inside the MCP server environment:

{
 "servers": {
 "ado": {
 "type": "stdio",
 "command": "mcp-server-azuredevops",
 "args": ["contoso", "-d", "core", "work", "work-items", "mcp-apps"]
 }
 }
}

The first example is mcp_app_my_work_item — a self-contained work item experience that lets you view, filter, and edit work items assigned to you, without manually chaining multiple tool calls.

The idea is compelling: instead of your agent calling wit_get_work_item → wit_list_work_items → wit_update_work_item across multiple turns, a single MCP App provides the entire workflow as one structured, reusable unit. Reduced setup time, consistent behavior, fewer moving parts.

It’s on the mcp-apps-poc branch right now, which tells you where it stands in terms of production readiness. But the direction is right — more workflow composition at the MCP layer, less ad-hoc tool chaining in your agent prompts.

Wrapping up

The Azure DevOps MCP Server is maturing quickly. WIQL support and PAT auth are immediate wins for anyone using Copilot with Azure Boards. The annotation work makes the remote server safer for agentic use cases. And MCP Apps, while experimental, hints at where this is going: from raw tools to composable workflows.

Worth keeping an eye on the documentation as the remote server continues to evolve.

Original post by Dan Hellem: Azure DevOps MCP Server April Update.

Azure DevOps Server April 2026 Patch — PR Completion Fix and Security Updates

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Quick heads-up for teams running self-hosted Azure DevOps Server: Microsoft released Patch 3 for April 2026 with three targeted fixes.

What’s fixed

Pull request completion failures — a null reference exception during work item auto-completion could cause PR merges to fail. If you’ve hit random PR completion errors, this is likely the cause
Sign-out redirect validation — improved validation during sign-out to prevent potential malicious redirects. This is a security fix worth applying promptly
GitHub Enterprise Server PAT connections — creating Personal Access Token connections to GitHub Enterprise Server was broken, now it’s restored

How to update

Download Patch 3 and run the installer. To verify the patch is applied:

<patch-installer>.exe CheckInstall

If you’re running Azure DevOps Server on-premises, Microsoft strongly recommends staying on the latest patch for both security and reliability. Check the release notes for full details.

Azure DevOps Finally Fixes the Markdown Editor UX Everyone Complained About

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

If you use Azure Boards, you’ve probably experienced this: you’re reading through a work item description, maybe reviewing acceptance criteria, and you accidentally double-click. Boom — you’re in edit mode. You didn’t want to edit anything. You were just reading.

Dan Hellem announced the fix, and it’s one of those changes that sounds tiny but actually removes real friction from your daily workflow.

What changed

The Markdown editor for work item text fields now opens in preview mode by default. You can read and interact with the content — follow links, review formatting — without worrying about accidentally entering edit mode.

When you actually want to edit, you click the edit icon at the top of the field. When you’re done, you exit back to preview mode explicitly. Simple, intentional, predictable.

That’s it. That’s the change.

Why this matters more than it sounds

The community feedback thread on this was long. The double-click-to-edit behavior was introduced with the Markdown editor back in July 2025, and the complaints started almost immediately. The problem wasn’t just accidental edits — it was that the whole interaction felt unpredictable. You never knew if clicking would read or edit.

For teams that do sprint planning, backlog grooming, or code review with Azure Boards, this kind of micro-friction compounds. Every accidental edit mode entry is a context switch. Every “wait, did I change something?” moment is wasted attention.

The new default respects the most common interaction pattern: you read work items far more often than you edit them.

Rollout status

This is already rolling out to a subset of customers and expanding to everyone over the next two to three weeks. If you’re not seeing it yet, you will soon.

Wrapping up

Not every improvement needs to be a headline feature. Sometimes the best update is just removing something annoying. This is one of those — a small UX fix that makes Azure Boards feel less hostile to people who just want to read their work items in peace.