Feature Request
Problem
The create_pull_request tool currently does not support adding labels during PR creation. Users who want to label PRs at creation time must either:
- Make a separate
add_label tool call after creating the PR
- Manually add labels in the GitHub UI
This creates a poor developer experience in agentic workflows where a PR should be created with appropriate labels in a single step (e.g., "Create a PR for this bugfix and label it as bug and priority:high").
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 would use 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 should clearly indicate the PR was created successfully but labels could not be applied.
Use Cases
- Agentic workflows: "Create a PR from my feature branch and label it as
enhancement"
- CI/CD automation: Programmatically creating PRs with classification labels
- Triage workflows: Creating PRs with priority/area labels in one step
Impact
- Makes the
create_pull_request tool more complete and reduces the number of tool calls needed
- Aligns with how developers naturally think about PR creation (title + description + labels together)
- No breaking changes — the parameter is fully optional
Feature Request
Problem
The
create_pull_requesttool currently does not support adding labels during PR creation. Users who want to label PRs at creation time must either:add_labeltool call after creating the PRThis creates a poor developer experience in agentic workflows where a PR should be created with appropriate labels in a single step (e.g., "Create a PR for this bugfix and label it as
bugandpriority:high").Proposed Solution
Add an optional
labelsparameter (string array) to thecreate_pull_requesttool. Since the GitHub REST APIPOST /repos/{owner}/{repo}/pullsdoes not natively support labels, the implementation would use a two-step approach:POST /repos/{owner}/{repo}/issues/{issue_number}/labelsIf label application fails after PR creation, the error should clearly indicate the PR was created successfully but labels could not be applied.
Use Cases
enhancement"Impact
create_pull_requesttool more complete and reduces the number of tool calls needed