Improving JSM request quality with external LLMs (Rovo limitations & MCP feasibility)?

Tomislav Tobijas

[note: text might look AI-ish because I CBA with writing everything from scratch] 

Hi everyone 👋

I’ve been exploring ways to improve request quality and reduce agent effort in JSM (or CSM) by leveraging AI beyond native capabilities (e.g., Rovo / Virtual Agent).

While testing built-in features, I ran into a few limitations:

• Handling incomplete or ambiguous user inputs

• Limited ability to leverage external context (HRIS, historical requests, user attributes)

• Lack of proactive request enrichment before reaching agents

To be clearer, I'm looking at how to resolve the following requirement: Leveraging AI to minimize incomplete requests and agent effort 👈👈

 

💡 Potenital approach (high-level)

I started experimenting with a more extensible architecture using a third-party LLM + middleware layer (via APIs / MCP).

Conceptually, the flow looks like this:

In short:

1. User submits a request (potentially outside Atlassian)

2. Middleware enriches the prompt with external data (HRIS, past tickets, etc.)

3. LLM generates a structured, complete request

4. Request is created in JSM

5. Optional feedback loop for continuous improvement

 

❓Now, the questions

I’d love to validate how feasible this is within the Atlassian ecosystem and what constraints I might be missing.

Specifically:

• Has anyone implemented something similar using Rovo MCP or external LLMs?

• Any specific limitations of MCP for third-party AI integrations (for this scenario)?

• Would this require all end users to have Atlassian accounts, or would portal-only accounts also work?

• Any performance or cost trade-offs worth calling out?

Would really appreciate any insights, examples, or lessons learned 🙏

Cheers,
Tobi

---

Fyi — I briefly discussed this with an Atlassian PM, and one suggestion was leveraging Slack ↔ JSM integration for intake (i.e. users submitting requests via Slack, which then creates tickets in JSM).

This makes sense from an entry-point perspective, but I’d still expect to need an AI layer in between.

Arkadiusz Wroblewski

@Tomislav Tobijas  Moin Moin

Nice diagram. The overall idea looks solid to me.

The main thing I would separate here is who is calling the API versus who the request is being created for.

On the JSM side, creating a request on behalf of a customer is possible with raiseOnBehalfOf, so the request can still be opened for a portal customer. But the account making that API call is not just a portal-only customer account. In practice, that needs to be an account with the right JSM access, typically an agent/admin-capable one.

About external...

your middleware authenticates with a dedicated service account, creates the request through the JSM API, and uses raiseOnBehalfOf to set the actual end user as the reporter.

That way, the external user does not need to be a full licensed Jira user. They would just need to exist as a valid customer in the portal/customer setup.

Where I would be a bit careful is the MCP part.

The JSM API itself supports this model, but I would not state too strongly that the current Atlassian MCP server already exposes that exact flow. From the current public docs, the JSM-related MCP tooling still looks fairly limited, so that part is the one I would leave a bit open unless someone has tested it recently.