GitLab ACTION
Create Merge Request Review
Submit a whole review on a merge request in one step: any number of inline comments anchored to lines of the diff, an overall summary comment, and optionally an approval. This is the tool for "review this MR" — call Get Merge Request and Get Merge Request Diffs first to read the changes, then send the findings back here. GitLab has no single submit-review API, so this action posts each inline comment as its own thread and then approves if asked; if an individual comment is rejected (usually a line that is not part of the diff) the rest are still posted and the failures are returned in
failed, so check that array rather than assuming everything landed. Line numbers follow GitLab's diff rules: new_line for a line the merge request adds, old_line for a line it removes, both for an unchanged context line. There is no REST equivalent of GitLab's Request changes state — to block a merge request, leave the findings as comments and do not approve. See the documentation- Action
- Writes data
- OAuth
- SDK
- MCP
IMPLEMENTATION
Call this tool
Connect a user's GitLab account once, then configure and run Create Merge Request Review from your backend or agent.
import { PipedreamClient } from "@pipedream/sdk"
const pd = new PipedreamClient({
projectId: process.env.PIPEDREAM_PROJECT_ID!,
clientId: process.env.PIPEDREAM_CLIENT_ID!,
clientSecret: process.env.PIPEDREAM_CLIENT_SECRET!,
projectEnvironment: "production",
})
const result = await pd.actions.run({
id: "gitlab-create-merge-request-review",
externalUserId: "{external_user_id}", // any stable ID for this user in your system
configuredProps: {
gitlab: { authProvisionId: "apn_xxxxxxx" },
projectId: "Project",
mergeRequestIid: 10,
},
})
console.log(result)curl -X POST https://api.pipedream.com/v1/connect/{project_id}/actions/run \
-H "Content-Type: application/json" \
-H "X-PD-Environment: production" \
-H "Authorization: Bearer {access_token}" \
-d '{
"external_user_id": "{external_user_id}",
"id": "gitlab-create-merge-request-review",
"configured_props": {
"gitlab": { "authProvisionId": "apn_xxxxxxx" },
"projectId": "Project",
"mergeRequestIid": 10
}
}'// accessToken: mint a short-lived token with the Connect SDK — see the MCP guide
const transport = new StreamableHTTPClientTransport(
new URL("https://remote.mcp.pipedream.net/v3"),
{
requestInit: {
headers: {
Authorization: `Bearer ${accessToken}`,
"x-pd-project-id": "{project_id}",
"x-pd-environment": "production",
"x-pd-external-user-id": "{external_user_id}", // any stable ID for this user in your system
"x-pd-app-slug": "gitlab",
},
},
},
)
const mcp = new Client({ name: "my-agent", version: "1.0.0" })
await mcp.connect(transport)
const { tools } = await mcp.listTools()
// listTools() hands your model this tool's input schema, so it can
// fill the arguments itself:
const result = await mcp.callTool({
name: "gitlab-create-merge-request-review",
arguments: {
projectId: "Project",
mergeRequestIid: 10,
},
})SCHEMA
Inputs
Pipedream supplies the connected account. Your application provides the operation-specific values below. Dynamic inputs are resolved against that user's account.
| Property | Type | Description |
|---|---|---|
projectId Project | string | The project, given either as its path — group/project or group/subgroup/project, e.g. backend/payments — or as its numeric project ID. The path is what appears in the project URL and is usually what a user will name, so prefer it. A pasted GitLab URL also works. Use List Projects to find the path if you only know part of the name. Required |
mergeRequestIid Merge Request IID | integer | The merge request's internal ID — the !N shown in the GitLab UI and the number at the end of the merge request URL. This is not the id field, which is a much larger instance-wide number; passing id here returns a 404. Use List Merge Requests or Search Merge Requests to resolve the IID from a title, branch or author. Required |
summary Summary | string | An overall comment on the merge request, posted as a plain (non-inline) comment after the inline ones. This is where the verdict goes — what the change does well, what is blocking, what you checked. Optional, but a review with only inline nitpicks and no summary reads badly. Optional |
comments Inline Comments | string | JSON array of inline comments to anchor to the diff. Each entry is {"new_path": "...", "new_line": N, "body": "..."} — for example [{"new_path": "src/api/client.py", "new_line": 88, "body": "This retries forever if the host is down; cap it."}, {"old_path": "src/legacy.py", "old_line": 12, "body": "Good riddance."}]. Use new_line for an added line, old_line for a removed one, and both for an unchanged context line. Paths and line numbers must come from Get Merge Request Diffs. Optional |
action Action | string | comment (the default) posts the feedback only. approve posts the feedback and then approves the merge request. GitLab refuses to let you approve your own merge request, so use comment on merge requests you authored. Optional |
REFERENCE
Tool details
Behavior hints are published with the component in the Pipedream registry and surface as MCP tool annotations, so an agent can reason about a tool before it calls it.
- Registry key
- gitlab-create-merge-request-review
- Version
- 0.0.1
- App
- GitLab
- Authentication
- OAuth
- Read-only
- No
- Destructive
- No
- Open world
- Yes
- Source
- View on GitHub ↗