Describe the feature or problem you'd like to solve
The create_pull_request tool currently does not support adding labels during PR creation. Users who want to label PRs at creation time must make a separate add_label tool call after creating the PR, which adds friction in agentic workflows where a PR should be created with appropriate labels in a single step.
This is especially common in real-world usage — developers naturally say "create a PR and label it as bug" rather than thinking of it as two separate operations.
Proposed solution
Add an optional labels parameter (string array) to the create_pull_request tool. Since the GitHub REST API (POST /repos/{owner}/{repo}/pulls) does not natively support labels, the implementation uses a two-step approach:
- Create the PR via the existing pulls endpoint
- Apply labels via
POST /repos/{owner}/{repo}/issues/{issue_number}/labels
If label application fails after PR creation, the error clearly indicates the PR was created successfully but labels could not be applied, so no work is silently lost.
Benefits:
- Reduces tool calls needed for a common workflow (2 → 1)
- Aligns with how developers naturally think about PR creation
- Fully backwards-compatible — the parameter is optional
- Consistent with
issue_write which already supports labels at creation time
Example prompts or workflows (for tools/toolsets only)
-
"Create a pull request from my feature branch to main and label it as bug and priority:high" — Single-step PR creation with classification labels, common in triage workflows.
-
"Open a PR for this hotfix, mark it as draft, and add the urgent label" — Combines draft mode with labeling for time-sensitive fixes.
-
"Create a PR titled 'Add user auth' from feat/auth to develop with labels enhancement and security" — Full PR creation with multiple labels in one natural request.
-
"Submit a pull request for my changes and tag it as documentation" — Simple single-label use case that feels natural to say but currently requires two tool calls.
-
"Create PRs for each of my feature branches and label them with their respective area labels" — Batch automation scenario where reducing tool calls per PR matters.
Additional context
I have a working implementation in PR #2413 that includes:
- Backend:
labels array property in CreatePullRequest InputSchema + AddLabelsToIssue post-creation call
- Tests: 2 new test cases (success with labels, label failure after PR creation)
- UI: Labels input field in the
pr-write MCP App
- Docs: Updated toolsnap + auto-generated README via
script/generate-docs
All tests pass (go test ./...) and lint is clean (golangci-lint run --new-from-rev=HEAD → 0 issues).
Describe the feature or problem you'd like to solve
The
create_pull_requesttool currently does not support adding labels during PR creation. Users who want to label PRs at creation time must make a separateadd_labeltool call after creating the PR, which adds friction in agentic workflows where a PR should be created with appropriate labels in a single step.This is especially common in real-world usage — developers naturally say "create a PR and label it as bug" rather than thinking of it as two separate operations.
Proposed solution
Add an optional
labelsparameter (string array) to thecreate_pull_requesttool. Since the GitHub REST API (POST /repos/{owner}/{repo}/pulls) does not natively support labels, the implementation uses a two-step approach:POST /repos/{owner}/{repo}/issues/{issue_number}/labelsIf label application fails after PR creation, the error clearly indicates the PR was created successfully but labels could not be applied, so no work is silently lost.
Benefits:
issue_writewhich already supports labels at creation timeExample prompts or workflows (for tools/toolsets only)
"Create a pull request from my feature branch to main and label it as
bugandpriority:high" — Single-step PR creation with classification labels, common in triage workflows."Open a PR for this hotfix, mark it as draft, and add the
urgentlabel" — Combines draft mode with labeling for time-sensitive fixes."Create a PR titled 'Add user auth' from
feat/authtodevelopwith labelsenhancementandsecurity" — Full PR creation with multiple labels in one natural request."Submit a pull request for my changes and tag it as
documentation" — Simple single-label use case that feels natural to say but currently requires two tool calls."Create PRs for each of my feature branches and label them with their respective area labels" — Batch automation scenario where reducing tool calls per PR matters.
Additional context
I have a working implementation in PR #2413 that includes:
labelsarray property inCreatePullRequestInputSchema +AddLabelsToIssuepost-creation callpr-writeMCP Appscript/generate-docsAll tests pass (
go test ./...) and lint is clean (golangci-lint run --new-from-rev=HEAD→ 0 issues).