Your delivery board, readable by an agent

Why start here

If you are introducing Model Context Protocol into an enterprise estate, do not start with the finance system. Start with something where the blast radius is small, the data is familiar, and the value is obvious within a minute of connecting.

Azure DevOps is that place. Every delivery leader already lives in it, the permissions model is well understood, and the questions you want to ask an agent — what is in flight, what is blocked, what changed in this repository — are questions you ask a human colleague several times a day.

The point of the first server is not the data. It is learning what changes when the agent can read the system directly instead of you pasting screenshots into a chat window.

What it is

That last row is the one worth pausing on. The historical way to automate against Azure DevOps was a Personal Access Token: a long-lived secret, pasted into a config file or an environment variable, valid until someone remembers to rotate it, and carrying whatever scope was convenient at the time it was minted.

This server does not use one. It signs you in through the browser, as you, and the resulting token lives in the operating system's credential store. If your access changes, the agent's access changes with it — on the next token refresh, not on the next audit.

Standing it up

Two prerequisites: Node.js, and access to the organisation. Then a single configuration file in whatever folder you want the server available in:

{
  "mcpServers": {
    "ado": {
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "Faisal Fareed"]
    }
  }
}

The final argument is the organisation name, not a URL — a small detail that costs people ten minutes the first time.

Start your MCP client in that folder, approve the server when prompted, and the browser sign-in happens on first use. That is the entire setup — with two caveats that cost us time on a clean machine.

The first: a project-scoped server starts in a pending approval state, and approving it has to happen in an interactive session. A health check run from a script will keep reporting the server as unapproved however many times you run it.

The second is subtler and looks alarming. The server connected, then started failing with a thirty-second connection timeout. The cause was npx downloading the package on first launch and not finishing inside the client's startup window. Fetching the package once, ahead of time, so it already sits in the local npm cache, resolved it permanently.

What it changes day to day

The shift is subtle and it took us a week to notice properly. It is not that the agent can query the board — a REST call could always do that. It is that the agent can join the board to everything else it knows.

• "Summarise what moved in this sprint and which items reference the invoicing module."
• "This pipeline failed. What changed in the repository since the last green run?"
• "Which work items are blocked, and who owns the dependency?"

None of those are hard queries. All of them were previously somebody's Tuesday morning, spent assembling context by hand from three browser tabs.

The governance point

Delegated identity means the agent operates as the signed-in person, bounded by that person's existing Azure DevOps project and repository permissions. There is no service account. Nothing is elevated. A user who cannot see a private repository does not gain visibility of it by asking an agent nicely.

This matters more than it sounds, because it is the property that makes the rest of the estate — Dataverse, Finance and Operations — defensible to a security review. Establish it on the low-risk server first, then carry the same model forward.

Sources

• Microsoft — Azure DevOps MCP Server: https://github.com/microsoft/azure-devops-mcp
• npm package: https://www.npmjs.com/package/@azure-devops/mcp