Skip to main content
Glama

Interactive MR Create

gitlab_interactive_mr_create

Interactively create a GitLab merge request by answering step-by-step prompts for source branch, target branch, title, description, labels, and settings. Final confirmation before API call; cancel anytime to abort.

Instructions

Create a GitLab merge request through step-by-step prompts, with explicit confirmation before calling the GitLab API. Cancellation at any prompt aborts without creating the MR.

After invocation, the tool elicits in order:

  • source_branch (string, required) — branch with the changes to merge.

  • target_branch (string, required) — branch to merge into (e.g. main, develop).

  • title (string, required) — MR title.

  • description (string, optional, multi-line, Markdown) — leave empty to skip.

  • labels (string, optional) — comma-separated; trimmed and deduped server-side.

  • remove_source_branch (boolean, optional) — yes/no confirmation; default unset.

  • squash (boolean, optional) — yes/no confirmation; default unset.

  • confirm (boolean, required) — final yes/no review of the assembled summary.

When to use: human-in-the-loop MR creation. NOT for: scripted/programmatic creation — use gitlab_merge_request (action='create') with all fields pre-supplied.

Requires the MCP client to support the elicitation capability. If unsupported, returns a structured error naming gitlab_merge_request (action='create') as the alternative.

Returns: JSON with the created MR (id, merge_request_iid, web_url, title, source_branch, target_branch, state).

See also: gitlab_merge_request, gitlab_branch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesProject ID or URL-encoded path where the MR will be created

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
next_stepsNo
idYes
merge_request_iidYes
project_idYes
project_pathNo
source_project_idNo
target_project_idNo
titleYes
descriptionYes
stateYes
source_branchYes
target_branchYes
web_urlYes
merge_statusYes
draftYes
has_conflictsYes
blocking_discussions_resolvedYes
squashNo
squash_on_mergeNo
merge_when_pipeline_succeedsNo
should_remove_source_branchNo
discussion_lockedYes
rebase_in_progressNo
authorNo
merged_byNo
assigneesYes
reviewersYes
labelsYes
milestoneNo
referencesNo
shaNo
merge_commit_shaNo
merge_errorNo
changes_countNo
diverged_commits_countNo
upvotesNo
downvotesNo
squash_commit_shaNo
force_remove_source_branchNo
allow_collaborationNo
closed_byNo
merge_afterNo
task_completion_countNo
task_completion_totalNo
time_estimateNo
total_time_spentNo
subscribedNo
first_contributionNo
diff_refsNo
pipeline_idNo
pipeline_web_urlNo
pipeline_nameNo
head_pipeline_idNo
latest_build_started_atNo
latest_build_finished_atNo
created_atYes
updated_atYes
merged_atNo
closed_atNo
prepared_atNo
user_notes_countNo
Behavior5/5

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

The description details the interactive process, confirmation step, cancellation behavior, and error handling if elicitation unsupported. This adds significant context beyond annotations (destructiveHint=false, openWorldHint=true), e.g., 'Cancellation at any prompt aborts without creating the MR'.

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 well-structured with bullet points for elicited parameters and clear sections (when to use, returns). Slightly verbose but each sentence serves a purpose. Could be tightened slightly.

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

Completeness5/5

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

Covers all aspects: prerequisites (project_id, client capability), workflow, cancellation, output format, and alternatives. Given the tool's interactive nature, the description is complete and leaves no major gaps.

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?

The only input schema parameter (project_id) is already described in the schema. The description lists elicited parameters but adds no extra meaning for project_id. With 100% schema coverage, baseline 3 is appropriate.

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 clearly identifies the tool as creating a merge request through step-by-step prompts with confirmation. It distinguishes itself from sibling tools by explicitly stating it is not for scripted creation and directing to gitlab_merge_request.

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?

Provides explicit when-to-use ('human-in-the-loop MR creation') and when-not-to-use ('NOT for: scripted/programmatic creation'), including an alternative tool. Also mentions requirement for MCP client elicitation capability.

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/jmrplens/gitlab-mcp-server'

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