PR Orchestrator MCP
Provides tools for automating pull request creation, managing forks and branches, and interacting with issues and PRs via the GitHub API.
Provides a tool to run pre-commit hooks on the repository.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PR Orchestrator MCPFix the typo in src/main.py and open a draft PR"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
PR Orchestrator MCP
The PR Orchestrator MCP is a tools-only Model Context Protocol (MCP) server that provides a safe and deterministic interface for automating the creation of pull requests against GitHub repositories. The server exposes a set of high-level operations—such as workspace management, repository cloning, branch management, test and lint execution, and GitHub API interactions—through the standardized MCP tool protocol.
A client language model (such as Claude in Cursor or other MCP-compatible clients) orchestrates calls to these tools to perform complex repair workflows on Python repositories. The server is intentionally "dumb"—it provides tools but does no autonomous reasoning. All decision-making is delegated to the client.
Architecture
┌─────────────────────┐ stdio (MCP) ┌──────────────────────┐
│ Orchestrator LLM │ ◄──────────────────────────► │ PR Orchestrator MCP │
│ (Claude/Cursor) │ tool calls + responses │ Server │
└─────────────────────┘ └──────────┬───────────┘
│
▼
┌──────────────────────┐
│ E2B Sandbox │
│ (isolated execution)│
└──────────────────────┘The server communicates over stdio using the MCP protocol. It registers tools that the client can discover and invoke. Each tool performs a specific operation and returns structured results.
Related MCP server: devflow-mcp
Motivation
Maintaining large codebases often involves applying fixes across many repositories. The PR Orchestrator MCP codifies common tasks into a reusable server so that clients (for example, an orchestrating LLM) can focus on reasoning while the server ensures a consistent and safe execution environment. It enforces strict safety policies, implements a branch strategy to avoid collisions, and produces verifiable evidence before opening a draft PR for review.
Features
MCP Protocol: Implements the standard Model Context Protocol for seamless integration with MCP-compatible clients like Claude Desktop and Cursor.
Workspace lifecycle: Create, manage and destroy isolated workspaces using the E2B code sandbox. Each workspace is time-limited and is used to perform all actions on the repository.
Repository operations: Clone the fork of an allowed repository, add an upstream remote, fetch branches and create or reuse topic branches. Enforce limits on the number of modified files and diff lines.
Editing tools: Read and write files, search through the repository and apply unified diffs. Patches are validated and redacted before being applied.
Quality assurance: Detect the project type, install dependencies, run tests, linting, type checking and formatting. Only the necessary commands are run and results are returned in structured JSON.
GitHub integration: Authenticate using a personal access token from
.env, ensure the fork exists, push changes and open a draft pull request with the required sections in the body. No auto-close keywords are allowed.Approval gate: Before pushing and opening a PR, the server exposes an approval tool which returns
approved: booland optional notes. The client must call this tool after reviewing the diff and evidence. Approval IDs are multi-use: they can authorize both push and PR creation.Fork-only workflow: Pushes are restricted to the user's fork (
origin). Direct pushes toupstreamare blocked.
Getting Started
This repository is intended to be consumed as a Python package and run via uv or python:
git clone https://github.com/your-fork/pr-orchestrator-mcp.git
cd pr-orchestrator-mcp
python -m venv .venv
source .venv/bin/activate
pip install -e .[dev]
cp .env.example .env
# Edit .env with your credentials
uv run pr-orchestrator-mcp # or python -m pr_orchestrator.serverEnvironment Variables
Create a .env file with the following required variables:
GITHUB_TOKEN=ghp_your_token_here
GITHUB_USERNAME=your_github_username
ALLOWED_REPOS=owner/repo1,owner/repo2
E2B_API_KEY=your_e2b_api_key
# Optional
E2B_TEMPLATE=base # E2B template with restricted network
LOG_LEVEL=INFO
E2B_ALLOW_LOCAL_FALLBACK=false # Set to true only for local testingUsing with Cursor/Claude
Add the server to your MCP configuration:
{
"mcpServers": {
"pr-orchestrator": {
"command": "uv",
"args": ["run", "pr-orchestrator-mcp"],
"cwd": "/path/to/pr-orchestrator-mcp"
}
}
}Tools Overview
The server exposes the following tool categories:
Workspace Tools
workspace_create- Create a sandboxed workspaceworkspace_destroy- Destroy a workspacerun_command- Execute allowed commands in a workspace
Repository Tools
ensure_fork- Ensure a fork exists for an upstream reporepo_clone- Clone a repository into workspacerepo_setup_remotes- Clone fork and configure upstream remoterepo_checkout,repo_create_branch,repo_fetchrepo_diff,repo_commit,repo_push(requires approval)
Editing Tools
read_file,write_file- File operationssearch_repo- Search repository contentsapply_patch- Apply unified diff patches
QA Tools
detect_project- Detect project type and commandsinstall_deps- Install dependenciesrun_tests,run_lint,run_typecheck,run_formatrun_precommit- Run pre-commit hooks
GitHub Tools
github_get_issue- Retrieve issue detailsgithub_find_prs_for_issue- Find related PRsgithub_open_pr- Open a pull request (requires approval)
Approval Tool
request_approval- Request approval for irreversible actions
Artifact Tool
bundle_artifacts- Create a redacted artifact bundle (returns base64)
See docs/tool-spec.md for detailed specifications of each tool.
Safety Features
Command allowlist: Only approved commands can be executed
Fork-only pushes: Cannot push to upstream, only to your fork
Approval gating: Push and PR creation require explicit approval
No auto-close: PR bodies cannot contain
closes/fixes/resolves #NSecret redaction: Tokens are redacted from all outputs
E2B sandbox: Execution happens in isolated containers
Repository allowlist: Only configured repos can be accessed
Repository Layout
pr-orchestrator-mcp/
├── README.md # This file
├── LICENSE # MIT license
├── CHANGELOG.md # Project changelog
├── CODE_OF_CONDUCT.md # Contributor Covenant code of conduct
├── CONTRIBUTING.md # Contribution guidelines
├── SECURITY.md # Security policies and reporting
├── pyproject.toml # Project metadata and dependencies
├── uv.lock # Lockfile for uv/pip
├── Makefile # Development tasks
├── docs/ # Documentation
│ ├── architecture.md # High-level architecture description
│ ├── threat-model.md # Threat modelling and safety considerations
│ ├── tool-spec.md # Detailed specification of each tool
│ └── demo.md # Walkthrough of a typical run
├── src/
│ └── pr_orchestrator/ # Source code package
│ ├── __init__.py
│ ├── server.py # MCP stdio server entrypoint
│ ├── state.py # Shared state (config, workspaces, runs)
│ ├── config.py # Configuration loading from environment
│ ├── constants.py # Hard-coded constants from the spec
│ ├── policy/ # Safety policies and allowlists
│ ├── sandbox/ # Workspace and E2B sandbox abstraction
│ ├── git/ # Git operations and branch strategy
│ ├── qa/ # Quality assurance helpers
│ ├── github/ # GitHub API interactions
│ ├── tools/ # Public tool interfaces
│ ├── artifacts/ # Artifact bundling and report generation
│ └── telemetry/ # Logging and run store implementation
├── tests/ # Unit and integration tests
│ ├── unit/
│ └── integration/
└── scripts/
├── smoke_test.sh # Quick smoke test for the server
└── run_server.sh # Helper script to start the MCP serverContributing
Contributions are welcome! Please read CONTRIBUTING.md and CODE_OF_CONDUCT.md before opening an issue or pull request. All changes must include unit tests and be accompanied by an entry in CHANGELOG.md.
License
This project is licensed under the terms of the MIT license. See LICENSE for details.
Available Tools
33 toolsapply_patchB
Apply a unified diff patch and enforce patch limits.
The patch is written to a temporary file inside the sandbox and applied
using ``git apply``. Patch limits are enforced before application.
| Name | Required | Description | Default |
|---|---|---|---|
| unified_diff | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
bundle_artifactsA
Bundle artifacts into a redacted zip and return it as base64.
The caller must provide the diff text, metadata dictionary, before and
after failure structures, and any logs to include. A list of secrets
should be supplied to aid in redaction.
S3: Returns the zip archive as base64-encoded bytes so the client can
retrieve it directly via the MCP protocol without needing filesystem
access to the server.
Returns:
A dictionary containing:
- artifact_path: Local filesystem path to the zip (for debugging)
- zip_filename: The filename of the zip archive
- zip_base64: Base64-encoded contents of the zip file
- size_bytes: Size of the zip file in bytes
| Name | Required | Description | Default |
|---|---|---|---|
| logs | Yes | ||
| secrets | Yes | ||
| metadata | Yes | ||
| diff_text | Yes | ||
| after_failures | Yes | ||
| before_failures | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
detect_projectD
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
ensure_forkA
Ensure a fork exists for the given upstream_repo_slug.
The upstream repository must be allowed according to the configured
allowlist (via ``upstream_allowed``). A fork will be created under the
authenticated user's account if it does not already exist. The function
returns the fork slug (``username/repo``), the HTTPS clone URL, and
whether a new fork was created.
| Name | Required | Description | Default |
|---|---|---|---|
| upstream_repo_slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
github_ensure_forkA
Ensure a fork exists for the given upstream repository.
Creates a fork under the authenticated user's account if it does not already exist. Returns the fork slug, clone URL, upstream clone URL, and whether the fork was newly created.
The upstream repository must be in the allowlist.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
github_find_prs_for_issueB
Find PRs linked to an issue.
The repository must be in the allowlist.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_slug | Yes | ||
| issue_number | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
github_get_issueC
Get issue details from GitHub.
The repository must be in the allowlist.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_slug | Yes | ||
| issue_number | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
github_open_prA
Open a pull request on GitHub.
Requires a valid ``approval_id``, which is consumed prior to performing
the API call. Raises ``PermissionError`` if the approval ID is missing or
invalid. Delegates to the underlying GitHub API implementation.
Validates that:
1. The upstream repository is in the allowlist
2. The fork owner matches the configured GitHub username
3. The PR body does not contain auto-close keywords (closes, fixes, resolves)
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| draft | No | ||
| title | Yes | ||
| approval_id | No | ||
| base_branch | Yes | ||
| head_branch | Yes | ||
| fork_repo_slug | Yes | ||
| upstream_repo_slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
install_depsD
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
read_fileA
Read a file within the checked-out repository.
The path is relative to the repository root. Content is read from the E2B sandbox and secrets are redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_add_remoteC
Add a new remote to the repository.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_checkoutB
Checkout a branch, tag or commit.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_cloneA
Clone a repository into the workspace.
The repository is cloned into the ``repo`` subdirectory within the sandbox.
All operations happen inside E2B - no host filesystem access.
The repository must be in the allowlist.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_commitB
Commit staged changes with a commit message.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_create_branchB
Create a new branch from a given reference.
| Name | Required | Description | Default |
|---|---|---|---|
| from_ref | Yes | ||
| branch_name | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_diffA
Get the unified diff of all changes in the working directory.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_fetchC
Fetch updates from a remote.
| Name | Required | Description | Default |
|---|---|---|---|
| remote | No | upstream | |
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_find_existing_branchesC
Find branches matching any of the provided patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| patterns | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_list_branchesC
List branches in the repository.
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | ||
| remote | No | origin | |
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_pushA
Push the current HEAD to the specified remote/branch.
A valid ``approval_id`` must be provided.
Only pushing to 'origin' (the fork) is allowed.
The fork must be under the configured GitHub username.
| Name | Required | Description | Default |
|---|---|---|---|
| remote | No | origin | |
| approval_id | No | ||
| branch_name | No | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_read_pr_templateB
Read the repository's pull request template.
Reads `.github/pull_request_template.md` from inside the sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
repo_setup_remotesA
Clone the user's fork and add the upstream remote.
This helper encapsulates the recommended cloning workflow for a fork-based
contribution flow:
1. Clone the fork into repo/
2. Add upstream remote
3. Fetch upstream
4. Checkout base branch tracking upstream
All operations happen inside E2B sandbox.
Both fork and upstream URLs must be in the allowlist.
| Name | Required | Description | Default |
|---|---|---|---|
| fork_url | Yes | ||
| base_branch | No | main | |
| upstream_url | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
request_approvalA
Record the approval decision and return an approval token if approved.
The server verifies that mandatory fields (summary, unified_diff, checks,
branch_plan) are present. If ``approved`` is True, a unique approval
identifier is generated and stored. This identifier must be provided to
tools that perform side effects (e.g., pushing commits or opening
pull requests).
The approval ID is multi-use: it can be consumed for both "push" and
"open_pr" actions, but each action can only be performed once per approval.
The approval record is only deleted when all allowed actions have been used.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| checks | Yes | ||
| pr_body | No | ||
| summary | Yes | ||
| approved | Yes | ||
| pr_draft | Yes | ||
| pr_title | No | ||
| issue_url | No | ||
| branch_plan | Yes | ||
| unified_diff | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
run_commandA
Execute a command inside a workspace.
The ``mode`` argument controls the command allowlist. Supported values:
* ``safe`` (default): Only allow a restricted set of commands (git, uv, pip install,
pytest/unittest, ruff, mypy). This prevents dangerous operations.
* ``expert``: Allows the same commands plus additional dev tools (not implemented here).
Commands that violate the allowlist will raise a ``PermissionError``.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | . | |
| mode | No | safe | |
| command | Yes | ||
| timeout_s | No | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
run_formatD
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
run_lintD
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
run_precommitD
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
run_testsD
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
run_typecheckD
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
search_repoA
Search for query within files under the repository root.
Executes a Python search script inside the sandbox to find matches.
Limited to a modest time budget and maximum match count.
| Name | Required | Description | Default |
|---|---|---|---|
| globs | No | ||
| query | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
workspace_createB
Create a new workspace and return its identifier.
The ``ttl_minutes`` is clamped to the maximum allowed TTL from configuration.
Returns workspace info including expiration time.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | code | |
| ttl_minutes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
workspace_destroyC
Destroy a workspace by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
write_fileC
Write content to a file in the repository.
The path is relative to the repository root.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| workspace_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
33 tool updates
v0.1.0- First observed
apply_patch - First observed
bundle_artifacts - First observed
detect_project - First observed
ensure_fork - First observed
github_ensure_fork - First observed
github_find_prs_for_issue - First observed
github_get_issue - First observed
github_open_pr - First observed
install_deps - First observed
read_file - First observed
repo_add_remote - First observed
repo_checkout - First observed
repo_clone - First observed
repo_commit - First observed
repo_create_branch - First observed
repo_diff - First observed
repo_fetch - First observed
repo_find_existing_branches - First observed
repo_list_branches - First observed
repo_push - First observed
repo_read_pr_template - First observed
repo_setup_remotes - First observed
request_approval - First observed
run_command - First observed
run_format - First observed
run_lint - First observed
run_precommit - First observed
run_tests - First observed
run_typecheck - First observed
search_repo - First observed
workspace_create - First observed
workspace_destroy - First observed
write_file
TDQS
Scored across 33 tools
There are notable overlaps: `ensure_fork` and `github_ensure_fork` appear to be duplicates, and `repo_setup_remotes` overlaps with `repo_clone` + `repo_add_remote`. The `run_*` tools with blank descriptions also create ambiguity. As a result, agents may struggle to select the right tool.
Tool names mix conventions: many are noun_verb (`repo_diff`, `workspace_create`) while others are verb_noun (`read_file`, `run_tests`). The `github_*` prefix is used inconsistently (`ensure_fork` vs `github_ensure_fork`), and there are multiple prefixes (`repo_`, `workspace_`, `github_`) with no clear pattern.
With 33 tools, the server is over-scoped for a PR orchestration workflow. Several tools are redundant (duplicate fork checks, overlapping remote setup), suggesting the tool surface could be consolidated. This exceeds the typical well-scoped range and may confuse agents.
The server covers the main PR creation flow (workspace, repo operations, changes, checks, push, open PR) but lacks lifecycle tools for existing PRs—no update, merge, or comment operations. There are also no PR listing or detail tools, which are common gaps for orchestration scenarios.
Maintenance
Related MCP Connectors
Create, deploy, and operate MCP servers directly from your GitHub repositories.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables Git repository operations and GitHub PR workflows, allowing users to manage repositories, create branches, commit changes, and create pull requests through natural language.2-
- AlicenseNot gradedqualityDmaintenanceA production-ready MCP server that provides AI assistants with comprehensive GitHub developer tooling including PR analysis, code review, changelog generation, dependency auditing, commit summarization, and refactoring suggestions.7 npmISC
- AlicenseCqualityDmaintenanceA production-ready MCP server for GitHub operations, providing tools for repository management, issues, pull requests, and more via both MCP stdio and REST API.27MIT
- AlicenseNot gradedqualityBmaintenanceMCP server providing maximum practical control over GitHub via REST and GraphQL APIs, exposing 22 tools for repository management, file operations, issues, PRs, Actions, and more.MIT