Turn Jira tickets into GitLab MRs with Duo Agent Platform

Higher agent accuracy, lower token cost
Learn how to harden your software factory and let AI agents earn autonomy, without trading away security.
Stay updated with our latest features and improvements.
Published on: November 12, 2026
Learn how to build a custom Jira agent with GitLab Duo Agent Platform to manage your tickets and turn them into merge requests.
Many teams plan in Jira and ship in GitLab. Even if you already use GitLab Duo Agent Platform, you still open Jira to read each ticket, copy it into an agent for implementation, and report the merge request back.
This tutorial shows you how to remove that handoff. You add a Jira agent to Duo Agentic Chat. The agent knows your project and repository, and you use it to find, create, and update tickets. Then you hand a ticket to Developer Flow with /goal, and Developer Flow creates the merge request.
Watch the short demo first: A custom Jira agent finds the urgent tickets, one goes to Developer Flow, and the merge request shows up on the Jira ticket.
Note: The Atlassian MCP server in the AI Catalog is an experiment and isn't ready for production use. Try it on a test project first.
Here are the steps to follow to turn Jira tickets into GitLab merge requests.
This is GitLab's standard Jira integration. It makes any MR that mentions a ticket, for example KAN-123, show up on that Jira ticket, and posts a comment there. Five minutes, done once per project.
Reference: Jira issue integration.
GitLab Duo Agent Platform lets you create custom agents right in the UI. Give the agent a name, a prompt, and tools through an MCP server. We'll call ours Jira, with a prompt tuned for triage, summaries, and ticket hygiene, and the Atlassian MCP server for the tools to act on Jira.
Setup takes about 10 minutes: create the agent once, enable it in any project that needs it, and each person connects their own Atlassian account in Step 2.3. Creating the agent publishes it to the AI Catalog automatically. In its configuration you choose the managing project, and only Maintainers and Owners of that project can edit the agent. Deleting an agent requires an administrator. Its visibility decides which projects can enable it: a Private agent can't be shared with other projects, a Restricted agent can be used by anyone in the managing project's top-level group, and a Public agent can be viewed and used by anyone. Creating an agent does not make it available anywhere, though: You enable it separately in each project that should use it, including the managing project, in Step 2.2 Section 5.
Go to admin.atlassian.com and pick the organization that owns your Jira site (if you have more than one, the right org lists your Jira site under Apps > Atlassian apps). In the left sidebar, select Connectors > Atlassian MCP server, then Add domain and enter https://gitlab.com/**. You need Atlassian organization admin rights for this page. Without it, the OAuth step in 2.3 fails because Atlassian refuses GitLab as an MCP client. Reference: Control Atlassian MCP server settings.
Atlassian Administration's Connectors > Atlassian MCP server page, with https://gitlab.com/ added as a trusted domain
The AI > Agents page, with New agent highlighted
The Jira agent's configuration page, showing the Custom type, the system prompt, and the Atlassian MCP server selected 5. Enable the agent for any project that should use it: open the AI Catalog, find Jira, select Enable, and choose the project.
The project's AI > MCP servers page, with the Atlassian row and its Connect button
Each person who uses the agent connects once with their own Atlassian account, so Jira comments appear under their name, not a bot's name.
Reference: MCP servers in the AI Catalog, custom agents.
The agent calls the Atlassian searchJiraIssuesUsingJql tool (approve it when asked) with a query it writes itself, roughly project = KAN AND assignee = currentUser() AND priority in (High, Highest) AND statusCategory != Done ORDER BY created ASC, and answers with a short table.
Agentic Chat with the Jira agent selected, showing the approved tool calls and the resulting table of high-priority issues
Steer it like a colleague: "only bugs", "anything about the checkout page", "what did the reporter say in the comments on KAN-123?". Each follow-up makes the agent query Jira again, so you can keep narrowing the results without opening Jira.
Ask the agent to brief you first:
If the summary is clear, hand it over. In the same chat, either select + > Goal to attach the Goal label, or start your message with /goal. Then type:
The Agentic Chat message box with the Goal label attached and Implement KAN-123 typed in
What happens, in order:
You can keep chatting while it runs. When the session page shows Finished, the MR is ready to review.
Once a goal starts, it has write access to Git and the GitLab API and runs without asking for approval on each action, so sending the goal text is the one human checkpoint.
Review the draft MR like any contributor's work. Nothing merges on its own.
If you send the Jira agent another message after the MR exists, it posts a summary comment on the ticket with the MR link. The Jira integration from Step 1 also adds a comment when the MR mentions the ticket key.
The implementation demo is the headline, but the agent earns its place in the dropdown through the small questions. All of these work with the prompt above and no extra setup:
Because the agent runs with your Atlassian login, it sees exactly the projects you see, and every comment is attributed to you.
One habit worth keeping: Each /goal is a full agent session that consumes GitLab Credits, so brief the agent well before you send it.
Try GitLab Duo Agent Platform today to convert Jira tickets into GitLab MRs. Start your free trial now.
No credit card required.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Start building faster today
See what your team can do wi