MCP server

Released MCP will be exposed through Forge MCP, allowing Atlassian Rovo and other compatible AI tools to work with Released data.

This page defines the first set of tools. Tool names and request fields may change while the MCP is being built, but the actions and safety rules below are the intended contract.

Authentication and access

Released MCP uses Atlassian authentication and authorization. When someone connects from an interactive AI tool, they sign in to Atlassian and approve access through an interactive consent flow. This follows Atlassian’s recommended OAuth 2.1 model for user-driven MCP connections.

Each tool call runs with the current Atlassian user’s access. It can only return or change Released content that user is already allowed to access. Authentication does not grant additional access or create a new Released role. If the user does not have permission, the tool returns a clear permission error rather than partial results.

For more detail, see Atlassian’s MCP authentication and authorization guidance.

Posts

Post tools manage release notes, changelogs, or announcements. Creating or editing a post does not publish it automatically.

Tool	What it does
`create_post`	Creates a draft post from supplied title and content, or a selected template, with optional Jira work items.
`get_post`	Returns one post, including its draft or published state.
`list_posts`	Lists posts for a workspace or channel, with filters for state and date.
`update_post`	Updates a post’s title, content, selected Jira work items, categories, versions, or other editable fields.
`delete_post`	Deletes a post after any required unpublish step.
`publish_post`	Publishes a post to the selected channel or channels, with the requested notification setting.
`unpublish_post`	Retracts a published post when it needs to be removed from its channels.

Publishing returns the channels where the post is live and the notification setting that was used.

Customer feedback

Feedback tools manage the feedback threads that appear in the Released inbox.

Tool	What it does
`create_feedback`	Creates a feedback thread for a workspace, optionally linked to a Jira work item or roadmap item.
`get_feedback`	Returns one feedback thread and its current status.
`list_feedback`	Browses individual feedback items using structured filters such as workspace, status, source, date, and linked work item.
`update_feedback`	Updates editable feedback details, including status and linked work.
`delete_feedback`	Deletes a feedback thread when the caller has permission to do so.
`query_feedback`	Answers an open-ended question by finding relevant feedback and identifying patterns.
`prepare_feedback_follow_up`	Creates a reviewable follow-up campaign for people who commented on or liked feedback related to a Jira work item.
`send_feedback_follow_up`	Starts an approved follow-up campaign in the background. Explicit confirmation is required.
`get_feedback_follow_up_status`	Returns a campaign’s progress and its sent, skipped, and failed recipients.

Feedback replies

Replies belong to a feedback thread. A reply tool must explicitly identify whether the reply is public or an internal note, so an AI tool cannot accidentally send an internal comment to a customer.

Tool	What it does
`create_feedback_reply`	Adds a public reply or internal note to a feedback thread.
`get_feedback_reply`	Returns one reply, including its visibility and author.
`list_feedback_replies`	Lists replies for a feedback thread in conversation order.
`update_feedback_reply`	Updates a reply when the caller has permission to edit it.
`delete_feedback_reply`	Removes a reply when the caller has permission to delete it.

Query feedback

Use query_feedback to answer an open question from feedback. Use list_feedback when you know the filters and want individual records.

Example request	Expected result
“What are customers finding difficult about onboarding?”	An answer based on relevant feedback, with evidence links and any inferred themes clearly labelled.
“What feedback is related to PROJ-123, including comments and likes?”	The relevant feedback, comments, and likes, with links back to the source records.

Results must be based on source feedback and distinguish direct evidence from inferred themes. The tool does not invent customer opinions or make changes.

Close the loop with customers

Use a follow-up campaign to tell customers who commented on or liked related feedback that work has shipped.

Example request	Expected result
“Prepare a follow-up for PROJ-123 and this shipped post.”	A reviewable campaign with the recipient count, one shared draft, personalised variants, representative samples, and exceptions.
“Send campaign `campaign_42` to its 120 recipients.”	A request for explicit confirmation of that exact campaign, recipient count, and version.
“How is campaign `campaign_42` going?”	Its background progress and sent, skipped, and failed recipients.

The shared draft is personalised from the customer’s feedback or follow. A campaign sends only after confirmation and then runs in the background.

Shared behaviour

List and query tools should support a result limit and cursor-based pagination. Responses should return stable IDs, URLs where available, and the current state of changed content. Mutating tools should confirm the action performed and return the changed record, rather than only reporting that it succeeded.