MULTI-APP TOOLKIT
Build with GitHub + GitLab
- Multi-app
- One MCP session
- 76 actions
- 37 triggers
- Managed auth
MCP
One MCP session, both toolsets
One session gives your product or agent every GitHub and GitLab tool at once — connect once, list tools, and call them like any single-app session.
// 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": "github,gitlab",
},
},
},
)
const mcp = new Client({ name: "my-agent", version: "1.0.0" })
await mcp.connect(transport)
const { tools } = await mcp.listTools()
// One list, both toolsets: GitHub and GitLab tools arrive
// together, each keyed by its own app's slug.
// e.g. run Create Issue:
const result = await mcp.callTool({
name: "github-create-issue",
arguments: {
repoFullname: "Repository",
title: "Title",
},
})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 externalUserId = "{external_user_id}" // any stable ID for this user in your system
const [githubTools, gitlabTools] =
await Promise.all([
pd.components.list({ app: "github" }),
pd.components.list({ app: "gitlab" }),
])
// One external user owns both connected accounts, so either app's tools
// run on their behalf with the same externalUserId.curl "https://api.pipedream.com/v1/connect/{project_id}/components?app=github" \
-H "X-PD-Environment: production" \
-H "Authorization: Bearer {access_token}"
curl "https://api.pipedream.com/v1/connect/{project_id}/components?app=gitlab" \
-H "X-PD-Environment: production" \
-H "Authorization: Bearer {access_token}"
# Connect both accounts to the same external_user_id, then
# configure and invoke either app's tools on that user's behalf.ARCHITECTURE
One user, two connected accounts
Your user connects each account once, under whatever ID they already have in your product. The two stay independent — either can be revoked on its own — and your code reaches both through that one user.
Your product
external_user_id
{external_user_id}Pipedream Connect
Managed identity
Auth · tools · routing
GitHub
Connected account
GitLab
Connected account
TOOLS
GitHub tools
The GitHub tools this pairing puts in reach, each one running on your user's own connected account.
Actions top 8 of 48
-
Create Issue
actionCreate a new issue in a repository, optionally with labels, assignees, and a milestone. Provide the repository as anowner/repostring. Labels and assignees are passed by name/login (e.g.bug,octocat) — setting them requires push access to the repo. To comment on an existing issue instead, use Create Issue Comment; to change an existing issue, use Update Issue. See the documentationWritev0.4.3 -
Search Issues and Pull Requests
actionSearch issues and pull requests across GitHub using the issues-search query DSL. This is the escape hatch for finding items by keyword, state, label, author, or assignee when you don't already know the issue/PR number. Build thequeryfrom space-separated qualifiers:repo:owner/nameto scope to one repo (a barerepo:namewith no owner is auto-resolved to your own account),is:issue/is:pr,is:open/is:closed,label:bug,author:octocat,assignee:octocat,in:title/in:body, and free-text keywords. Example:repo:PipedreamHQ/pipedream is:issue is:open label:bug raptor. Returns matching items (each withnumber,title,state,labels,html_url); feed a result'snumberinto Get Issue, Get Pull Request, or Create Issue Comment. See the query syntaxRead-onlyv0.3.3 -
Create Branch
actionCreate a new branch in a repository, pointing at the tip of a source branch. Provide the repository as anowner/repostring, the newbranchName, and optionally thesourceBranchto branch from (defaults to the repository's default branch). Use Create or Update File Contents to add commits to the new branch, then Create Pull Request to open a PR. See the documentationWritev1.0.2 -
Create Gist
actionAllows you to add a new gist with one or more files. See the documentationWritev0.0.18 -
Create Issue Comment
actionAdd a comment to an existing issue or pull request (GitHub treats PRs as issues for comments, so the samenumberworks for both). Provide the repository as anowner/repostring, the issue/PR number, and the comment body. If you only know the issue/PR by title, call Search Issues and Pull Requests first to resolve its number. See the documentationWritev0.1.3 -
Create or Update File Contents
actionCreate a new file or overwrite an existing one in a repository with a single commit. Provide the repository as anowner/repostring, the filepath, the raw textcontent(passed as-is — do not base64-encode it yourself), and a commit message. If the file already exists on the target branch it is overwritten; the required blob SHA is resolved for you automatically. Defaults to the repository's default branch unlessbranchis set. See the documentationWritev1.0.3 -
Create Pull Request
actionOpen a pull request proposing to merge one branch into another within a repository. Provide the repository as anowner/repostring, theheadbranch (the source containing your changes) and thebasebranch (the target, e.g.main), plus a title. The head and base branches must already exist and differ. For a cross-fork PR, setheadtousername:branch. Use Create or Update File Contents to push changes to a branch before opening the PR. See the documentationWritev1.0.3 -
Create Pull Request Review
actionSubmit a review on a pull request: approve it, request changes, or leave a general comment. SeteventtoAPPROVE,REQUEST_CHANGES, orCOMMENT— abodyis required forREQUEST_CHANGESandCOMMENT. Optionally attach inlinecommentstied to specific lines of the diff. GitHub forbids approving your own pull request, so useCOMMENTto leave feedback on PRs you authored. Provide the repository as anowner/repostring and the PR number. Use Get Pull Request Files to find the file paths and lines to comment on, and Search Issues and Pull Requests withis:prto resolve the PR number from a title. See the documentationWritev0.0.3
Triggers top 4 of 27
-
New Branch Created
triggerEmit new event when a branch is created.Instantv1.0.16 -
New Card in Column (Classic Projects)
triggerEmit new event when a (classic) project card is created or moved to a specific column. For Projects V2 useNew Issue with Statustrigger. More information hereInstantv1.0.15 -
New Collaborator
triggerEmit new event when a collaborator is addedInstantv1.0.16 -
New Commit
triggerEmit new event when commits are pushed to a branchInstantv1.0.17
TOOLS
GitLab tools
The GitLab tools this pairing puts in reach, each one running on your user's own connected account.
Actions top 8 of 28
-
Approve Merge Request
actionApprove a merge request as the authenticated user, or withdraw an earlier approval by setting Action tounapprove. Call Get Merge Request first to check the merge request is actually ready — itsreadinessrollup reports the pipeline status, conflicts and how many approvals are still required — and Get Merge Request Diffs to read the changes being approved. Two things commonly go wrong: GitLab refuses to let you approve your own merge request, and a project may require approval from a specific approval rule that the authenticated user does not satisfy; both surface as a401. To approve as part of leaving review feedback in one step, use Create Merge Request Review with its Action set toapproveinstead. Optionally pass SHA to make the approval conditional on the merge request's head commit, so it fails rather than silently approving work that was pushed after you read the diff. See the documentationWritev0.0.1 -
Create Branch
actionCreate a new branch in the repository. See the documentationWritev0.3.4 -
Create Epic
actionCreates a new epic. See the documentationWritev0.0.6 -
Create issue
actionCreates a new issue. See the documentationWritev0.2.4 -
Create Merge Request
actionOpen a new merge request from one branch into another. Use this for "open an MR", "raise a merge request", "submit my branch for review". Both branches must already exist in the project — use List Repo Branches to check, or Create Branch to make one. Reviewers and assignees are given as usernames and resolved to IDs automatically; a username that is not a member of the project is rejected rather than silently dropped. Set Draft totruefor work that is not ready for review — GitLab expresses this by prefixing the title withDraft:, which this action does for you and which blocks merging until removed. After creating, use Get Merge Request to check its pipeline and merge readiness. See the documentationWritev0.0.1 -
Create Merge Request Comment
actionPost a comment on a merge request. It works in three modes, chosen by which props you set: leave File Path and Discussion ID blank for a plain comment on the merge request as a whole; set File Path plus a line number to open an inline thread anchored to that line of the diff; or set Discussion ID to reply inside an existing thread. Use Get Merge Request Diffs first to get valid file paths and line numbers, and List Merge Request Discussions to get a Discussion ID to reply to. Line numbers follow GitLab's diff rules: for a line the merge request adds or leaves unchanged, pass New Line; for a line it removes, pass Old Line; for an unchanged context line, pass both. Getting that wrong is the usual cause of a rejected inline comment. To post several review comments at once, and optionally approve in the same step, use Create Merge Request Review instead. See the documentationWritev0.0.1 -
Create Merge Request Review
actionSubmit 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 infailed, so check that array rather than assuming everything landed. Line numbers follow GitLab's diff rules:new_linefor a line the merge request adds,old_linefor 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 documentationWritev0.0.1 -
Get Issue
actionGets a single issue from repository. See the documentationRead-onlyv0.2.4
Triggers top 4 of 10
-
New Commit (Instant)
triggerEmit new event when a new commit is pushed to a branchInstantv0.1.4 -
New Branch (Instant)
triggerEmit new event when a new branch is createdInstantv0.1.3 -
New Project
triggerEmit new event when a project (i.e. repository) is createdv0.1.4 -
New Audit Event (Instant)
triggerEmit new event when a new audit event is createdInstantv0.1.4
MULTI-APP
Works with more apps
The combinations customers connect alongside these two — nothing here is limited to a pair.
REFERENCE
Toolkit details
- x-pd-app-slug
- github,gitlab
- Primary app
- GitHub (github)
- Second app
- GitLab (gitlab)
- Authentication
- OAuth + OAuth
- Available actions
- 76
- Available triggers
- 37