Jira MCP With GitHub Copilot in VS Code

To use Jira from GitHub Copilot, add the Atlassian Rovo MCP Server to VS Code and use it from a Local session in the Chat view, with Agent selected. VS Code’s Copilot harness↗ (opens in a new tab) can currently reach only local MCP servers that don’t need authentication, and Atlassian’s server is remote with an OAuth sign-in. The server is hosted by Atlassian at https://mcp.atlassian.com/v2/mcp. The quick route is the Extensions view: search for @mcp Atlassian, pick the Atlassian server from the gallery and select Install. The manual route is a .vscode/mcp.json file with that URL as an http server. Either way VS Code opens Atlassian’s consent screen in your browser, you approve, and Copilot can then search Jira with JQL, read work items, and create, transition and comment on them with your own Jira permissions. VS Code asks before each tool call until you tell it otherwise, so the setup worth thinking about is what you let run unattended.

This guide covers VS Code and Copilot only. What the server’s Jira tools cover, and which groups are off by default, is in what the Jira MCP server can do. The same setup in other clients is in Jira MCP in Cursor and Jira MCP with Claude Code.

Before you start

• A Jira site on Atlassian Cloud. The Rovo MCP Server is a cloud service, so Jira Data Center and Server are not covered.
• VS Code with GitHub Copilot signed in. GitHub’s instructions↗ (opens in a new tab) have you select Agent in the Copilot Chat box to reach MCP servers and their tools.
• If your Copilot seat is Copilot Business or Copilot Enterprise, an admin controls MCP through a policy called MCP servers in Copilot. GitHub says the policy is disabled by default and applies only to those plans, and it can limit Copilot to a registry↗ (opens in a new tab) of approved servers. On an individual plan it does not apply.
• On the Atlassian side, the organisation must allow the client. Atlassian’s list of supported client domains includes vscode.dev for VS Code; an organisation admin can block it, or add it back, under Rovo MCP server domain settings.

Option 1: install from the MCP gallery

1. Open the Extensions view (Ctrl+Shift+X, or Cmd+Shift+X on a Mac) and type @mcp Atlassian in the search box.
2. Select the Atlassian server and choose Install. It appears under MCP Servers - Installed in the same view.
3. Start the server when VS Code offers to. The first start shows a trust dialog with a link to the server’s configuration; check that the URL is mcp.atlassian.com, then trust it.
4. Your browser opens on Atlassian. Sign in, choose the site, read the access requested, and approve.

This is the route Atlassian’s getting-started guide↗ (opens in a new tab) gives for VS Code, and it installs the server in your user profile, so it is available in every workspace you open.

Option 2: a .vscode/mcp.json file

To keep the setup with a repository, add a workspace file. VS Code’s MCP configuration reference↗ (opens in a new tab) describes .vscode/mcp.json with a top-level servers object; a remote server needs a type and a url:

{
  "servers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v2/mcp"
    }
  }
}

Commit the file and everyone who opens the repository gets the server, but each person still signs in as themselves and sees only what their own Jira account can see. VS Code also reads a portable .mcp.json at the workspace root, which uses the mcpServers key that other clients use, if your team keeps one file for several editors. For a server in your user profile instead, run MCP: Open User Configuration from the Command Palette. Older guides use /v1/sse or an mcp-remote bridge; Atlassian’s current address is /v2/mcp, used directly.

Signing in, and when it is blocked

Run MCP: List Servers, choose atlassian and start it. VS Code handles the OAuth sign-in for you: it registers itself with Atlassian’s sign-in service, opens the browser, and stores the token once you approve. There is no client ID to create and nothing to paste.

• If the consent step says your organisation admin must authorise access from this redirect URL, the client is not allowed. An Atlassian organisation admin fixes it in Atlassian Administration, under Rovo, then Rovo MCP server, then Domain settings.
• If the server starts but shows no tools, run MCP: Reset Cached Tools and start it again.
• To see what went wrong, run MCP: List Servers, choose the server and select Show Output. Connection and sign-in errors show in its log.
• If you declined the trust dialog by mistake, MCP: Reset Trust asks again.

Check it works

In the Chat view, choose Local as the session target, pick Agent, and select Configure Tools in the chat input; which harness reads which configuration is in the .vscode/mcp.json guide. The Atlassian server should be listed with its tools, and you can switch individual tools off there. Then start with reads: “Which Atlassian sites can you see, and who am I signed in as?” That uses atlassianUserInfo and getAccessibleAtlassianResources, which are always available. Then something real: “List the open bugs assigned to me in project PAY and show me the JQL you used.” An empty answer usually means the wrong site, since the sign-in grants access to the sites you picked on the consent screen.

The list will look short. The server exposes a few primary tools such as searchJiraIssuesUsingJql, getJiraIssue, createJiraIssue and transitionJiraIssue, and the agent finds the rest through discover and runs them through executeRead, executeWrite or executeDestructive, grouped by risk. The full breakdown is in what the Jira MCP server can do.

Prompts that fit a coding session

• “Read PAY-412 and its comments, find the code involved in this repository, and propose a fix. Do not change the issue.”
• “Create a bug in PAY for the failing test in billing/retry.spec.ts, with the error and the file in the description.”
• “I have fixed PAY-412 in the last commit. Add a comment with the commit hash and a one-line summary, then move it to Done.”

The first is a read and the other two are writes, so you will be asked before the second and third run. Ask Copilot to name the work item it changed each time, so you can check it in Jira.

Tool approvals: what to let run

When agent mode wants to call an MCP tool, VS Code shows the call and its arguments and lets you approve a single use, or approve for the session, the workspace, or all future calls. The approval settings↗ (opens in a new tab) sit behind Chat: Manage Tool Approval, which groups tools by source; each MCP server has a top-level checkbox that trusts all its tools at once.

• Approve reads for the workspace: atlassianUserInfo, getAccessibleAtlassianResources, searchJiraIssuesUsingJql, getJiraIssue, and discover.
• Keep writes on ask: createJiraIssue, transitionJiraIssue and executeWrite. Never tick the server-wide checkbox for Atlassian, since it would let writes and executeDestructive through.
• Think before approving executeRead. It lets any deferred read run without asking, which may be more than you meant.
• The permission picker in the chat input also offers Assisted permissions, where a model judges each call, and Allow all. VS Code warns that Allow all and Autopilot skip confirmation for destructive actions, including external tool calls. Neither suits a connection that can change Jira.
• Changed your mind? Chat: Reset Tool Confirmations clears every saved approval.

The reasoning behind these defaults, and what an organisation can enforce centrally, is in MCP security in VS Code.

Using a token instead of a sign-in

For a machine without a browser, Atlassian accepts token authentication instead of OAuth, but only if an organisation admin has turned it on. A personal API token goes in a Basic header as your email and token, base64-encoded; a service account key goes in a Bearer header. In VS Code, keep the value out of the file with an input variable, which prompts you for it instead of holding it in the file:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "atlassian-basic",
      "description": "base64 of email:api_token",
      "password": true
    }
  ],
  "servers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v2/mcp",
      "headers": {
        "Authorization": "Basic ${input:atlassian-basic}"
      }
    }
  }
}

Atlassian lists the trade-offs↗ (opens in a new tab): code search and Teams tools need OAuth, a token is not bound to one site so the agent has to pass the site’s cloud ID where a tool needs it, and token connections are governed by IP allowlists rather than domain settings. Never put the token itself in a committed file.

What admins control

• GitHub: for Copilot Business and Enterprise, the MCP servers in Copilot policy at enterprise or organisation level, off until an admin enables it, and an optional registry that limits Copilot to approved servers.
• Atlassian: which client domains may sign in, whether API tokens are allowed, IP allowlists, which tool groups are switched on, and the audit log. Atlassian’s advice is least privilege and a review of high-impact changes before confirming them.
• Rovo credits: some calls, such as Rovo search, use credits from the organisation’s pool, so an admin may be watching usage.

If the board is the point

Jira over MCP gives Copilot all of your Jira rights on every site you approve. If your team would rather give Copilot a seat on one simpler board, fenbs connects to VS Code the same way, with an http entry in .vscode/mcp.json and a browser sign-in. Copilot holds your role narrowed by the scopes you tick, works across four lanes, To Do, Next Up, In Progress and Completed, and every change is recorded with its name. The steps are on connecting GitHub Copilot to fenbs, and the fair comparison is fenbs vs Jira.