Packages

@argus/mcp-ado

The five-tool ADO MCP server — the only path by which the agent affects Azure DevOps.

guardrail

The tool surface is the security boundary: keeping it small, budgeted, and host-side is what makes "the agent cannot approve, merge, or push" true by construction rather than by policy.

Place in the system

The worker connects it in-process and hands the agent its tools; it executes every call through an injected AdoClient (from @argus/ado) with the worker's credentials — the model never holds a token. A stdio bin (argus-mcp-ado) exists for spawning it as a separate process, with PR and caps bound from env.

The tool surface

Tool	Purpose	Mutating
`get_pr_metadata`	Title, description, branches, author, status	No
`list_pr_threads`	Existing threads, status, authorship	No
`post_thread_reply`	Reply to an existing thread	Yes
`create_inline_thread`	New thread anchored to file + line range	Yes
`resolve_thread`	Mark a thread resolved	Yes

Three properties enforced here, per call:

Per-PR confinement — the server is constructed for one PrRef; there is no tool argument that names another PR.
Mutation budgets — MutationBudget enforces the caps (findings_cap_exceeded, comment_rate_exceeded, reply_depth_exceeded); a blocked call returns a typed refusal (ToolRefusal), not an error — the model reads it and stops rather than retrying.
Audit — every call invokes the onAudit hook with a typed AuditEntry (tool, outcome, refusal code), feeding the enforcement-level audit trail.

Key exports

createServer(adoClient, { prRef, caps, onAudit }), MutationBudget, MCP_ADO_TOOL_NAMES, REFUSAL_CODES, and the payload types (ToolSuccess / ToolFailure / ToolRefusal, McpAdoCaps, AuditEntry).

How it's tested

server.test.ts exercises all five tools over the MCP protocol against a recordingAdoClient, asserting payload shapes, refusal codes when budgets trip, and the audit stream; rateLimit.test.ts pins MutationBudget semantics.

← ado rules →