Skip to main content
Glama

create_pull_request

Create a new pull request by specifying repository, branches, title, and description to propose code changes for review.

Instructions

Create a new pull request in a GitHub repository.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner
repoYesRepository name
titleYesPR title
bodyNoPR description
headYesBranch containing changes
baseYesBranch to merge into
draftNoCreate as draft PR
maintainer_can_modifyNoAllow maintainer edits

Implementation Reference

  • Registration of the 'create_pull_request' tool on the MCP server via server.tool(), including the schema definition and async handler function.
    // Tool: Create Pull Request
    server.tool(
    	"create_pull_request",
    	"Create a new pull request in a GitHub repository.",
    	{
    		owner: z.string().describe("Repository owner"),
    		repo: z.string().describe("Repository name"),
    		title: z.string().describe("PR title"),
    		body: z.string().optional().describe("PR description"),
    		head: z.string().describe("Branch containing changes"),
    		base: z.string().describe("Branch to merge into"),
    		draft: z.boolean().optional().describe("Create as draft PR"),
    		maintainer_can_modify: z
    			.boolean()
    			.optional()
    			.describe("Allow maintainer edits"),
    	},
    	async ({
    		owner,
    		repo,
    		title,
    		body,
    		head,
    		base,
    		draft,
    		maintainer_can_modify,
    	}) => {
    		try {
    			const response = await octokit.rest.pulls.create({
    				owner,
    				repo,
    				title,
    				body,
    				head,
    				base,
    				draft,
    				maintainer_can_modify,
    			})
    			const pr = response.data
    			let text = `PR created: **#${pr.number}: ${pr.title}**\n`
    			text += `URL: ${pr.html_url}\n`
    			text += `State: ${pr.state}${pr.draft ? " (draft)" : ""}\n`
    			text += `Branch: ${pr.head.label} -> ${pr.base.label}\n`
    			return {
    				content: [{ type: "text", text }],
    			}
    		} catch (e: any) {
    			return {
    				content: [{ type: "text", text: `Error: ${e.message}` }],
    			}
    		}
    	},
    )
  • Handler function that executes the PR creation via octokit.rest.pulls.create() and formats the success/error response.
    async ({
    	owner,
    	repo,
    	title,
    	body,
    	head,
    	base,
    	draft,
    	maintainer_can_modify,
    }) => {
    	try {
    		const response = await octokit.rest.pulls.create({
    			owner,
    			repo,
    			title,
    			body,
    			head,
    			base,
    			draft,
    			maintainer_can_modify,
    		})
    		const pr = response.data
    		let text = `PR created: **#${pr.number}: ${pr.title}**\n`
    		text += `URL: ${pr.html_url}\n`
    		text += `State: ${pr.state}${pr.draft ? " (draft)" : ""}\n`
    		text += `Branch: ${pr.head.label} -> ${pr.base.label}\n`
    		return {
    			content: [{ type: "text", text }],
    		}
    	} catch (e: any) {
    		return {
    			content: [{ type: "text", text: `Error: ${e.message}` }],
    		}
    	}
    },
  • Zod schema defining the input parameters for the create_pull_request tool.
    {
    	owner: z.string().describe("Repository owner"),
    	repo: z.string().describe("Repository name"),
    	title: z.string().describe("PR title"),
    	body: z.string().optional().describe("PR description"),
    	head: z.string().describe("Branch containing changes"),
    	base: z.string().describe("Branch to merge into"),
    	draft: z.boolean().optional().describe("Create as draft PR"),
    	maintainer_can_modify: z
    		.boolean()
    		.optional()
    		.describe("Allow maintainer edits"),
    },
  • Helper export function that registers all pull request tools (including create_pull_request) on the server.
    export function registerPullRequestTools(server: McpServer, octokit: Octokit) {
  • src/index.ts:18-19 (registration)
    Top-level registration of pull request tools from the main index entry point.
    registerPullRequestTools(server, octokit)
    registerRepositoryResource(server, octokit)
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states 'Create' without mentioning side effects, permissions (e.g., write access required), rate limits, or what happens on failure. The obvious mutation is implied, but richer context is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 10 words, making it very concise. However, it sacrifices behavioral and usage details for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, no output schema) and complete schema coverage, the description is adequate but minimal. It lacks context such as typical workflow order, prerequisites, or post-conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, so baseline is 3. The description adds no additional meaning beyond restating the tool's purpose. It does not explain parameter relationships or typical usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new pull request in a GitHub repository' clearly specifies the verb (create), resource (pull request), and context (GitHub repository). It effectively distinguishes from sibling tools like update_pull_request and merge_pull_request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as create_pull_request_review_comment or update_pull_request. There are no prerequisites, caveats, or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hithereiamaliff/mcp-github'

If you have feedback or need assistance with the MCP directory API, please join our Discord server