mcp-devops-onpremise

Overview Schema Source Related Servers Score Discussions Admin

devops_pull_request_write

Create and update pull requests, manage reviewers, and vote on PRs in on-premises Azure DevOps.

Instructions

Write operations for pull requests. Use the action parameter to create or update pull requests, add or remove reviewers, or cast the authenticated user's vote.

Input Schema

TableJSON Schema

Name	Required	Description
`vote`	No	Vote to cast: Approved, ApprovedWithSuggestions, NoVote, WaitingForAuthor, or Rejected.
`title`	No	Pull request title. Required for create; optional for update.
`action`	Yes	Action to perform: create, update, update_reviewers, or vote.
`labels`	No	Label names. Used for create and update.
`status`	No	New status for update: Active or Abandoned.
`is_draft`	No	Whether the pull request is a draft. Used for create and update.
`work_items`	No	Space-separated work item IDs to associate. Used for create.
`description`	No	Pull request description. Used for create and update.
`reviewer_ids`	No	Reviewer IDs. Required for update_reviewers.
`auto_complete`	No	Set or clear autocomplete. Used for update.
`bypass_policy`	No	Bypass branch policies on autocomplete. Requires bypass_reason.
`bypass_reason`	No	Reason for bypassing branch policies.
`repository_id`	No	Repository name or ID. Required for all actions.
`merge_strategy`	No	Merge strategy for autocomplete. Used for update.
`pull_request_id`	No	Pull request ID. Required for update, update_reviewers, and vote.
`reviewer_action`	No	Reviewer action: add or remove. Required for update_reviewers.
`source_ref_name`	No	Source branch ref for create, for example refs/heads/feature-branch.
`target_ref_name`	No	Target branch ref for create or update, for example refs/heads/main.
`delete_source_branch`	No	Delete source branch on autocomplete. Used for update.
`merge_commit_message`	No	Commit message for autocomplete. Used for update.
`transition_work_items`	No	Transition work items on autocomplete. Used for update.
`fork_source_repository_id`	No	Fork source repository ID. Used for create.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.1.0Sep 9, 2026

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds no behavioral detail beyond the annotation readOnlyHint=false. It simply restates that this is a write operation without disclosing potential side effects, required permissions, or the consequences of actions like abandoning a PR or casting a vote. Since annotations are minimal (only readOnlyHint), the description could have added value but does not; it is consistent with annotations but adds no extra transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the purpose, the key parameter ('action'), and the range of operations. It is front-loaded with the core concept and wastes no words, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 22 parameters and a rich schema, the description is brief but sufficient: it establishes the tool's role and points to the action parameter as the dispatcher. The schema already explains parameter-action relationships, and an output schema exists so return values are covered. The only minor gap is not explicitly warning that this tool is not for comment/thread operations, but sibling tool names make that evident. Overall, it is adequate for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter already has a detailed description in the input schema. The tool description only mentions the 'action' parameter, adding no new semantics beyond the schema. The schema itself notes which parameters are required for which actions (e.g., 'Required for create'), so the description does not need to compensate. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Write operations') and resource ('pull requests'), and explicitly enumerates the actions (create, update, update_reviewers, vote). This distinguishes it from read-only siblings like devops_pull_request_get and comment/thread tools, making the tool's scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for modifying pull requests but does not explicitly state when to avoid it in favor of sibling comment/thread tools. It names the 'action' parameter as the routing mechanism, which gives context, but it lacks explicit 'when-not-to-use' guidance for alternatives like comment update or deletion tools. Still, the scope is clear enough for an agent to infer it should be used for PR-level changes, not comment-level operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server