Remote Azure DevOps MCP Server: connect Copilot to your pipelines without installing anything

The Azure DevOps MCP Server is the bridge that gives AI agents (Copilot Chat, Copilot CLI, Cursor, and the like) access to your projects, pipelines, repos, and work items via Model Context Protocol. The change that reshapes the setup: Microsoft now recommends the hosted remote server instead of the local Node.js server. Less running on your machine, and according to the repository itself, new features land on the remote one first.

I migrated my local setup to the remote one this week. Here's the full path, stumbles included.

Why remote beats local

The local server (@azure-devops/mcp via npx) has always worked well, but it has two costs: you keep Node.js 20+ on the machine, and you need to set up authentication on a per-client basis. The official local config example uses --authentication azcli (the az cli credential), and the README also mentions interactive login with a Microsoft account. In other words, it's one more piece to maintain and one more step that can go wrong.

The remote server shortens all that. The endpoint is hosted by Microsoft at https://mcp.dev.azure.com/{organization}, and you install nothing: point the client at the URL and you're done. The README is explicit: "We recommend using the Remote MCP Server instead of this local server. It requires no installation and gets new features first." Microsoft itself notes that the local server remains supported, but new development is focused on the remote one, and that local users should start planning their migration.

The honest trade-off: you now depend on an external Microsoft service and on your client's support for remote MCP servers over HTTP. That's where the catch I explain at the end lives.

Setup: the mcp.json file

The remote setup is dramatically shorter than the local one. Create .vscode/mcp.json at the project root:

{
  "servers": {
    "ado-remote-mcp": {
      "url": "https://mcp.dev.azure.com/{organization}",
      "type": "http"
    }
  },
  "inputs": []
}

Replace {organization} with your Azure DevOps organization name (the same one that shows up in dev.azure.com/yourorg). It's not the full URL, just the org slug.

Save the file. In VS Code, open the MCP view (the MCP servers panel) and hit start on ado-remote-mcp. After that, per the README's guide, you just run a prompt. The full onboarding flow documentation and extra configuration options are in the Remote MCP Server onboarding documentation and the remote server configuration documentation linked in the repository.

To confirm it's up, send the classic prompt in Copilot Chat:

List ADO projects

If it returns your list of projects, the pipe is up. In my case, this was where I had to confirm that the account I was using in VS Code was the same one with access to the organization, otherwise the list comes back empty with no clear error.

What you can automate today

After the first List ADO projects, I tested what actually matters in the day-to-day of whoever handles delivery. The tools cover the main domains, and you talk to them in natural language. Prompts that the README itself lists as examples, and that I ran:

• Pipelines/builds: List ADO Builds for 'Contoso' to see the history and status of the latest runs.
• Repos: List ADO Repos for 'Contoso' and browse branches and PRs.
• Work items: List my work items for project 'Contoso' and the most useful one during sprint ceremonies, List work items in current iteration for 'Contoso' project and 'Contoso Team'.
• Test plans: List test plans for 'Contoso'.
• Iterations and teams: List iterations for project 'Contoso' and List teams for project 'Contoso'.
• Wiki: besides reading (Get the content of the wiki page '/API/Authentication'), you can create and update pages, like Create a wiki page '/Architecture/Overview' with content about system design. This is what saved me the most time: generating documentation from the repo's context without leaving the editor.

The design is deliberately lean: per the README, each tool is a thin layer over the Azure DevOps REST API, and the intelligence to chain actions is left to the agent. In other words, the server doesn't do magic; it exposes operations, and Copilot decides the order.

The full list of remote tools is in the project's Available Tools documentation. It's worth checking before promising automation to the team, because parity between remote and local is still a work in progress (the README points to TOOLSET.md for the list of local tools).

Help Copilot pick the right tool

One detail that makes a practical difference: add a .github/copilot-instructions.md file to the project with the instruction Microsoft itself suggests:

This project uses Azure DevOps. Always check whether the Azure DevOps MCP server has a tool relevant to the user's request.

Without it, Copilot sometimes tries to answer from memory instead of calling the tool. With the instruction, tool-selection accuracy went up in my tests.

The catch: not every client gets to remote the same way

Here's the part nobody mentions in the announcement. The remote setup shown above is the one the README describes for VS Code + Copilot. For the other supported clients, the README simply points to another document: "For other supported clients, including Visual Studio 2022, Codex, Claude Code, Cursor, OpenCode, and Kilo Code, see the getting started guide." In other words, those clients have their own instructions, and the README doesn't make clear, at that point, whether the recommended path for them is the remote server or the local one over stdio.

The practical takeaway: before standardizing the migration across the team, check the getting started guide to see how each client you use connects, because the VS Code path isn't necessarily the same as the others.

When I need the local server, the config switches to stdio and asks for the org as input again:

{
  "inputs": [
    {
      "id": "ado_org",
      "type": "promptString",
      "description": "Azure DevOps organization name (e.g. 'contoso')"
    }
  ],
  "servers": {
    "ado": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "${input:ado_org}"]
    }
  }
}

In the local server, two adjustments are worth gold. First, domains: the local server loads all tools by default, which blows past the tool limit of some clients. Use -d to load only what you need (available domains, per the README: core, work, work-items, search, test-plans, repositories, wiki, pipelines, advanced-security):

"args": ["-y", "@azure-devops/mcp", "${input:ado_org}", "-d", "core", "work", "work-items"]

Always include core, otherwise the agent can't even retrieve project information. Second, project and team defaults via environment variables, so the agent stops asking every time:

"env": {
  "ado_mcp_project": "Contoso",
  "ado_mcp_team": "Fabrikam Team"
}

A word about versioning

Microsoft just wrapped up a tool consolidation that renamed existing tools. If you have agents or skills that call specific tool names, this is a breaking change. You can hold off temporarily by pinning the version to @azure-devops/mcp@2.8.1 while you adapt to the new names (the list is in TOOLSET.md). For nightly builds, swap @azure-devops/mcp for @azure-devops/mcp@next in the config.

Verdict for Brazilian teams

If you're on VS Code with Copilot, migrating to the remote server is worth it: zero installation and new features arrive first, as Microsoft itself states. If your team is spread across Cursor, Claude Code, and the like, read the getting started guide for each client before promising the same flow to everyone, and keep the local server with filtered domains where it's still needed. What remains open is full tool parity between the two modes. Until then, measuring which of the two configs your team actually uses is what decides the migration.