Reading and creating single issues is table stakes; passing JQL straight through means the assistant can express the query you would have written yourself, and everything downstream operates on that result. Two things to check on day one: the token has to belong to an account with permission on the project, and status transitions in Jira are workflow-constrained, so an update that sets a status the workflow disallows will fail on Jira's side rather than in the tool.
An MCP server for Jira. Six tools cover the daily loop — find issues with JQL, read one, create a new one, change an existing one, add a comment, and look up project information — with authentication through a Jira API token rather than a password.
- `search_issues` runs a JQL query, which is what makes 'open issues in this project' one call rather than a filter you maintain
- `get_issue` returns the details of a specific issue
- `create_issue` opens a new one, and `update_issue` changes the title, description, status or assignee of an existing one
- `add_comment` posts a comment to an issue
- `get_project_info` returns project information
- A default project through `DEFAULT_PROJECT_KEY`, so a request that does not name one still lands somewhere sensible
Node.js, and a Jira API token created under account settings. Configuration is `JIRA_URL`, `JIRA_USERNAME`, `JIRA_API_TOKEN` and `DEFAULT_PROJECT_KEY`. After `npm install`, `npm run setup` runs an interactive setup that collects the connection details and writes both the environment file and a Claude Desktop configuration; setting them by hand is also supported. The client then launches the server entry point with `node`, with the four variables in its environment.