F
licenseNot graded
qualityD
maintenanceA server implementation that allows AI models to interact with Jira through the Model Context Protocol, enabling tasks like JQL searches and retrieving issue details.
-
Jira MCP Server
by ParasSolanki
Servidor Jira MCP
Un servidor de protocolo de contexto modelo para Jira.
Proporciona integración con Jira a través de MCP, lo que permite que los LLM interactúen con él.
Documentación de la API REST de Jira
Instalación
Instalación manual
Nota: Requiere que la versión de Node sea 22.12.0 o superior
Crear u obtener un token de acceso personal de Jira: Guía
Agregar configuración de servidor a Claude Desktop:
MacOS: ~/Biblioteca/Soporte de aplicaciones/Claude/claude_desktop_config.json
Windows: Consulta esta guía
{
"mcpServers": {
"jira": {
"command": "npx",
"args": ["-y", "@parassolanki/jira-mcp-server@latest"],
"env": {
"JIRA_PERSONAL_ACCESS_TOKEN": "email@example.com:your_personal_jira_access_token",
"JIRA_BASE_URL": "jira_base_url"
}
}
}
}Para Windows:
{
"mcpServers": {
"jira": {
"command": "cmd /c npx",
"args": ["-y", "@parassolanki/jira-mcp-server@latest"],
"env": {
"JIRA_PERSONAL_ACCESS_TOKEN": "email@example.com:your_personal_jira_access_token",
"JIRA_BASE_URL": "jira_base_url"
}
}
}
}Related MCP server: Jira MCP Server
Componentes
Herramientas
list_projects: enumera proyectos de Jira.Entradas requeridas:
query(cadena opcional): una cadena de consulta utilizada para filtrar los proyectos devueltos.maxResults(número opcional, máximo: 100): el número máximo de resultados a devolver.expand(cadena opcional): expande información adicional en la respuesta. (descriptionseparada por comas,lead,issueTypes,url,projectKeys,permissionsyinsight).
list_boards: Lista los tableros de un proyecto.Entradas requeridas:
projectKeyOrId(cadena): clave o Id del proyecto.name(cadena opcional): Nombre del proyecto.maxResults(número opcional, máximo: 100): el número máximo de resultados a devolver.startAt(número opcional): el índice inicial de los tableros devueltos.type(cadena opcional): el tipo de tableros. (puede serscrumokanban).
list_sprints_from_board: enumera los sprints de un tablero.Entradas requeridas:
boardId(cadena): el ID del tablero.maxResults(número opcional, máximo: 100): el número máximo de resultados a devolver.startAt(número opcional): el índice inicial de los tableros devueltos.
list_issues_from_sprint: enumera los problemas de un sprint.Entradas requeridas:
boardId(cadena): el ID del tablero.sprintId(cadena): el ID del sprint.maxResults(número opcional, máximo: 100): el número máximo de resultados a devolver.startAt(número opcional): el índice inicial de los tableros devueltos.expand(cadena opcional): expande información adicional en la respuesta. (schemaynamesseparados por comas).
create_issue: crea un problema en Jira (solo admite el tipo de problema de tarea).Entradas requeridas:
projectKeyOrId(cadena): clave o Id del proyecto.summary(cadena): el resumen/título del problema.description(cadena): la descripción del problema.
Ejemplos de uso
Algunos ejemplos de indicaciones que puedes usar para interactuar con Jira:
"Muéstrame todos los proyectos de Jira" → ejecuta la herramienta list_projects para ver todos los proyectos disponibles.
"¿Qué tableros Kanban existen en el proyecto DEV?" → ejecute la herramienta list_boards con la clave del proyecto DEV y el parámetro de tipo establecido en "kanban".
"Muéstrame todos los sprints para el tablero ID 123" → ejecuta la herramienta list_sprints_from_board para ver todos los sprints asociados con el tablero 123.
"¿Qué problemas hay en el sprint 456 en la placa 123?" → ejecute la herramienta list_issues_from_sprint para ver todos los problemas en el sprint 456 en la placa 123.
"Muéstrame los primeros 50 problemas del sprint actual en el tablero de Marketing" → primero ejecuta list_boards para encontrar el ID del tablero de Marketing, luego list_sprints_from_board para encontrar el sprint actual, luego list_issues_from_sprint con maxResults=50.
Desarrollo
Instalar dependencias:
pnpm installConfigurar el token de acceso de Github en
.env:
JIRA_PERSONAL_ACCESS_TOKEN=email@example.com:your_personal_jira_access_token
JIRA_BASE_URL=jira_base_urlEjecutar localmente con reloj:
pnpm devConstruir el servidor:
pnpm buildDepuración local con inspector:
pnpm inspectorTODOS
[x] lista_proyectos
[x] tableros de listas
[x] lista_sprints_del_tablero
[x] lista_de_problemas_del_sprint
[ ] obtener_problema_por_id_o_clave
[x] create_issue (solo tipo de problema de tarea)
[ ] create_issue (tipos de problema: historia, épica y subtarea)
[ ] problema de actualización
[ ] eliminar_un_problema
[ ] archivar_un_número
[ ] lista_de_comentarios_del_problema
[ ] obtener_comentarios_del_problema_por_id
[ ] crear_comentario_en_el_tema
[ ] actualización_del_comentario_del_problema
[ ] eliminar_comentario_del_problema
[ ] lista_subtareas_del_problema
[ ] obtener_usuario_por_nombre_de_usuario_o_clave
Available Tools
5 toolscreate_issueB
Create an issue in Jira
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| projectKeyOrId | Yes | The key or ID of the project | |
| summary | Yes | The summary of the issue | |
| description | Yes | The description of the issue |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it creates an issue; does not disclose side effects, permissions needed, success/failure behavior, or whether the action is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no filler; every word is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should hint at return value or additional behavior. It does not; leaves agent guessing about what happens after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no extra semantic context beyond the schema definitions; e.g., does not explain the purpose of projectKeyOrId or summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('an issue in Jira'), which is distinct from sibling tools that are all list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives (e.g., list_issues_from_sprint). Does not mention prerequisites such as having a project key or that summary and description are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_boardsC
List boards from a project
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| projectKeyOrId | Yes | The key or ID of the project | |
| name | No | The name of the boards to return, Must be less than 255 characters. | |
| maxResults | No | The maximum number of results to return, (max: 100) | |
| startAt | No | The starting index of the returned boards | |
| type | No | The type of boards to return |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose read-only nature, pagination behavior, or error handling. Only implies listing without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 4 words, no wasted text. However, it could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lacks return value info, pagination details, and filtering logic. With 5 parameters and no output schema, it is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 5 parameters with 100% coverage, so description adds no extra meaning beyond the schema. Baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists boards from a project, with a specific verb and resource. It is distinct from sibling tools (list_projects, list_sprints_from_board) but does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_issues_from_sprintC
List issues from a sprint
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sprintId | Yes | The ID of the sprint | |
| boardId | Yes | The ID of the board | |
| maxResults | No | The maximum number of results to return, (default: 5, max: 100) | |
| startAt | No | The starting index of the returned boards | |
| expand | No | Use this parameter to include additional information in the response. This parameter accepts a comma-separated list. Expand options include: `schema` and `names`. Comma separated list of options. |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action, omitting details like pagination (implied by maxResults/startAt), default results, error behavior, or authentication requirements. This is insufficient for an agent to understand the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) with no wasted text. However, it borders on under-specification, as it could benefit from a brief qualifier (e.g., 'paginated list'). Nonetheless, it is efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (2 required) and no output schema, the description is too minimal. It fails to explain return structure, parameter expected formats (e.g., sprintId format), or how results are ordered. An agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the schema already provides meaning. The description adds no additional parameter-level context beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List issues from a sprint' clearly states the verb (list) and the resource (issues from a sprint), distinguishing it from sibling tools like list_boards or list_sprints_from_board. However, it lacks specificity on scope or filtering options that would enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., search issues, list all issues), nor does it specify prerequisites like the need for valid sprintId and boardId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsC
List projects from Jira
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| maxResults | No | The maximum number of results to return, (max: 100) | |
| query | No | A query string used to filter the returned projects. The query string cannot be used with the startAt and maxResults parameters. | |
| expand | No | Use this parameter to include additional information in the response. This parameter accepts a comma-separated list. Expand options include: `description`, `lead`, `issueTypes`, `url`, `projectKeys`, `permissions`, `insight`. Comma separated list of options. |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosure. It does not state whether the operation is read-only, idempotent, or any side effects. The name 'list' implies read-only, but no explicit confirmation is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks any structure or additional context. It could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a tool with no output schema. It does not explain the return format, pagination behavior, or any error conditions, even though the schema mentions maxResults and expand. The low complexity partly excuses this, but a complete description would add value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions are clear. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List projects from Jira' clearly states the action and resource. It is specific enough to distinguish from siblings like list_boards or list_issues_from_sprint, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives (e.g., filtering via query vs. using maxResults). There is no mention of when-not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sprints_from_boardB
List sprints from a board
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The ID of the board | |
| maxResults | No | The maximum number of results to return, (max: 100) | |
| startAt | No | The starting index of the returned boards |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behaviors like pagination (maxResults, startAt), ordering, or scope (active/future/closed sprints). Full burden on description, which fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not mention return format, pagination behavior, or constraints like max sprints. Incomplete for a 3-parameter tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add any additional meaning beyond schema parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'list', resource 'sprints', and scope 'from a board'. Distinguishes from sibling tools like list_boards and list_issues_from_sprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives, but purpose is straightforward given sibling names. Lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v1.0.0- Added
create_issue - Added
list_boards - Added
list_issues_from_sprint - Added
list_projects - Added
list_sprints_from_board
TDQS
B3.4/5.0
Scored across 5 tools
Disambiguation5/5
Each tool targets a distinct action: create issue, list boards, list issues from sprint, list projects, list sprints from board. No overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_issue, list_boards). No deviations.
Tool Count5/5
5 tools is well-scoped for a Jira MCP server, covering essential listing and creation operations without bloat.
Completeness3/5
The set covers creation and listing of key entities but lacks update, delete, and search operations, which are common in Jira workflows.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol server that enables AI assistants like Claude to interact with Jira, allowing for project management tasks such as listing projects, searching issues, creating tickets, and managing sprints through natural language queries.754 npm2TypeScriptMIT
- AlicenseCqualityDmaintenanceA Model Context Protocol server that enables AI assistants like Claude to interact with Jira Cloud instances, providing capabilities for issue management, project listing, and JQL search.154 npm2MIT
- AlicenseNot gradedqualityCmaintenanceA clean, reliable Model Context Protocol server for Jira integration, enabling issue management, search, and more via natural language.MIT