Skip to main content
Glama

scm_create_pull_request

Destructive

Open a pull request with file changes on a GitHub repository, automatically (no confirmation) - the pull request is itself the human review gate. Use this in agent mode to land a pipeline-failure fix or other change as a reviewable PR: creates a new branch from the base branch, commits the files, and opens the PR. This tool is only available in agent mode; in ask mode, propose the change and ask the user to switch to agent mode. Requires the exact owner from github_list_repositories - never guess it.

Input Schema

NameRequiredDescriptionDefault
bodyNoPull request description in markdown.
repoYesRepository name. Also accepts the combined 'owner/name' form.
draftNoIf true, create as a draft PR.
filesYesFiles to create or update. Each entry has a 'path' and 'content'.
ownerYesRepository owner (e.g. 'octocat'). Prefer the exact owner from a prior github_list_repositories call. May be embedded in 'repo' as 'owner/name'.
titleYesPull request title.
base_branchNoTarget branch to merge into. Defaults to the repository's default branch.
head_branchYesName for the new branch (e.g. 'fix/ci-build'). Must not already exist.
commit_messageYesGit commit message for the changes.
confirm_large_deletionsNoPaths from 'files' whose new content is intentionally much shorter than the file it replaces. A commit that would replace an existing file with less than half of its content is refused unless that path is listed here. Leave this out unless a refusal named the path and removing that much is the change you intend.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / confirm_large_deletions
      Added value: +{
      +  "description": "Paths from 'files' whose new content is intentionally much shorter than the file it replaces. A commit that would replace an existing file with less than half of its content is refused unless that path is listed here. Leave this out unless a refusal named the path and removing that much is the change you intend.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / files / items / properties / content / description
      Previous value: -"File content as a string."New value: +"The COMPLETE new content of the file. The commit replaces the whole file with this string; it is not a patch, so anything left out is deleted."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=true; the description goes beyond them by disclosing that it runs automatically with no confirmation, that the PR itself is the human review gate, and that it is gated to agent mode. It doesn't restate the destructive/overwrite nature (deferred to the schema's content field), so it adds real context without contradicting the safety profile.

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?

Front-loads the core action and the no-confirmation trait, then layers mode gating and the owner prerequisite. Four dense sentences with little waste, though the mode-gating clause could be tightened slightly.

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

Completeness4/5

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

For a 10-parameter mutation tool with no output schema, the description covers workflow, gating, and the critical owner precondition. It omits what is returned (PR number/URL) and the base-branch default, which leaves minor gaps but nothing that would cause a wrong invocation.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by mandating that owner come from a prior github_list_repositories call and never be guessed, and by summarizing the branch/commit/file flow. It doesn't elaborate on base_branch defaults or confirm_large_deletions, but the schema already covers those.

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?

States a specific verb and resource ("Open a pull request with file changes on a GitHub repository") and then enumerates the full side-effect sequence: creates a branch from base, commits the files, opens the PR. This makes the tool's scope distinguishable from the sibling read/manipulation tools even though it doesn't name github_create_pull_request directly.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (agent mode, land a pipeline-failure fix) and when-not-to-use (ask mode: propose the change and ask the user to switch). Also names the prerequisite source for the owner value (github_list_repositories, never guess). This is close to a complete routing instruction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources