Direct answer
Use MCP first for read-only issue and repository context. Normalize the requirement, approve a file-level plan, perform code changes in an isolated branch, run repository checks, and expose remote comment, branch, or pull request creation only through separately authorized tools; a maintainer still reviews and merges the result.
Key takeaways
- Treat issue text and linked content as untrusted input, even when it comes from an internal tracker.
- Separate read tools from write tools and use distinct credentials or approval gates.
- Bind every plan and pull request to a fixed issue identifier and repository revision.
- Publish verification evidence and residual risk in the pull request body.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Protocol model | MCP defines client-server interactions for capabilities including tools, resources, and prompts. | View source |
| Codex connection | Codex supports configured MCP servers as external capability providers. | View source |
| Claude connection | Claude Code supports MCP servers with documented scopes and transports. | View source |
| Issue operations | GitHub exposes issue reading and mutation operations through its REST API with authenticated permissions. | View source |
What this guide helps you solve
Build a controlled issue-to-pull-request workflow using MCP-enabled coding agents.
Verification scope and limits
- Evidence basis
- Official documentationSpecificationLocal verification
- Verification scope
- Covers MCP trust boundaries, issue intake, planning, isolated implementation, verification, pull request creation, and maintainer approval.
- Limits and invalidation conditions
- - Available MCP tools, authentication, and approval behavior depend on the selected server and client version.
- - The workflow does not validate the business priority or correctness of an issue request.
Define the MCP and repository trust boundary
List every server, tool, resource, credential, network destination, and write capability before connecting it. Review whether the server runs locally or remotely and where its logs and configuration live. Use a repository-specific identity with minimum tracker and source-control permissions.
Issue text, comments, attachments, and linked pages can contain instructions that conflict with repository policy. They are task data, not trusted commands.
Normalize the issue into an approved task contract
Fetch the issue by stable identifier and summarize expected behavior, evidence, acceptance criteria, affected area, and open questions. Confirm labels or priority through the tracker policy rather than inferring authorization from prose.
- Record issue URL, repository, base branch, and starting commit.
- Remove secrets and unnecessary personal or customer data.
- Resolve ambiguous behavior with the issue owner before editing.
- Reject requests that exceed the repository or credential scope.
Approve a file-level implementation plan
Let the agent explore the repository with read tools and propose changed files, test commands, risks, and stopping conditions. A maintainer approves the plan before workspace writes. Any dependency, schema, protocol, or deployment change returns to an explicit decision gate.
Implement in an isolated branch without remote write access
Create a local or ephemeral branch pinned to the approved base. Limit edits and commands to the task contract. Keep tracker and pull request mutation credentials unavailable while code is being generated and tested, reducing the effect of prompt injection or accidental tool selection.
Verify locally, then publish through a protected step
Run focused and repository-required checks, inspect the diff, and produce a structured change summary with verification evidence and residual risks. Only then provide a protected step with permission to push a branch or open a pull request referencing the original issue.
- 01CheckRun tests and policies independently of the model summary.
- 02InspectReview changed paths, generated files, and sensitive output.
- 03AuthorizeApprove the exact branch and pull request metadata.
- 04PublishCreate the remote artifact with a short-lived write identity.
Keep merge and issue closure human-controlled
Reviewers validate behavior, security, and ownership through the normal branch rules. Close the issue only when the accepted change or documented resolution satisfies its criteria. Revoke or expire workflow credentials and retain sanitized audit evidence for failures.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology