Developer Productivity | 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.

Aspire 13.2 Gets Bun, Better Containers, and Less Debugging Friction

Emiliano Montesdeoca — Fri, 24 Apr 2026 00:00:00 +0000

If you’ve been building .NET backends with JavaScript frontends in Aspire, 13.2 is the kind of update that quietly makes your day better. No splashy new paradigms. Just solid improvements to things that were mildly annoying.

Let’s walk through what actually landed.

Bun is Now a First-Class Citizen

The headline feature: Bun support for Vite apps in Aspire. One fluent call, done.

// TypeScript AppHost
const builder = await createBuilder();

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

await builder.build().run();

If your team already uses Bun — which you might, given its dramatically faster install times and startup — Aspire no longer makes you fight against the grain. Previously, Aspire assumed npm and you had to work around it. Now .withBun() is a first-class option alongside .withYarn() and the default npm behavior.

Why does this matter? Because JavaScript tooling speed directly affects your inner dev loop. If your frontend takes 30 seconds to install dependencies every time you spin up a fresh environment, that adds up. Bun cuts that dramatically.

The C# AppHost equivalents are documented at aspire.dev if you prefer authoring in C# — all the same patterns apply.

Yarn Got More Reliable

Bun gets the spotlight, but Yarn users get something arguably more impactful: fewer mysterious failures. Aspire 13.2 improves reliability for withYarn() with addViteApp().

These kinds of fixes don’t sound exciting until you’ve spent 20 minutes debugging why your Yarn-backed frontend resource wouldn’t start. Consider it fixed.

Container Publishing You Can Actually Reason About

Two container improvements worth knowing:

Explicit Pull Policy

Docker Compose publishing now supports PullPolicy, including a Never option:

import { createBuilder, ImagePullPolicy } from './.modules/aspire.js';

const builder = await createBuilder();
await builder.addDockerComposeEnvironment("compose");

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

await builder.build().run();

This is the “please use the image I already built and leave the registry out of it” workflow. Super useful when iterating locally on images you’re building and publishing manually, or when your CI produces an image and you want Compose to use exactly that one without sneaking in a remote pull.

PostgreSQL 18+ Volumes Work Again

PostgreSQL 18 changed its internal data directory layout. This broke volume mapping in Aspire silently — your data volume would be set up but persistence wouldn’t actually work correctly. 13.2 fixes this.

const postgres = await builder.addPostgres("postgres")
 .withDataVolume({ isReadOnly: false });

If you’re running PostgreSQL 18 or later with a data volume, upgrade to Aspire 13.2 and don’t think about it again.

Debugging Quality-of-Life Improvements

A few things that make stepping through an AppHost session less frustrating:

DebuggerDisplayAttribute on core types — DistributedApplication, resources, endpoint expressions now show useful values in the debugger instead of requiring you to drill into object trees
Better WaitFor failure messages — when resources fail to start, the error context is actually helpful now
BeforeResourceStartedEvent fires at the right time — only when a resource is actually starting, not on unrelated state transitions
launchSettings.json is more resilient — less chance of a malformed setting corrupting your dev startup

None of these are individually earth-shattering, but collectively they remove friction from the debugging experience. If you’ve ever had to drill three levels deep into an Aspire resource object to figure out what endpoint it was using, the debugger display improvement alone is worth the update.

Wrapping up

Aspire 13.2 is a focused quality release. Bun support is the headline, but the container and debugging improvements are what will make your day-to-day work smoother. Worth updating — especially if you’re on PostgreSQL 18 with data volumes.

Full details in the original post by David Pine and the Aspire 13.2 what’s new docs.

68 Minutes a Day Re-Explaining Code to Copilot? There's a Fix for That

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

You know that moment when your Copilot session hits /compact and the agent completely forgets what you were doing? You spend the next five minutes re-explaining the file structure, the failing test, the three approaches you already tried. Then it happens again. And again.

Desi Villanueva timed it: 68 minutes per day — just on re-orientation. Not writing code. Not reviewing PRs. Just catching the AI up on things it already knew.

Turns out there’s a concrete reason this happens, and a concrete fix.

The Context Window Lie

Your agent ships with a big number on the box. 200K tokens. Sounds massive. In practice it’s a ceiling, not a guarantee.

Here’s the actual math:

200K total context
Minus ~65K for MCP tools loaded at startup (~33%)
Minus ~10K for instruction files like AGENTS.md or copilot-instructions.md

That leaves you with roughly 125K before you type a word. And it gets worse — LLMs don’t degrade gracefully as context fills up. They hit a wall at around 60% capacity. The model starts losing things mentioned 30 turns ago, contradicts earlier responses, hallucinates file names it stated confidently 10 minutes prior. The industry calls this the “lost in the middle” problem.

Effective limit: 45K tokens before quality degrades. That’s maybe 20-30 turns of active conversation before the agent starts drifting. Which is why you’re hitting /compact every 45 minutes — not because you’ve filled 200K tokens, but because the model is already rotting at 120K.

The Compaction Tax

Every /compact costs you flow state. You’re deep in a debugging session. Shared context built up over 30 minutes. The agent knows the file structure, the failing test, the hypothesis. Then the warning hits.

Ignore it → agent gets progressively dumber, hallucinates old state
Run /compact → agent has a 2-paragraph summary of a 30-minute investigation

Either way you lose. Either way you’re narrating your own project back to it like a new hire on day one.

The cruel part? The memory already exists. Copilot CLI writes every session to a local SQLite database at ~/.copilot/session-store.db — every file touched, every turn, every checkpoint. It’s all sitting on disk. The agent just can’t read it.

auto-memory: A Recall Layer, Not a Memory System

That’s the key insight behind auto-memory: don’t build a new memory system — build a read-only query layer over the one that already exists.

pip install auto-memory

~1,900 lines of Python. Zero dependencies. Installs in 30 seconds.

Instead of flooding the context with grep results, you give the agent surgical access to what actually matters:

Operation	Tokens	What you get
`grep -r "auth" src/`	~5,000–10,000	500 results, most irrelevant
`find . -name "*.py"`	~2,000	Every Python file, no context
Agent re-orientation	~2,000	You explaining what it should know
`auto-memory files --json --limit 10`	~50	The 10 files you touched yesterday

That’s a 200x improvement. The agent skips the archaeological dig and goes straight to what matters.

The recommended flow: when you’re approaching 50-70% context usage, run /clear and then prompt with “review last sessions we discussed topic X”. Instead of burning 12K tokens on blind searches, auto-memory pulls the relevant context in 50.

Why This Matters for .NET Developers

If you’re using GitHub Copilot CLI for .NET work — scaffolding services, debugging EF Core queries, iterating on Blazor components — the context rot problem hits just as hard. Complex solutions with multiple projects, shared libraries, and deep call chains are exactly the kind of codebase where the agent loses track fastest.

The install guide walks through pointing Copilot CLI at it. It’s a one-time setup.

Honestly? 68 minutes a day back in your pocket is not a minor quality-of-life tweak. That’s almost 6 hours a week.

Wrapping up

Context rot is a real architectural constraint, not a bug that will get patched. auto-memory works around it by giving your agent a cheap, precise recall mechanism instead of expensive, noisy re-exploration. If you’re doing serious AI-assisted development with GitHub Copilot CLI, it’s worth the 30-second install.

Check it out: auto-memory on GitHub. Original post by Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.