Team-connected Atlassian MCP not available inside scheduled Automation (cloud) runs

[Ivaylo_Kostov]

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

A scheduled Cursor Automation (Team Owned) cannot access the Atlassian/Jira MCP at
runtime, even though the Atlassian MCP is fully connected for cloud. Every documented
prerequisite is satisfied, but automation runs report the Atlassian tools as unavailable
and cannot fetch Jira data.
Environment / configuration (all verified):

• Automation type: scheduled (cron, weekly), scope = Team Owned.
• Team MCP Servers: “Atlassian” = Connected, endpoint https://mcp.atlassian.com/v1/mcp (HTTP).
• Customize → MCPs → atlassian (Plugin): “40 tools, 4 resources enabled”;
  scopes show BOTH Local: Connected and Cloud: Connected.
• Integrations: Jira = Connected (JIRA - KADANZA).
• “Wait for MCP Authentication” is ON.
• The Atlassian MCP tool is enabled on the automation itself.
• Atlassian OAuth was re-authenticated prior to the run.
  Expected:
  The scheduled automation run can call the Atlassian/Jira MCP tools and fetch issue
  statuses/summaries.
  Actual:
  Every run reports “no Atlassian/Jira MCP was available this run” / tools not exposed.
  The agent successfully reads the repos and extracts Jira keys (e.g. 45 keys on platform-be,
  26 on platform-fe) but cannot call Atlassian, so it falls back to commit-derived summaries
  and cannot compute status buckets.
  Repro:

1. Connect Atlassian as a Team MCP server (Cloud scope Connected) + Jira integration.
2. Create a Team Owned scheduled automation with the Atlassian MCP tool enabled.
3. Run it (scheduled or manual).
4. Observe: Atlassian tools are not available during the run.
   Hypothesis / question:
   Does a Team Owned automation execute under a shared service-account identity that does
   NOT inherit the team’s Atlassian OAuth at runtime? If so, how do we authenticate the
   Atlassian MCP for that service-account identity? This step is not documented.
   Please advise on the fix or confirm whether this is a bug.
   Attachments to include: run ID(s) of the failed runs, and screenshots of the
   Cloud-scope “Connected” state.

Steps to Reproduce

Create an configure an automation, execute the run.

Expected Behavior

I expect the automation to be able to fetch the ticket statuses from JIRA.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Cursor version 3.9.16

Additional Information

Test run id: bc-703413f9-f4ac-4834-a13e-af2b192aa1ff

Does this stop you from using Cursor

No - Cursor works, but with this issue

[kevinn (Kevin Neilson)]

Thanks for the detailed report and screenshots. I checked the run you shared, and this was not caused by service-account OAuth.

The supplied automation was running as a Private, user-owned automation rather than team-owned. Your Atlassian authentication was working in another cloud run shortly beforehand.

The failure happened earlier in setup: the automation had saved a lowercase atlassian reference, but the connected server is Atlassian. The runtime could not match that saved reference, so it never reached authentication.

As a workaround:

1. Open the “Weekly repo change digest” automation.
2. Confirm its permission scope. The supplied run was Private, not Team Owned.
3. Remove the existing Atlassian MCP entry from the automation’s Tools section.
4. Re-add Atlassian from the MCP picker, then save.
5. If you change the automation to Team Owned, authenticate Atlassian from the automation’s own MCP row.
6. Run another test.

The “Wait for MCP Authentication” setting does not affect this failure because the server was not resolved in the first place.

If it still fails after re-adding the server, please share the new run ID.

[Ivaylo_Kostov]

@kevinn

t plac

Thanks for the reply and assistance on the subject.

Sharing the automation with the team, removing the Atilassian MCP, saving and adding it again did the trick (on the second try).

The topic can be considered as closed.