Add org-scoped "my pull requests" tool (created by / reviewing)

[Cooper Cox (coopercox-ms)]

Summary

Implement one new tool that returns pull requests with an organization-scoped list action so callers can retrieve pull requests across every project and repository in an Azure DevOps organization with one MCP call.

This is particularly useful for personal work views such as:

• Pull requests created by the authenticated user
• Pull requests where the authenticated user is a reviewer
• Active pull requests across the organization

The current list action requires either project or repositoryId, forcing clients to enumerate projects and issue many calls. Azure DevOps itself presents an organization-wide My Work → Pull requests view, and the projectless Git API endpoint returns pull requests from multiple projects in one response.

Tool

Extend the existing consolidated tool rather than introducing a separate tool:

repo_pull_request with action: "list_org"

List pull requests across all projects and repositories visible to the authenticated user in an organization.

Endpoint:

GET https://dev.azure.com/{organization}/_apis/git/pullrequests?api-version=7.1

Example requests:

    ?searchCriteria.status=1
    &searchCriteria.creatorId={authenticatedUserId}
    &$top=100
    &api-version=7.1

    ?searchCriteria.status=1
    &searchCriteria.reviewerId={authenticatedUserId}
    &$top=100
    &api-version=7.1

Parameters to expose where supported:

• creatorId
• reviewerId
• status
• repositoryId
• sourceRefName
• sourceRepositoryId
• targetRefName
• minTime
• maxTime
• queryTimeRangeType
• includeLinks
• top
• skip

Also retain these convenience filters:

• created_by_me — resolves the authenticated user's ID
• created_by_user — resolves an email address to an ID
• i_am_reviewer — resolves the authenticated user's ID
• user_is_reviewer — resolves an email address to an ID

The created_by_me and i_am_reviewer convenience filters should resolve the authenticated user's identity through the existing getCurrentUserDetails() helper.
creatorId and reviewerId should pass directly to the API. The convenience parameters exist so normal callers do not need to discover identity GUIDs. The issue should require a clear validation error if multiple creator or reviewer filters conflict.

Results should include enough context to identify each PR across the organization:

• Pull request ID
• Title and status
• Project name and ID
• Repository name and ID
• Creator
• Reviewers
• Source and target branches
• Creation and closure dates
• Web URL

Validation

The projectless endpoint has been tested successfully and:

1. Returned active pull requests from multiple projects in a single response.
2. Accepted  searchCriteria.creatorId .
3. Accepted  searchCriteria.reviewerId .
4. Returned the same creator and reviewer matches as local filtering of the organization-wide result set.

However, the projectless form does not appear to be documented alongside the supported Get Pull Requests By Project API:

https://learn.microsoft.com/rest/api/azure/devops/git/pull-requests/get-pull-requests-by-project?view=azure-devops-rest-7.1

Please confirm whether the organization-scoped route is supported. If it is considered an internal or unsupported route, an MCP-managed aggregation action would still be valuable: the server could enumerate projects internally and return one combined, paginated response so MCP clients do not need to make one call per project.

Implementation guidance

Modify the existing repo_pull_request action list; do not add a new
top-level MCP tool or duplicate its filtering logic.

The current implementation rejects requests when both repositoryId and
project are absent:

if (!repositoryId && !project) { return {
    content: [{ type: "text", text: "Either repositoryId or project must be provided." }],
    isError: true, };
}

Replace that restriction with three-way scope dispatch:

} else if (project) { // Existing project-scoped behavior.
} else { // New organization-scoped behavior.
}

The organization branch must issue:

GET https://dev.azure.com/{organization}/_apis/git/pullrequests

Reuse the existing searchCriteria construction, identity resolution,
pagination, trimming, and response shape for all three scopes.

Do not implement organization scope by enumerating projects. It should remain
one Azure DevOps request.

Rules

1. Adhere strictly to existing project standards and coding conventions.
2. Add this capability to the existing consolidated repo_pull_request tool.
3. Expose all applicable required and optional API parameters.
4. Reuse the existing identity-resolution helpers for authenticated-user filters.
5. Preserve the existing project- and repository-scoped list behavior.
6. Support pagination and avoid silently truncating organization-wide results.
7. Use the official Azure DevOps Node API where it supports the operation. If it cannot construct the organization-scoped route, use its authenticated REST client rather than introducing separate authentication handling.
8. Add tests covering organization scope, creator filtering, reviewer filtering, status filtering, pagination, and multi-project results.

Special treat

If you follow the rules, you'll get candy!

[Dan Hellem (danhellem)]

I am not seeing anyone else request this tool. I have some ideas on what we could change, but I would like to see more interest in it before we add another tool that we need to maintaint.