GitFlic MCP Server

gitflic_branch_create

DestructiveIdempotent

Create a new GitFlic branch from an existing source branch by specifying the project, origin branch, and new branch name.

Instructions

Create a new branch from an existing one.

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": {
      "project": "<project>",
      "newBranch": "<newBranch>"
    },
    "name": "gitflic_branch_create"
  }
}

Input Schema

Name	Required	Description
`raw`	No	Return the full, un-slimmed GitFlic response for THIS call (no token compression). Use when the default slim view dropped a field you need.
`from`	No	Origin branch (default: master)
`project`	Yes
`newBranch`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Nov 13, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely covered. The description adds nothing beyond the name: it doesn't explain what a failure to create looks like, whether protected-branch rules block it, or that the call mutates repository state. With annotations carrying the weight, this is a thin but not contradictory description.

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?

A single sentence with no padding, and the operation is front-loaded before the origin-branch detail. Its brevity is slightly under-specification rather than verbosity, but structurally it is clean.

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

Completeness2/5

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

For a mutating branch-creation call with no output schema and two undocumented required parameters, the description should at least cover naming expectations, the default origin branch, and duplicate-branch behavior. Annotations cover the safety flags, but the required `project` and `newBranch` semantics and the outcome of the call are left entirely to inference.

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

Parameters2/5

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

Schema coverage is only 50%: `from` and `raw` are documented in the schema, while `project` and `newBranch` are bare. The description's phrase "from an existing one" loosely echoes the `from` parameter that the schema already documents, and it says nothing about whether `project` is an ID or a path. It does not compensate for the undocumented required parameters.

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

Purpose4/5

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

The description states a specific verb and resource ("Create a new branch") and adds the key qualifier that the branch derives from an existing one. It does not distinguish itself from nearby siblings such as gitflic_branch_default or gitflic_branch_protection_create, but the core operation is unambiguous.

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

Usage Guidelines3/5

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

"From an existing one" implies the prerequisite that an origin branch must exist, but there is no explicit when-to-use guidance, no mention of what happens if the branch already exists (despite idempotentHint=true), and no exclusions or alternative tools named. Usage is inferable rather than stated.

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

Deploy Server