Both servers hand the real query language through, which is what makes them useful for anything beyond looking up one ticket: the assistant can express the filter precisely rather than guessing at a search box. They are two processes with two credential sets, so register both if you want work to move between a ticket and the page that documents it.
A Python project holding two separate MCP servers, one for Jira and one for Confluence, each launched independently and registered separately in your client.
- Jira: `jira_search_issues` by JQL, `jira_get_issue`, `jira_create_issue`, `jira_update_issue`, `jira_add_comment`, `jira_transition_issue` and `jira_get_projects`
- Confluence: `confluence_search_content` by CQL, `confluence_get_page`, `confluence_create_page`, `confluence_update_page`, `confluence_delete_page`
- Confluence structure tools too: `confluence_get_spaces`, `confluence_get_page_children` and `confluence_add_attachment`
- Worked call examples for search, creation, transition and page update
`uv sync`, then credentials per product: `JIRA_URL`, `JIRA_USERNAME`, `JIRA_API_TOKEN` and `JIRA_CLOUD`, and the matching `CONFLUENCE_` set. Set the cloud flag to true for Atlassian Cloud, false for Server. Register both servers in the client, each pointing at its own shell script in the project root.
One command plus a key — uvx jira-mcp, then supply credentials