Because the data already sits in Snowflake, questions that are slow or awkward through the JIRA API — everything in one sprint, statistics across every project, all links from one issue — become single calls. The tables it reads are the non-PII ones, so what comes back is the issue rather than the people on it.
An MCP server over JIRA issue data stored in Snowflake. Its tools query the non-PII issue tables directly, so filtering, linking and summarising happen in the warehouse rather than against the JIRA API.
- Issues queried and filtered by project, issue key, type, status, priority, component, version and date
- Free-text search across issue summaries and descriptions
- Full details for several issues at once, by their keys
- Statistics and summaries across all projects
- The links between one issue and the others it relates to
- Every issue in a sprint, by sprint name
A Snowflake database and schema holding the JIRA tables the server expects by name — issues, labels, comments, components, project versions, issue links and link types, custom field values, sprints and change history — plus credentials to reach it.
One command plus a key — podman build -t localhost/jira-mcp-snowflake:latest ., then supply credentials