Atlassian put six tool routes on cards.
Atlassian says its MCP V2 rollout now gives rich UI cards to five Jira tools and one Confluence search tool. The Jira list includes reads, searches, issue creation, edits, and transitions. Atlassian says the rollout is gradual and directs customers who still lack the cards after October 23 to support.[1]
The important change is not decoration. Search results, issue details, edit forms, and transition controls can now appear inside the conversation that called the tool. A reader can inspect or act without opening a separate application window.
The card is part of the route. It is not the receipt.
The tool and the interface are different objects.
The MCP Apps extension joins two things. A tool description points to a ui:// resource through _meta.ui.resourceUri. The host fetches that HTML resource, renders it in a sandboxed iframe, and moves messages between the app and host through a JSON-RPC channel built on postMessage.[2]
This split matters during review. The tool schema defines an operation. The UI resource defines what the user sees and can select. The host decides which app capabilities and tool calls it allows. The server decides whether a call changes Jira or Confluence. A visual state in one layer does not prove the next layer accepted it.
Sandboxing answers one security question.
The MCP Apps documentation says a host can isolate third-party HTML from the parent page, cookies, local storage, and parent navigation. The same documentation says the app can request tool calls through the host bridge. Isolation limits where the card can reach in the host. It does not decide which Jira project may change, which transition is allowed, or whether a person approved the exact arguments.[2]
The core MCP tools specification keeps that authority question visible. Tools are model-controlled, but the specification says applications should show exposed tools, mark invocations, and present confirmation prompts so a person can deny operations.[3]
Inspect five records for a write card.
- Record the exact tool name and input arguments.
- Record the
ui://resource URI and the server that supplied it. - Name the host and the app capabilities it granted.
- Show the proposed server-side change before dispatch.
- Keep the tool result, object ID, resulting state, and error status after dispatch.
For a read-only card, the last record is a fetch result. For an edit or transition card, it is a write receipt. Keep those states different in labels and logs. "Card rendered" belongs to the interface. "Transition accepted" belongs to the tool result. "Issue now has status Done" needs a readback from Jira.