Watch this video on YouTube (opens in a new tab)

I had this crazy idea. What if I could just ask my AI assistant — Claude, Copilot, whatever — a question like "how's the project going?" and actually get a useful answer? Not a hallucinated guess. A real answer, based on real data, from my actual Azure DevOps project.

So I built it. It's an MCP server that ships as part of azdoutil, my open-source Azure DevOps command-line tool. And it's not a data pipe. It's a coach.

What's MCP?

MCP stands for Model Context Protocol. Think of it as a USB cable for your AI assistant. One end plugs into the AI (Claude, Copilot, Cursor, whatever you're using). The other end plugs into an external tool. Once they're connected, the AI can ask questions and get real answers back from your actual data.

An MCP server is the thing on the other end of that cable. It knows how to talk to your specific tool — in this case, Azure DevOps — and translates between what the AI is asking and what the API can provide. You ask a question in plain English. The MCP server goes and gets the answer.

The word "server" tripped me up at first. I kept thinking of some app running on hardware somewhere. In practice, what I built is essentially a CLI wrapper. You run azdoutil mcp-server, it communicates over stdio, and your AI assistant talks to it. No deployment. No infrastructure. Just a dotnet global tool.

"But Microsoft Already Built One"

Yeah, they did. And it's good. Microsoft's MCP server for Azure DevOps has over 80 tools with full read and write access to your work items, repos, pull requests, pipelines, and wikis. Pretty much the whole API surface is covered. You can create work items, update fields, close items — all through your AI assistant.

It's a data pipe. A really good data pipe. You ask for data, it gives you data. You ask to change data, it changes data. And that's exactly what it should be. Microsoft's job is to expose the platform, and that's what they did.

But there's a gap between having access to your data and actually understanding what your data is trying to tell you.

Read / write ≠ opinionated / insightful.

Can Your AI Answer These?

Try asking your AI assistant these questions right now:

• How long does stuff typically take around here?
• What's been sitting in progress for too long?
• When will we actually be done with these 15 items?
• Is this project in trouble?

Those aren't exotic questions. Those are the questions a team lead asks every single week. But a data pipe can't answer them — because answering them requires analysis. And analysis requires opinions about what the numbers actually mean.

What a Coach Actually Does

A coach doesn't have secret data. They're looking at the same board you're looking at. Same backlog. Same sprint. Same history.

But they ask fundamentally different questions. Where a data tool lists the items in your sprint, a coach asks how long that one item has been sitting there. Where a data tool tells you seven items finished last week, a coach asks whether that number is going up or going down.

And then they tell you what they see — with an opinion attached. Not "here's a number," but "hey, you've got 3 items that have been in progress longer than your typical delivery window, and that's a red flag."

That's coaching. That's what I built.

The Coaching Questions

Here's the part you probably came for. These are the delivery intelligence tools, framed as the questions they answer. Because that's how you'll actually use them — you'll just ask your AI a question in plain English, and the MCP server will go figure out the answer.

"How long does stuff typically take?"

Tool: get_typical_delivery_window

This gives you cycle time percentiles — your 50th, 85th, and 95th. So instead of saying "I think it takes about a week," you can say "85% of our work finishes in 12 days or less." That's not a guess. That's your actual historical data talking.

This is the foundational delivery intelligence question. If you can't answer this one, you can't meaningfully answer any of the others.

"Are we getting things done?"

Tool: get_throughput

Throughput analysis: how many items are crossing the finish line per week? And more importantly, is that number trending up or trending down? Because if it's been dropping for six weeks in a row, that's not a blip — that's a pattern worth investigating.

This isn't "are people busy." This is "are things finishing." There's a massive difference between activity and completion.

"When will these N items be done?"

Tool: forecast_completion_date

This is the one everybody wants. You give it a count of items and it runs thousands of Monte Carlo simulations using your actual throughput history. It gives you forecasted week counts at different confidence levels — 50%, 85%, 95%.

Not a promise. A probability. And that's a fundamentally different conversation to have with your stakeholders than "I think it'll be done by March."

"How much can we get done in N weeks?"

Tool: forecast_items_in_timeframe

The reverse of the previous question. You've got a deadline. You've got four weeks. How many items can you realistically expect to finish? Same Monte Carlo simulation, same confidence levels, different input.

Useful when someone says "we have six weeks until the release" and you need to figure out what's actually going to make it.

"What's stuck right now?"

Tool: get_aging_work

This one looks at everything currently in progress and flags items that have been there longer than your typical delivery window. These are the items most likely to blow up, and most teams don't notice them until it's too late.

If you've read The Priority Doom Loop, you know that high WIP is the enemy. Aging work detection is how you find the items that are silently becoming expensive.

"How's the project overall?"

Tool: get_project_summary

Think of this as a one-page diagnostic that rolls up throughput, delivery window, and aging work into a single picture. You just ask your AI "how's my project doing?" and it tells you.

This is the one I use the most. It's the coaching equivalent of "give me the headline before I ask my follow-up questions."

Getting Oriented: Context and Discovery Tools

Before the AI can coach you, it needs to figure out where it is. That's what the context and discovery tools are for. These are all read-only, and they help the AI navigate your Azure DevOps instance so it can call the right coaching tools with the right parameters.

"What projects and teams exist?"

• list_team_projects — What projects are in the org?
• get_project_info — Details for a specific project (ID, URL, state, process template).
• list_teams — What teams are in a project? (You need the exact team name for team-scoped flow metrics.)

"What kind of work are we tracking?"

• get_work_item_types — What work item types exist in a project? (PBI, Bug, Task, etc.)
• get_work_item_type_states — What are the workflow states for a work item type? (New → Active → Done, etc.)
• list_process_templates — What process templates are available? (Scrum, Agile, Basic, inherited, etc.)

"What queries and repos do we have?"

• list_work_item_queries — What saved queries exist in the project?
• run_work_item_query — Run a saved query and return the results. If you've already got a query for "all active bugs in Sprint 14," the AI can just run it.
• list_git_repositories — What Git repos are in this project?
• analyze_repository — Build-readiness analysis of a repo: languages, target frameworks, solution structure, project references. Useful if you're doing migrations or modernization work. (And it does this without cloning the repo.)

"What Azure DevOps connection am I using?"

• list_configurations — What Azure DevOps connections does azdoutil know about? (Never returns tokens.)

That's 18 tools total. Seven for delivery intelligence and coaching. Ten for context and discovery. Plus one more.

The CLI Escape Hatch

Tool: discover_cli_commands

azdoutil has a lot of commands beyond what's exposed through the MCP server. TFVC-to-Git migrations, build definition management, process template administration, test data generation — a whole CLI full of stuff that the MCP surface doesn't cover (yet).

Rather than try to expose everything as an MCP tool, the server has a discovery tool that searches the full CLI command catalog. When you ask for an Azure DevOps task that doesn't have a dedicated MCP tool, the AI can use this to tell you the exact azdoutil command to run from the command line. It knows which commands are already exposed as MCP tools, so it won't send you to the CLI unnecessarily.

Nothing gets executed. It just describes the commands and gives you the command-line syntax. Think of it as the AI knowing how to read the help docs for you.

Data vs. Coach: The Same Data, Two Different Conversations

Let me put it as simply as I can. Here's the difference between a data pipe and a coach, looking at the exact same data:

A data pipe tells you:

• Work item 4527 has been active for 14 days.
• Your team completed 7 items last week.
• You have 23 items in the backlog.

All true. All accurate. All useful as far as they go.

A coach tells you:

• That item has been in progress longer than 85% of your historical work. Someone should go check on it before it gets worse.
• Your throughput has been trending down for 6 weeks. Seven items last week, but it was 10 six weeks ago. That's not noise — that's a pattern worth investigating.
• At your current throughput, those 23 items finish by mid-October at 85% confidence. Not a promise — a forecast you can actually have a conversation about with your stakeholders.

Same data. Completely different conversation. And that's what "opinionated" means.

Why These Opinions Aren't Microsoft's Job

Everything I just described requires opinions. What does "typical" mean? What counts as "stuck"? How many simulations should you run? What percentile matters for forecasting?

Microsoft isn't going to ship those opinions. And honestly, they shouldn't. Their job is to build a great platform. My job — as someone who does project delivery consulting — is to have opinions about what your data means. I want you to know when you're on track for delivery and when you're getting into trouble.

That's what this tool does.

Getting Started

Getting set up is straightforward:

Install azdoutil as a .NET global tool:

dotnet tool install azdoutil -g

Configure your Azure DevOps connection:

azdoutil addconfig /url:{your-azdo-url} /pat:{your-pat}

Add it as an MCP server in your AI assistant. The easiest way is to let azdoutil do it for you:

azdoutil mcp-config /install

That registers the server with Claude Code at user scope. For Claude Desktop, VS Code (Copilot), Visual Studio 2022/2026, or Cursor, run azdoutil mcp-config (without /install) and it'll print the config snippets you need for each client.

Start asking delivery questions. Just talk to it like you'd talk to a coach:

• "How long do work items usually take in ProjectX?"
• "What's stuck in ProjectX right now?"
• "When will these 12 items be done?"
• "How's the project going overall?"

The AI maps your questions to the right tools automatically. If you want to be explicit, you can name the tool directly: "Use the azdoutil get_project_summary tool for ProjectX."

Full setup details — including per-client configuration examples for Claude Code, Claude Desktop, VS Code, Visual Studio, and Cursor — are in the GitHub repo README.

Honest Cheetah

One shameless plug before I wrap up. If you like the idea of delivery intelligence but you want a full dashboard instead of a command-line interface or an AI chat, check out Honest Cheetah. Same philosophy — delivery questions answered with opinions — but with persistent dashboards, trend tracking, and team-level views. It works with Azure DevOps and GitHub. And it's free.

Quick Reference: All 18 MCP Tools

Delivery Intelligence (Coaching)

Context and Discovery

CLI Fallback

-Ben

If your organization's delivery feels stuck — priorities thrashing, nothing finishing, no idea when anything will land — that's the kind of problem I help teams diagnose and fix. The MCP server is the free tool. The conversation is what changes things.