GitFlic MCP Server

gitflic_mr_create

DestructiveIdempotent

Create a merge request with a required description, using the current branch as source and the project default as target unless branches are specified.

Instructions

Create a new merge request. description is required (GitFlic rejects empty MR descriptions). If from is omitted, uses current git branch; if to is omitted, uses project default branch.

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>",
      "title": "<title>",
      "description": "<description>"
    },
    "name": "gitflic_mr_create"
  }
}

Input Schema

Name	Required	Description
`to`	No	Target branch (default: project default branch)
`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	Source branch (default: current git branch)
`title`	Yes
`squash`	No	Squash commits on merge
`project`	Yes
`description`	Yes	Markdown body
`removeBranch`	No	Remove source branch on merge (default true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Nov 13, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: GitFlic rejects empty MR descriptions, which explains the hard requirement, plus the implicit branch-resolution rules. It does not mention that the source branch is removed on merge by default (destructiveHint), though the schema does.

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?

Three short sentences with the core action front-loaded and no filler. The parenthetical explaining the empty-description rejection earns its place; nothing is wasted. Slightly more compact phrasing could merge the two branch-default clauses.

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 an 8-parameter mutation with no output schema, the description covers the required fields, the defaulting behavior of the branch parameters, and one upstream validation rule. The remaining optional flags (`raw`, `squash`, `removeBranch`) are adequately explained by the schema, so no critical gap remains.

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 75%, so the schema already documents `from`, `to`, `raw`, `squash`, and `removeBranch`. The description restates the `from`/`to` defaults and flags `description` as required, which is largely redundant with the schema's required array, though the 'why' (empty descriptions rejected) adds a little value. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Create a new merge request.' That verb cleanly separates it from the sibling set's edit/merge/close/view MR tools without needing to name them. It stops short of explicitly contrasting with siblings such as gitflic_mr_edit, which keeps it out of the top band.

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?

It gives conditional guidance for the branch parameters ('If `from` is omitted, uses current git branch; if `to` is omitted, uses project default branch'), which tells the agent when it can safely skip them. It offers no guidance on when to create a new MR versus reusing/editing an existing one, and no prerequisites such as target project access.

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

Deploy Server