Skip to main content
Glama

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: bool and 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 to upstream are 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.server

Environment 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 testing

Using 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 workspace

  • workspace_destroy - Destroy a workspace

  • run_command - Execute allowed commands in a workspace

Repository Tools

  • ensure_fork - Ensure a fork exists for an upstream repo

  • repo_clone - Clone a repository into workspace

  • repo_setup_remotes - Clone fork and configure upstream remote

  • repo_checkout, repo_create_branch, repo_fetch

  • repo_diff, repo_commit, repo_push (requires approval)

Editing Tools

  • read_file, write_file - File operations

  • search_repo - Search repository contents

  • apply_patch - Apply unified diff patches

QA Tools

  • detect_project - Detect project type and commands

  • install_deps - Install dependencies

  • run_tests, run_lint, run_typecheck, run_format

  • run_precommit - Run pre-commit hooks

GitHub Tools

  • github_get_issue - Retrieve issue details

  • github_find_prs_for_issue - Find related PRs

  • github_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 #N

  • Secret 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 server

Contributing

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 tools
apply_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.
NameRequiredDescriptionDefault
unified_diffYes
workspace_idYes

Output Schema

NameRequiredDescription

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
NameRequiredDescriptionDefault
logsYes
secretsYes
metadataYes
diff_textYes
after_failuresYes
before_failuresYes

Output Schema

NameRequiredDescription

No output parameters

detect_projectD
NameRequiredDescriptionDefault
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
upstream_repo_slugYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
repo_slugYes

Output Schema

NameRequiredDescription

No output parameters

github_find_prs_for_issueB

Find PRs linked to an issue.

The repository must be in the allowlist.
NameRequiredDescriptionDefault
repo_slugYes
issue_numberYes

Output Schema

NameRequiredDescription

No output parameters

github_get_issueC

Get issue details from GitHub.

The repository must be in the allowlist.
NameRequiredDescriptionDefault
repo_slugYes
issue_numberYes

Output Schema

NameRequiredDescription

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)
NameRequiredDescriptionDefault
bodyYes
draftNo
titleYes
approval_idNo
base_branchYes
head_branchYes
fork_repo_slugYes
upstream_repo_slugYes

Output Schema

NameRequiredDescription

No output parameters

install_depsD
NameRequiredDescriptionDefault
workspace_idYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
pathYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_add_remoteC

Add a new remote to the repository.

NameRequiredDescriptionDefault
urlYes
nameYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_checkoutB

Checkout a branch, tag or commit.

NameRequiredDescriptionDefault
refYes
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
repo_urlYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_commitB

Commit staged changes with a commit message.

NameRequiredDescriptionDefault
messageYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_create_branchB

Create a new branch from a given reference.

NameRequiredDescriptionDefault
from_refYes
branch_nameYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_diffA

Get the unified diff of all changes in the working directory.

NameRequiredDescriptionDefault
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_fetchC

Fetch updates from a remote.

NameRequiredDescriptionDefault
remoteNoupstream
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_find_existing_branchesC

Find branches matching any of the provided patterns.

NameRequiredDescriptionDefault
patternsYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_list_branchesC

List branches in the repository.

NameRequiredDescriptionDefault
allNo
remoteNoorigin
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
remoteNoorigin
approval_idNo
branch_nameNo
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

repo_read_pr_templateB

Read the repository's pull request template.

Reads `.github/pull_request_template.md` from inside the sandbox.
NameRequiredDescriptionDefault
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
fork_urlYes
base_branchNomain
upstream_urlYes
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
notesNo
checksYes
pr_bodyNo
summaryYes
approvedYes
pr_draftYes
pr_titleNo
issue_urlNo
branch_planYes
unified_diffYes

Output Schema

NameRequiredDescription

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``.
NameRequiredDescriptionDefault
cwdNo.
modeNosafe
commandYes
timeout_sNo
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

run_formatD
NameRequiredDescriptionDefault
commandNo
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

run_lintD
NameRequiredDescriptionDefault
commandNo
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

run_precommitD
NameRequiredDescriptionDefault
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

run_testsD
NameRequiredDescriptionDefault
commandNo
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

run_typecheckD
NameRequiredDescriptionDefault
commandNo
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
globsNo
queryYes
workspace_idYes

Output Schema

NameRequiredDescription

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.
NameRequiredDescriptionDefault
modeNocode
ttl_minutesNo

Output Schema

NameRequiredDescription

No output parameters

workspace_destroyC

Destroy a workspace by ID.

NameRequiredDescriptionDefault
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

write_fileC

Write content to a file in the repository.

The path is relative to the repository root.

NameRequiredDescriptionDefault
pathYes
contentYes
workspace_idYes

Output Schema

NameRequiredDescription

No output parameters

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 33 tool updatesv0.1.0
    • First observedapply_patch
    • First observedbundle_artifacts
    • First observeddetect_project
    • First observedensure_fork
    • First observedgithub_ensure_fork
    • First observedgithub_find_prs_for_issue
    • First observedgithub_get_issue
    • First observedgithub_open_pr
    • First observedinstall_deps
    • First observedread_file
    • First observedrepo_add_remote
    • First observedrepo_checkout
    • First observedrepo_clone
    • First observedrepo_commit
    • First observedrepo_create_branch
    • First observedrepo_diff
    • First observedrepo_fetch
    • First observedrepo_find_existing_branches
    • First observedrepo_list_branches
    • First observedrepo_push
    • First observedrepo_read_pr_template
    • First observedrepo_setup_remotes
    • First observedrequest_approval
    • First observedrun_command
    • First observedrun_format
    • First observedrun_lint
    • First observedrun_precommit
    • First observedrun_tests
    • First observedrun_typecheck
    • First observedsearch_repo
    • First observedworkspace_create
    • First observedworkspace_destroy
    • First observedwrite_file

TDQS

C2.2/5.0

Scored across 33 tools

Disambiguation2/5

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.

Naming Consistency2/5

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.

Tool Count2/5

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.

Completeness3/5

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

ActivityInactive
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    An 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
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    A 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 npm
    ISC
  • A
    license
    C
    quality
    D
    maintenance
    A production-ready MCP server for GitHub operations, providing tools for repository management, issues, pull requests, and more via both MCP stdio and REST API.
    27
    MIT