Skip to main content
Glama
Sign In
GitHub MCP Server — AutomateHub

GitHub MCP Server — AutomateHub

by gnvidia06-ux
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Crear branch

create_branch

Creates a new GitHub branch from the main or specified branch so you can start a feature or fix or work in parallel without touching the main line.

Instructions

Crea una branch nueva en un repositorio de GitHub, a partir de la branch principal o de la que se indique. Usala cuando el usuario quiera empezar una feature, un fix o trabajar en paralelo sin tocar la branch principal.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>",
      "branch": "<branch>"
    },
    "name": "create_branch"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoYesNombre del repositorio, sin el owner. Ejemplo: 'mi-proyecto'.
ownerNoUsuario u organización dueña del repositorio. Si se omite, se usa el usuario autenticado (dueño del token).
branchYesNombre de la nueva branch. Ejemplo: 'feature/login'.
fromBranchNoBranch desde la cual crear la nueva. Si se omite, se usa la branch principal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose one behavioral trait beyond the schema (the default base is the main branch when fromBranch is omitted), but it says nothing about whether the call fails if the branch already exists, idempotency, required token scopes, or whether anything is pushed or fetched.

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

Conciseness5/5

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

Two sentences with no filler: the action and its scope come first, the usage context second. Nothing repeats the parameter names unnecessarily.

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?

With four fully documented parameters, no annotations, and no output schema, the description covers what the tool does and when to reach for it. The remaining gap is failure semantics for an existing branch and permission requirements, which matters for a mutation tool but is a moderate omission.

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?

Schema description coverage is 100%, so every parameter is already documented, including the exact fallback for owner and fromBranch. The description only reinforces the fromBranch default and adds no new meaning beyond the schema, which is the baseline case.

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 (create) and resource (a new branch in a GitHub repository) plus the scope of where the branch can be forked from. No sibling tool (create_repository, create_commit, create_issue) creates branches, so an agent can distinguish it immediately.

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

Usage Guidelines4/5

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

The second sentence gives concrete usage triggers: starting a feature, a fix, or working in parallel without touching the main branch. It does not state when NOT to use it or name an alternative tool, which keeps it short of the top score.

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

Deploy Server

Other Tools