You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mcp__sdlc-server__pr_create's GitLab adapter invokes glab with the -F shorthand flag, but glab does not accept -F for mr create (or mr view). The tool returns: glab mr view failed: unknown shorthand flag: 'F' in -F.
glab version: local glab does not accept -F (verified by inspecting the error and glab mr create --help flags — body is passed via --description, not -F)
Steps to Reproduce
Call mcp__sdlc-server__pr_create({base: "<base>", head: "<head>", title: "...", body: "<long body>"}) against a GitLab project.
Curiously the error names glab mr view, not glab mr create — suggests the adapter creates the MR successfully then tries to query it back via glab mr view -F ... (or similar) and fails on that follow-up. In my reproduction, MR !70 was actually created on the GitLab side despite the error response. The adapter's failure surface is misleading: caller treats it as a creation failure when the MR actually exists.
Expected Behavior
pr_create returns {ok: true, number, url, ...} for successfully-created MRs.
The body argument flows through to glab mr create --description <text> (the canonical glab flag).
Actual Behavior
Adapter shells glab with -F somewhere in the chain; glab rejects.
MR may already be created; caller can't tell.
Severity
severity::major — /wavemachine's gate flow depends on pr_create to open the kahuna→base MR. Workaround is direct glab mr create --description "$(cat body.md)" from the orchestrator's Bash tool, but that bypasses the MCP layer entirely and the wave-pattern's idempotency / structured-return contract.
Summary
mcp__sdlc-server__pr_create's GitLab adapter invokesglabwith the-Fshorthand flag, but glab does not accept-Fformr create(ormr view). The tool returns:glab mr view failed: unknown shorthand flag: 'F' in -F.Environment
mcp__sdlc-server__pr_create({base, head, title, body})against ananalogicdev/internal/tools/wellofsoulsMR (Wave 2 Plan feat(wave-mcp): implement flight_overlap + lib/flight_overlap #74), 2026-05-06-F(verified by inspecting the error andglab mr create --helpflags — body is passed via--description, not-F)Steps to Reproduce
mcp__sdlc-server__pr_create({base: "<base>", head: "<head>", title: "...", body: "<long body>"})against a GitLab project.{"ok": false, "error": "glab mr view failed: unknown shorthand flag: 'F' in -F\n\nUsage: glab mr view {<id> | <branch>} [flags]\n..."}Curiously the error names
glab mr view, notglab mr create— suggests the adapter creates the MR successfully then tries to query it back viaglab mr view -F ...(or similar) and fails on that follow-up. In my reproduction, MR !70 was actually created on the GitLab side despite the error response. The adapter's failure surface is misleading: caller treats it as a creation failure when the MR actually exists.Expected Behavior
pr_createreturns{ok: true, number, url, ...}for successfully-created MRs.glab mr create --description <text>(the canonical glab flag).Actual Behavior
glabwith-Fsomewhere in the chain; glab rejects.Severity
severity::major—/wavemachine's gate flow depends onpr_createto open the kahuna→base MR. Workaround is directglab mr create --description "$(cat body.md)"from the orchestrator's Bash tool, but that bypasses the MCP layer entirely and the wave-pattern's idempotency / structured-return contract.Workaround
Skip
pr_create; use Bash + glab directly:Acceptance Criteria
pr_createagainst GitLab succeeds and returns a properly populated{ok: true, number, url, state, head, base}.-Fshorthand in the glab invocation; use--description(or--body-fileif glab gains it).mr viewfollow-up to populate the response, that call also avoids unsupported flags.pr_createagainst a GitLab fixture project returns the expected normalized envelope.Dependencies