Provides tools for searching and retrieving Jira issues, comments, subtasks, and attachments, enabling AI agents to interact with Jira projects and tickets.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@copilot-jira-mcp Show me my assigned Jira tickets"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official MCP (Model Context Protocol) server for seamless Jira integration with GitHub Copilot CLI
Interact with Jira issues, search tickets, and manage your workflow directly from GitHub Copilot CLI using natural language!
🔍 Smart Search - Search Jira tickets using JQL or natural language
📝 Issue Details - Get comprehensive information about any ticket
💬 Comments - Read and analyze issue comments
🔗 Subtasks & Links - Navigate issue hierarchies
📎 Attachments - List and access issue attachments
👤 My Issues - Quick access to your assigned tickets
🚀 Fast & Lightweight - Minimal dependencies, maximum performance
🔐 Secure - Credentials stored safely in environment variables
🌍 Universal - Works with any Jira instance (Cloud or Server)
🎯 AI-Powered - Let Copilot understand and query your Jira naturally
Related MCP server: Jira Cloud MCP Server
Node.js 18 or higher (Download)
GitHub Copilot CLI (Setup Guide)
Jira Account with API access
# Install globally from GitHub
npm install -g git+https://github.com/GiDanis/copilot-jira-mcp.git
# Run interactive setup
npx jira-mcp setup# Clone repository
git clone https://github.com/GiDanis/copilot-jira-mcp.git
cd copilot-jira-mcp
# Install dependencies
npm install
# Run setup wizard
npm run setup
# Register with Copilot
npm run register# Install from NPM
npm install -g copilot-jira-mcpThe setup wizard will guide you through:
Jira URL - Your Jira instance URL (e.g., https://your-company.atlassian.net)
Email - Your Jira account email
API Token - Generate at Atlassian API Tokens
Credentials are stored securely in environment variables:
JIRA_URL
JIRA_EMAIL
JIRA_API_TOKEN
Once installed, simply open Copilot and use natural language:
copilotGet your tickets:
> Show me my assigned Jira ticketsSearch issues:
> Search Jira for open bugs in project IIAB
> Find all high priority tickets in sprint 23
> Show me tickets updated in the last weekGet ticket details:
> Get details for IIAB-12345
> Show me comments on ticket PROJ-789
> List subtasks for IIAB-456Advanced JQL:
> Search Jira with JQL: project = IIAB AND status = "In Progress"The MCP server exposes these tools to Copilot:
Tool | Description |
| Search issues using JQL |
| Get detailed ticket information |
| Retrieve all comments |
| List all subtasks |
| List attachments |
| Get your assigned tickets |
Your credentials are NEVER committed or shared!
✅ Stored in environment variables
✅ .gitignore prevents accidental commits
✅ No plaintext storage
✅ API tokens can be revoked anytime
Best Practices:
Generate dedicated API tokens (don't reuse)
Revoke tokens when not needed
Never share .env files
Use different tokens for different machines
See SECURITY.md for complete security guidelines.
Installation Guide - Detailed setup instructions
Configuration - Advanced configuration options
Usage Examples - More query examples
Troubleshooting - Common issues and solutions
Contributing - How to contribute
If you prefer manual setup:
# Set environment variables
[Environment]::SetEnvironmentVariable("JIRA_URL", "https://your-company.atlassian.net", "User")
[Environment]::SetEnvironmentVariable("JIRA_EMAIL", "your.email@company.com", "User")
[Environment]::SetEnvironmentVariable("JIRA_API_TOKEN", "your-token-here", "User")
# Restart terminal# Add to ~/.bashrc or ~/.zshrc
export JIRA_URL="https://your-company.atlassian.net"
export JIRA_EMAIL="your.email@company.com"
export JIRA_API_TOKEN="your-token-here"
# Reload shell
source ~/.bashrc # or ~/.zshrcEdit ~/.copilot/mcp.json:
{
"mcpServers": {
"jira": {
"command": "node",
"args": ["/path/to/copilot-jira-mcp/src/index.js"],
"env": {
"JIRA_URL": "${JIRA_URL}",
"JIRA_EMAIL": "${JIRA_EMAIL}",
"JIRA_API_TOKEN": "${JIRA_API_TOKEN}"
}
}
}
}Solution: Run the setup wizard:
npm run setupCauses:
Invalid API token
Incorrect email
Wrong Jira URL
Solution: Regenerate API token and run setup again.
Solution: Re-register the server:
npm run registerFor more help, see Troubleshooting Guide.
Contributions are welcome! Please see CONTRIBUTING.md for guidelines.
Areas we'd love help with:
🌐 Internationalization
📱 Additional Jira features (transitions, creating tickets, etc.)
🧪 Test coverage
📖 Documentation improvements
🐛 Bug fixes
MIT © 2026 Giuseppe Danise
See LICENSE for details.
Built with Model Context Protocol SDK
Inspired by the awesome GitHub Copilot CLI
Thanks to the Jira REST API team
If this project helps you, please give it a ⭐ on GitHub!
Issues? Report them here
Questions? Start a discussion
Made with ❤️ for developers who love automation
Recupera tutti i ticket assegnati all'utente corrente
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filtra per stato (es. "In Progress", "Open", "To Do") | |
| max_results | No | Numero massimo di risultati (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the primary action and scope but does not disclose read-only nature, default statuses, ordering, pagination behavior, or any authentication/rate-limit considerations. The max_results parameter hints at pagination but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose without any filler or repetition. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the core functionality. However, it lacks usage differentiation from siblings and does not describe the return format or default behavior, which could be important for an agent to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'status' and 'max_results'. The tool description adds no extra meaning beyond those schema definitions, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Recupera tutti i ticket assegnati all'utente corrente' (Retrieves all tickets assigned to the current user), specifying a concrete action and resource with scope. It distinguishes from siblings by focusing on current-user assignment rather than a single ticket (jira_get_ticket) or general search (jira_search_tickets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the siblings. The description does not mention alternatives or contexts where jira_search_tickets might be more appropriate, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recupera i dettagli di un ticket Jira specifico tramite la sua chiave (es. IIAB-81069)
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_key | Yes | La chiave del ticket Jira (es. IIAB-81069) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it retrieves details, implying a read-only operation, but does not disclose any additional behavioral traits such as error handling, required permissions, or side effects. The behavior is simple and inferable, so a 3 is appropriate—clear but not rich in context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains all essential information: the action, the target, and the parameter format. No filler or redundancy. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is complete. It tells the agent exactly what the tool does and what input is needed. The lack of output structure is not a gap because the tool's purpose is clear—returning ticket details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers the parameter fully (Key of the Jira ticket with example IIAB-81069). The tool description repeats the same example, adding no new semantic value beyond what the schema provides. Since schema coverage is 100%, baseline 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Recupera i dettagli' - retrieves the details), the resource (a specific Jira ticket), and the unique identifier (its key). It distinguishes itself from siblings by emphasizing 'specifico tramite la sua chiave', which clearly separates it from searching or getting my tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you have a specific ticket key and need its details. It doesn't explicitly compare with sibling tools (jira_search_tickets, jira_get_my_tickets), but the context is clear enough that this is the tool for a known key. Missing explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cerca ticket Jira usando JQL (Jira Query Language). Esempi: "project = IIAB AND status = Open", "assignee = currentUser()", "labels = backend"
| Name | Required | Description | Default |
|---|---|---|---|
| jql | Yes | Query JQL per cercare i ticket | |
| max_results | No | Numero massimo di risultati (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Non sono presenti annotations, quindi la descrizione deve indicare il comportamento. Dice solo che esegue una ricerca con JQL, ma non specifica se è read-only, il formato di ritorno (es. array di ticket), l'ordine, la paginazione o eventuali limiti. Manca trasparenza su aspetti comportamentali rilevanti.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Descrizione in una frase breve con tre esempi immediatamente utili. Nessuna parola superflua, il contenuto è front-loaded e facilmente consultabile.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Per uno strumento semplice con due parametri ben documentati e una funzione di ricerca ben exemplificata, la descrizione è quasi completa. Manca però la forma del risultato (output non definito) e un riferimento esplicito ai casi d'uso alternativi, ma il tutto resta comunque utilizzabile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Lo schema copre al 100% i parametri con descrizioni chiare. La descrizione aggiunge valore con esempi concreti di JQL che chiariscono la sintassi del parametro jql, pur non aggiungendo nulla su max_results oltre allo schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
La descrizione usa un verbo specifico ('Cerca') e indica chiaramente l'oggetto ('ticket Jira') e il metodo (JQL). Gli esempi illustrano il tipo di query, differenziando il tool dai sibling come jira_get_ticket e jira_get_my_tickets che non eseguono ricerche libere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
L'uso è implicito: si usa quando si vuole cercare ticket tramite JQL, come mostrato dagli esempi. Tuttavia non vengono esplicitati quando usare questo tool rispetto ai sibling (come jira_get_ticket per un ticket singolo o jira_get_my_tickets per i propri) né le esclusioni.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0jira_get_my_ticketsjira_get_ticketjira_search_ticketsScored across 3 tools
Each tool targets a distinct retrieval mode: by key, by JQL query, and by assignee. Although search could mimic get_my_tickets with a JQL, the dedicated tool adds convenience and clarity.
All tools follow a consistent 'jira_<verb>_<noun>' pattern, making the tool set predictable and easy to navigate.
With only 3 tools, the set is concise but reasonable for a read-only Jira assistant. It is within the ideal range, though slightly sparse.
The server only supports reading tickets. Missing create, update, transition, and comment operations leaves significant gaps for typical Jira workflows, so the surface feels incomplete.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
The Jam MCP server provides AI tools with instant bug context without manual prompting, enabling a streamlined workflow from bug identification to ticket creation and pull request generation without switching between tools.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
