Asking the connected client to do the summarisation means the report never leaves your model's context for a third-party API, and there is no second key to manage or bill. The default JQL is a sensible weekly window, but the parameter is there — pointing it at a sprint, a component or a person is the same call with a different query.
A small server built on FastMCP that connects to a Jira instance, Cloud or Server/Data Center, and turns issue activity into a report. Its one distinguishing move is summarisation: rather than calling a model of its own, it asks the connected client's model to summarise the report it just produced.
- A report of Jira issues, defaulting to `updated >= -7d ORDER BY updated DESC` when you supply nothing — `generate_jira_report`
- A custom JQL query when you want a different window or filter, passed as `jql_query`
- The search scoped to one project by key, passed as `project_key`
- A cap on how many issues go into the raw report, via `max_results`, defaulting to 50
- An optional summary produced by your own client's model when `summarize` is true, so no second API key is involved
Access to a Jira instance and an API token — an Atlassian API token for Cloud, or a Personal Access Token for Server and Data Center. Put `JIRA_URL`, `JIRA_USERNAME` and `JIRA_API_TOKEN` in a `.env` file beside the server script, and keep that file out of version control. Python 3.10 or later, with dependencies installed via `uv pip install fastmcp "jira[cli]" python-dotenv httpx anyio`, and the FastMCP CLI on your PATH since the documented client config launches `fastmcp run` against the script's absolute path. An SSE transport option is available for remote use.
