I am the site administrator for my Atlassian organization. I am attempting to use the Atlassian Rovo MCP server connector with xAI Grok (console.x.ai / grok.com).
All user-facing configuration steps have been completed successfully on both the Atlassian and xAI sides:
It specifically tells me when setting up the connector that it has completed successfully in Grok after I click on the Atlassian page that pops up and asks me to grant it access for my domain.
Despite the above, every tool call from Grok (specifically trello___getAccessibleAtlassianResources and trello___atlassianUserInfo) continues to return the identical error:
“We couldn't verify your connection settings. Please contact your administrator for assistance.”
This error persists after multiple re-authentication cycles and a full wipe/re-add. Front-end configuration on both platforms appears complete and correct. The failure appears to be occurring in the backend token verification / resource handshake between xAI and Atlassian.
Can anyone help point me in the right direction?
I have attempted to inspect organization-level connection state, any cached tokens, or policy that may be blocking the verified Rovo MCP integration with the console.x.ai / grok.com domains. As this is a Free-plan workspace I do not appear to have access to the deeper organization controls or the ability to open a formal support ticket.
Thanks in advance to anyone who takes the time to read through this and attempt to help,
Josh
Community moderators have prevented the ability to post new answers.
Hi @Natural Muse, neither console.x.ai nor grok.com is on Atlassian's allowed-domain list, and that list is one of the stated preconditions: "For a tool call to succeed, all of the following must be true: If the tool is using OAuth 2.1, its domain is allowed in the Atlassian Rovo MCP server domain settings."
I pulled the published list this morning. chatgpt.com, claude.ai, claude.com, vscode.dev, cursor://cursor.mcp, localhost and about thirty more, with no xAI property anywhere in it. Only that set is allowed automatically, so a Grok connector needs the origin added by hand.
Which is probably where naturalmuse.com comes in. A verified domain is your org proving it owns its mail domain, for claiming accounts. The MCP list is a separate screen and it wants the AI client's origin, so verifying yours has no effect on a redirect arriving from console.x.ai. Atlassian Administration, Rovo, Rovo MCP server, Add domain, and put in both console.x.ai and grok.com with the protocol on the front, since patterns without one get rejected. If it saves and nothing changes, delete the entry, re-add the identical string, save, then run the OAuth again in a private window. Atlassian's KB documents that exact state: "the domain may appear correctly in the Admin UI but may not have fully committed to the backend enforcement service."
On the deeper org controls, you're already standing on that screen, since the Permissions counts and the Authentication tab both live there. The platform FAQ also puts Free inside the tent: "All Atlassian Cloud customers have access to the Atlassian Rovo MCP server", metered at 500 calls an hour on Free. If Add domain is greyed out for you anyway, say so here, because no page I can find states a plan tier for that button.
Some of what you checked is genuinely clean, so leave it alone. Your 8/8 Read and 8/8 Write will include read_trello and write_trello, which is the org-level allow for Trello. The Authentication tab is "not relevant to Trello MCP" in Atlassian's own words.
What I can't tell you is why consent completes. The one place Atlassian documents a clean consent screen followed by failing tool calls is the IP allowlist, not the domain list, so hold my theory loosely. And the success you're seeing is xAI's own message, so I wouldn't read it as Atlassian confirming the handshake.
Check which URL that connector points at too, because it decides whether any of this reaches your boards. On mcp.atlassian.com, Trello data won't come back even once the domain is allowed: "In a future release, Trello data may also be available through the Atlassian Rovo MCP server for customers who use Trello alongside other Atlassian products." Trello's own server is https://mcp.trello.com/v1, on any plan.
https://support.atlassian.com/trello/docs/connect-trello-to-ai-assistants-with-trello-mcp/
Thank you so much for your response, insight, and the information you've provided. Very useful. I will run some tests as soon as I can and will update either way. I appreciate your help on this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Following your guidance I deleted and re-added both domains under Rovo → Rovo MCP server → Your domains:
Permissions tab shows Read 8/8, Write 8/8, Search 3/3 (all Allowed, including new toolsets). Authentication tab left at defaults (API token and enterprise managed auth both off).
I then fully disconnected the previous connector, re-added the custom MCP in the Grok Business console with:
OAuth consent succeeds. The connector appears as Connected on grok.com/connectors and lists the server URL correctly.
However, every tool call still fails. The foundational call trello___getAccessibleAtlassianResources returns exactly:
“We couldn’t verify your connection settings. Please contact your administrator for assistance.”
Also notable: the tools that surface under the connected “Trello” connector are Rovo-style tools (addCommentToJiraIssue, createCompassComponent, addTeamworkGraphContext, etc.) rather than pure Trello board/list/card tools.
Is it possible to test/check the backend verification for the organization naturalmuse.atlassian.net? The front-end configuration and domain allowlist now appear correct, but the post-consent resource/cloud-ID verification step is still failing.
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for running all of that properly. I got the emphasis wrong last time: the domain allowlist was a real precondition, not the blocker, and I handed it over as though clearing it would be the fix.
The tell is in what you posted. addCommentToJiraIssue, createCompassComponent, addTeamworkGraphContext. That is the Rovo toolset, and it matches Atlassian's published coverage. The official server's own README describes it as a bridge to Jira, Confluence, Jira Service Management, Bitbucket and Compass. Trello is not in that list. The word trello does not appear in that README, so the board, list and card tools you have been waiting for are not served there, and getting the handshake to pass would not have produced them.
The endpoints Atlassian documents are mcp.atlassian.com/v1/mcp/authv2, recommended for most clients, and mcp.atlassian.com/v1/mcp for API token setups. Their supported client table lists ChatGPT, Claude, Cursor, VS Code with Copilot, Copilot CLI and Gemini CLI. Grok and xAI are not on it. Not listed is not the same as blocked, so I would not read that as something you did wrong, but nobody has published that this pairing works either.
I checked mcp.trello.com/v1 before writing rather than assuming. It is live and returns a 401, as the Atlassian endpoint does. So the URL is not what I am flagging. What came back through it was the Rovo tool surface.
What I would do next splits the two remaining causes. Set the same connector up in Claude or ChatGPT, pointed at the same org. Fails there too, same message? Atlassian side, and you have a clean support case with a supported client sitting in the evidence. Works there? Then the allowlist was not your problem and the gap is the Grok connector, which is a question for xAI rather than any screen in your admin.
Your permissions, domains and consent are clean at this point. I would stop re-checking those.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.