Overview
This playbook covers how to connect Jira to your AI coding agent alongside CoreStory’s MCP server, and what you can do once both are connected. Jira becomes the intake and output layer — the agent pulls ticket details from Jira, uses CoreStory’s code intelligence to understand the codebase, does the work, and pushes results back to the ticket. CoreStory doesn’t have a native Jira plugin. The integration works through MCP: your AI coding agent connects to both the CoreStory MCP server and a Jira MCP server, and orchestrates between them. This means any MCP-capable agent (Claude Code, GitHub Copilot, Cursor, Windsurf, Factory.ai) can work with both systems in a single session. What this unlocks:- Resolve Jira tickets — pull a bug or feature ticket, use CoreStory to investigate the codebase, implement a fix or feature, update the ticket with results
- Enrich Jira tickets — take a vague or under-specified ticket and add architectural context, acceptance criteria, and implementation guidance using CoreStory intelligence
- Draft new Jira tickets — discover something in the codebase via CoreStory (a missing test, a code smell, a dependency risk) and create a well-structured Jira ticket for it
- Triage and estimate — use CoreStory to assess ticket complexity, identify affected files, and estimate implementation scope before sprint planning
How It Works
The CoreStory + Jira integration runs through your AI coding agent. The agent connects to two MCP servers simultaneously and orchestrates between them:| Component | Role |
|---|---|
| Jira MCP Server | Intake and output — read tickets, post comments, create issues, transition statuses |
| CoreStory MCP Server | Code intelligence — query architecture, identify relevant files, understand patterns and dependencies |
| AI Coding Agent | Orchestrator — pulls from Jira, queries CoreStory, implements changes, writes back to Jira |
| Tool | Purpose |
|---|---|
create_conversation | Start a new CoreStory session for the ticket’s codebase area |
send_message | Query architecture, patterns, file locations, and dependencies |
get_project_prd | Pull product requirements for context on feature tickets |
get_project_techspec | Pull technical specs for implementation guidance |
list_projects | Identify which CoreStory project maps to the Jira ticket’s codebase |
| Capability | Used In |
|---|---|
| Read tickets (summary, description, fields, comments) | All workflows |
| Post comments | Resolve, Enrich |
| Create issues | Draft |
| Transition statuses | Resolve |
| Update fields (labels, assignee, custom fields) | Resolve, Enrich |
| Query project metadata | Triage |
Prerequisites
Required:- A CoreStory account with at least one project that has completed ingestion
- The CoreStory MCP server connected to your AI coding agent (see the CoreStory MCP Server Setup Guide)
- A Jira instance — Jira Cloud (required for Atlassian’s official Rovo MCP Server) or Jira Server/Data Center (requires a community MCP server)
- Authentication credentials — either an Atlassian account for OAuth (Rovo) or a Jira API token (community servers, generated from id.atlassian.com/manage-profile/security/api-tokens)
- A code repository the agent can read and write to (required for resolve and implement workflows)
- Agent-specific configuration files (skill files, custom instructions, project rules) — covered in the Agent Configuration section below
Jira MCP Server Setup
The Jira MCP server gives your AI agent the ability to read tickets, create issues, post comments, and transition statuses. There are two approaches: Atlassian’s official Rovo MCP Server (recommended for Jira Cloud) and community-maintained MCP servers (for self-hosted Jira or when you need more control).Option A: Atlassian Rovo MCP Server (Recommended)
The Atlassian Rovo MCP Server is Atlassian’s official, cloud-hosted MCP server. It’s now generally available and supports Jira, Confluence, and Compass. Authentication uses OAuth 2.1 — you’ll sign in with your Atlassian account through a consent screen, and access is scoped to your existing Jira permissions. Requirements: Jira Cloud instance. Rovo MCP does not support Jira Server or Data Center. Setup varies by agent — see the Agent Configuration section below for specifics. The general pattern: For agents that support remote/HTTP MCP servers natively (Claude Desktop, newer Cursor builds, VS Code), point to the Rovo endpoint:mcp-remote:
Option B: Community MCP Servers
If you’re on Jira Server/Data Center, or prefer API token auth with a locally-running server, use a community-maintained Jira MCP server. The most actively maintained options:| Package | Install | Auth | Notes |
|---|---|---|---|
| mcp-atlassian | pip install mcp-atlassian | API token | Python. Supports Cloud + Server/Data Center. Covers Jira and Confluence. |
| @mcp-devtools/jira | npx @mcp-devtools/jira | API token | Node.js. Jira-focused. Search, create, update issues. |
mcp-atlassian (Python):
Verify the Connection
After configuration (either option), ask your agent:Permissions
Whether using Rovo or a community server, the agent can only see and modify what your account can access. For most workflows, you need:- Read access to the projects you want to pull tickets from
- Write access if you want the agent to post comments, update fields, or transition statuses
- Create access if you want the agent to draft new tickets
Workflows
These workflows use both the CoreStory and Jira MCP servers together. The prompts are agent-agnostic — they work with any MCP-capable agent that has both servers connected.Workflow 1: Resolve a Jira Ticket
This is the primary workflow. Pull a ticket, use CoreStory to understand the codebase, implement a solution, and update the ticket. This workflow maps directly to the six-phase process described in the Bug Resolution and Feature Implementation playbooks — the only difference is that Jira is the ticket source. Start the workflow:- Pull the ticket from Jira — extracting the summary, description, acceptance criteria, priority, labels, and any linked issues
- Create a CoreStory conversation to investigate the relevant codebase
- Query CoreStory to understand the architecture, identify relevant files, and plan the implementation
- Implement the fix or feature using test-driven development
- Update the Jira ticket with an implementation summary, files changed, and test results
- Transition the ticket status (if configured) — e.g., move from “In Progress” to “In Review”
Workflow 2: Enrich a Jira Ticket
Use CoreStory to add architectural context and implementation guidance to under-specified tickets. This is useful before sprint planning, when handing tickets to other developers, or when a ticket needs more detail before it’s actionable. Start the workflow:- Pull the ticket from Jira
- Query CoreStory about the feature area — architecture, patterns, relevant files, data structures, and historical context
- Post a structured comment to the Jira ticket with its findings
Workflow 3: Draft New Jira Tickets
Use CoreStory to discover issues in the codebase and create well-structured Jira tickets for them. This is useful during code reviews, tech debt audits, or when onboarding to a new codebase. Start the workflow:- Query CoreStory about the specified area
- Identify actionable items — missing tests, security gaps, code quality issues, documentation gaps
- Create Jira tickets with structured descriptions, suggested priority, and relevant context from CoreStory
Workflow 4: Triage and Estimate
Use CoreStory to assess ticket complexity before sprint planning. The agent reads the ticket, queries CoreStory about the affected code, and provides an implementation assessment. Start the workflow:- Pull the ticket details from Jira
- Query CoreStory about the affected code area — files, complexity, dependencies, test coverage
- Provide an assessment including: estimated complexity, files likely affected, dependencies and risks, and suggested approach
Agent Configuration
Claude Code
1. Connect CoreStory MCP server:- Claude Code’s skill files can reference both CoreStory and Jira MCP tools. The Bug Resolution and Feature Implementation skill files already support Jira ticket intake — they detect ticket IDs in the format
JIRA-1234orPROJ-123. - For team-wide configuration, commit MCP settings to
.claude/settings.jsonin version control.
GitHub Copilot
1. Connect CoreStory MCP server in your VS Code MCP configuration (Settings → MCP Servers, or edit the JSON config directly). 2. Add Jira MCP server — Option A (Rovo, recommended for Jira Cloud): VS Code supports remote MCP servers. Add the Rovo endpoint:pip install mcp-atlassian first.
3. Verify by asking Copilot Chat (in agent mode): “List Jira projects” and “List my CoreStory projects.”
Tips:
- Copilot’s agent mode is required for multi-step workflows that use both MCP servers.
- The
.github/copilot-instructions.mdfile can reference Jira workflows. If you’re using the custom instructions from the Feature Implementation or Bug Resolution playbooks, they already support Jira ticket intake. - Copilot can use both prompt files (
.github/prompts/) and custom instructions to learn Jira-specific workflows.
Cursor
1. Connect CoreStory MCP server in Cursor’s MCP settings (Settings → MCP Servers, or edit the MCP config JSON directly). 2. Add Jira MCP server — Option A (Rovo): Newer Cursor builds support remote MCP servers natively via the MCP settings panel. Add the Rovo endpoint URL:https://mcp.atlassian.com/v1/sse. For older Cursor builds, use the mcp-remote proxy in ~/.cursor/mcp.json:
- Cursor rules in
.cursor/rules/can reference Jira-specific workflows. If you’re using the rules from the Bug Resolution or Feature Implementation playbooks, they already support Jira ticket intake. - For team-wide Cursor MCP configuration, use the project-level MCP settings file.
Windsurf
1. Connect CoreStory MCP server in Windsurf’s MCP settings. 2. Add Jira MCP server — Option A (Rovo): Add the Rovo endpoint in Windsurf’s MCP settings:https://mcp.atlassian.com/v1/sse. If Windsurf requires a local process proxy, use the mcp-remote approach from the Cursor section.
2. Add Jira MCP server — Option B (community server): Use the JSON block from the Jira MCP Server Setup section (Option B).
3. Verify by asking: “List Jira projects” and “List my CoreStory projects.”
Devin
1. Navigate to Settings → MCP Marketplace → “Add Your Own” 2. Add CoreStory MCP server with Transport TypeHTTP and Server URL https://c2s.corestory.ai/mcp. Add your CoreStory token as a secret and configure the Authorization: Bearer $API_TOKEN header.
3. Add Jira — Option A (Rovo): Add the Rovo endpoint as a remote MCP server: https://mcp.atlassian.com/v1/sse. Devin supports remote HTTP/SSE transport natively.
3. Add Jira — Option B (community server): Add as a custom MCP server with the mcp-atlassian command and configure Jira credentials as secrets.
4. Verify by asking Devin: “List Jira projects” and “List my CoreStory projects.”
Tips:
- Devin supports HTTP transport for remote MCP servers. Use HTTP for both CoreStory and Jira.
- Click “Test listing tools” after configuring each server to verify the connection before starting a session.
Factory.ai
1. Connect CoreStory MCP server in your Factory.ai environment. Verify with the/mcp command that CoreStory tools are accessible.
2. Add Jira MCP server to your Factory.ai MCP configuration.
3. Verify by asking: “List Jira projects” and “List my CoreStory projects.”
Tips:
- Factory.ai droids can use both CoreStory and Jira MCP tools. List both tool sets in the droid’s
toolsfrontmatter if you want to restrict tool access. - The Bug Resolution and Feature Implementation droids already support generic ticketing system intake, including Jira.
Tips & Best Practices
Start with “enrich” before “resolve.” If your team is new to the CoreStory + Jira workflow, start with Workflow 2 (Enrich). It’s read-only — the agent reads tickets and posts comments but doesn’t write code. This builds confidence before you move to autonomous ticket resolution. Use Jira labels to track AI-assisted work. Add a label likecorestory-assisted or ai-resolved to tickets the agent works on. This makes it easy to measure impact, audit AI-generated changes, and filter in Jira dashboards.
Match your Jira workflow statuses. If your team uses custom Jira workflow statuses (e.g., “QA Review” instead of “In Review”), tell the agent explicitly: “After implementing, move the ticket to QA Review.” The agent doesn’t know your workflow transitions unless you tell it.
One ticket per session for complex work. For bug fixes and feature implementations, give the agent one ticket at a time. The CoreStory conversation context builds throughout the session — mixing unrelated tickets dilutes the quality of architectural queries.
Batch operations are fine for lightweight workflows. Enrichment, triage, and ticket drafting can handle multiple tickets in a single session because they don’t require deep codebase context for each individual ticket.
Keep ticket descriptions actionable. The quality of the agent’s output is directly proportional to the quality of the input. A ticket that says “export is broken” produces worse results than one that says “CSV export returns 500 error when user has no profile photo — expected: export succeeds with empty photo field.”
Use linked issues. If a Jira ticket references other issues (blocks, relates to, duplicates), mention this to the agent. It can query CoreStory about related components and produce more comprehensive fixes.
Troubleshooting
“List Jira projects” returns an error or empty results. If using Rovo: verify the OAuth consent completed successfully — check your browser for any pending authorization prompts, and confirm your org admin has allowed the AI tool to connect. If using a community server: check three things — (1) theJIRA_URL is correct and includes https://, (2) the username/email matches the account that generated the API token, and (3) the API token hasn’t expired. Regenerate the token if unsure.
Agent can’t find a specific ticket.
Verify the project key is correct (e.g., PROJ in PROJ-1234). The Jira MCP server respects the account’s project permissions — if the account can’t see the project in Jira’s web UI, the agent can’t see it either.
Agent can’t transition ticket status.
Jira workflow transitions are governed by workflow rules. If the agent tries to move a ticket from “To Do” directly to “Done” but your workflow requires intermediate states, the transition will fail. Tell the agent the valid transitions, or check your Jira workflow configuration.
Agent can’t update custom fields.
Custom field IDs in Jira are opaque (e.g., customfield_10042). The agent may need to discover the field ID before updating it. Ask: “What custom fields are available on ticket PROJ-1234?” The Jira MCP server can list them.
API rate limiting.
Jira Cloud has API rate limits. If you’re doing batch operations (enriching 20+ tickets, triaging a full sprint backlog), you may hit limits. The agent will report rate limit errors clearly. Space out batch operations or reduce batch size.
CoreStory and Jira return conflicting information.
This usually means the Jira ticket describes one thing and the codebase has evolved since the ticket was written. CoreStory reflects the current state of the code. When in doubt, trust CoreStory for architectural questions and the Jira ticket for requirements and acceptance criteria.
“Permission denied” when posting comments or creating tickets.
The API token’s permissions are inherited from the Atlassian account. Verify the account has the necessary project role (at least “Developer” for comment and transition access, “Administrator” for workflow changes).