Azure DevOps MCP Server (local)

By default the server signs the user in through Microsoft Entra and asks for a token with the user's full Azure DevOps permissions, then uses that one token for every tool, reads and writes alike. Tokens are short-lived and held in memory, and every request is built against the single organization named on the command line, but nothing narrows what the token itself may do. A personal access token mode lets the operator supply a token with chosen scopes, but the code does not ask for or check any scope, so least privilege depends entirely on manual setup.

The host application, not the server, decides which calls need a human, so this criterion rates the signals the server gives it. Reads and writes are separate tools, every tool carries read-only or destructive hints from one central table, and registration fails if a tool has no entry, so a new tool cannot ship unlabelled. There is no server-side confirmation step, no read-only mode, and a dry run exists only for previewing a pipeline's YAML. The server offers no delete tools, and most of its writes keep history in Azure DevOps, but pipeline runs, pull request approvals and auto-complete merges cannot be taken back.

The tools are purpose-built Azure DevOps operations with typed schemas and fixed action lists rather than a generic HTTP passthrough, and every request URL is built from the single organization given at startup; a wiki URL supplied by the model is refused if it points at another organization. Local file saves must be relative paths without traversal, under the server's working directory, and downloads have size caps. Some tools stay broad, though: ad-hoc WIQL queries, pipeline runs with caller-supplied variables and parameters, commits to any existing branch, and pull request auto-complete with an option to bypass branch policies. Many list sizes have no upper bound, and the default loads every tool group, writes included.

The server never runs model-supplied code or commands: it starts no subprocesses and has no eval or template execution. The only process it opens is the system browser for the sign-in page. Pipeline runs it can trigger execute on Azure DevOps agents, not in the server, and are scored as consequential actions under approval gates and untrusted input.

Everything the server returns from Azure DevOps (work items, comments, pull request threads, repository files, wiki pages, build logs, search results) is written by other people, and every tool's text output is wrapped in randomized delimiters labelled as untrusted with the source area. That marking is consistent and cannot be switched off, but it is a hint to the model, not a limit: the same default session holds the user's full access to private code and boards and can commit, run pipelines, approve pull requests and post content with nothing in the server requiring a human. There is no read-only mode that would drop the write side.

The server keeps no memory between sessions and loads no instruction or configuration files from the workspace: settings come from command-line flags and environment variables set by the operator. The only file it persists is a cache in the home directory mapping the organization name to its Microsoft Entra tenant, filled from an Azure DevOps response header and never shown to the model. Content the agent writes into Azure DevOps (wiki pages, work items) can of course be read back later; that exposure is scored under untrusted input.

The server loads no third-party code at runtime: no plugins, no MCP servers of its own, no downloaded tools or models. The one dynamic import is Microsoft's own sign-in broker library, a declared package dependency.

The server never hands its token to the model: no tool returns it, it is not written to logs, and the default sign-in keeps short-lived tokens only in memory. In personal access token mode the server also checks the destination host before sending the token. There is, however, no masking or redaction layer at all: API error bodies are passed back to the model verbatim, and protection rests on the code simply not printing credentials. There is no telemetry, and logs go to standard error at info level by default. A leaked default token is short-lived but carries the user's full Azure DevOps rights.

The server keeps no record of the tools it runs. Its logger writes startup and sign-in events to standard error, but no tool logs its calls, arguments or results, and there is no audit file, trace export or correlation ID. After an incident, what the agent did can only be pieced together from the host's transcript or Azure DevOps's own history, which shows the user as the actor.

A few operations have hard limits in the server: build artifact downloads are capped (1 GB to disk, 10 MB inline), ad-hoc WIQL queries are limited in length, directory listing depth is clamped, and one retry loop is bounded. Everything else is unbounded: most list sizes are whatever the model asks for, work item attachment downloads have no size cap, no request has a timeout, there is no rate limit on writes, and a cancelled call keeps running. Azure DevOps's own throttling is the main external ceiling.