MCP server that gives Claude Code tools for GitHub and dbt CI on Databricks.
v0.10.0: Jira and Confluence tools were removed. Use the Atlassian MCP server in Claude Code alongside jirade — add it to
.claude.jsonand authenticate with/mcp. No Atlassian OAuth app, scopes, orJIRADE_JIRA_OAUTH_*env vars are needed any more.
| Integration | Required for | Auth |
|---|---|---|
| GitHub | PR tools, dbt CI (diff reports), advisors | gh auth login (auto-detected) or JIRADE_GITHUB_TOKEN |
| Databricks | dbt CI, UAT reports, airflow tests | Databricks CLI OAuth (default) or PAT; needs JIRADE_DATABRICKS_HOST, _HTTP_PATH, _CI_CATALOG |
| git (local) | change detection for CI | none |
| Atlassian | — none in jirade — | Atlassian MCP server in .claude.json + /mcp (see below) |
| Anthropic API (optional) | advisor auto-suggestions for unclassified tables | ANTHROPIC_API_KEY — without it, advisors report the gap for the calling agent to fill |
jirade exposes tools via the Model Context Protocol that let Claude Code:
- Monitor GitHub PRs -- list PRs, check CI status, watch until checks pass
- Run dbt CI on Databricks -- build models in isolated schemas, compare against production using metadata-only queries, post diff reports to PRs
- Generate UAT data impact reports -- run analytical aggregate queries against CI tables and post the results to the GitHub PR (the agent posts the same markdown to the Jira ticket via the Atlassian MCP server)
- Audit jirade activity -- pull a quarter's worth of PR data (plus the JQL queries for the agent to run via the Atlassian MCP server) so the agent can write a funnel-style activity report
- Analyze dbt deprecation impact -- find downstream models affected by deprecating a table or column
No raw data is ever exposed. The Databricks client enforces a strict SQL whitelist -- only aggregated metadata queries (counts, schemas, NULLs, distributions) are allowed.
# From source (recommended for development)
git clone https://github.com/djayatillake/jirade.git
cd jirade
poetry install
# Or via pipx
pipx install git+https://github.com/djayatillake/jirade.gitAdd jirade as an MCP server in your Claude Code settings (~/.claude/settings.json or project .claude/settings.json):
{
"mcpServers": {
"jirade": {
"command": "jirade-mcp",
"env": {}
}
}
}If installed via poetry (not pipx), use the full path:
{
"mcpServers": {
"jirade": {
"command": "/path/to/jirade/.venv/bin/jirade-mcp",
"env": {}
}
}
}Atlassian (Jira + Confluence): no jirade configuration. Add the Atlassian MCP server to
~/.claude.json and authenticate it with /mcp — it provides JQL/CQL search, issue
reads/comments/transitions, and Confluence page create/update, acting as the authenticated user.
"mcpServers": {
"atlassian": {
"type": "http",
"url": "https://mcp.atlassian.com/v1/mcp/authv2"
}
}Restart Claude Code after editing — server lists are built at startup — then run /mcp.
Pass cloudId as your site hostname (e.g. your-org.atlassian.net). The older
/v1/sse endpoint stopped being supported on 2026-06-30. The claude.ai "Atlassian Rovo"
connector exposes the same tool names, but only reaches surfaces that inject claude.ai
connectors; the .claude.json entry also works in the terminal CLI.
Required for GitHub tools:
# Option 1: gh CLI (recommended -- auto-detected, no env var needed)
gh auth login
# Option 2: manual token
JIRADE_GITHUB_TOKEN="ghp_..."Required for dbt CI tools:
JIRADE_DATABRICKS_HOST="dbc-xxxxx.cloud.databricks.com"
JIRADE_DATABRICKS_HTTP_PATH="/sql/1.0/warehouses/abc123"
JIRADE_DATABRICKS_AUTH_TYPE="oauth" # default, uses Databricks CLI creds
JIRADE_DATABRICKS_CI_CATALOG="development_yourname_metadata" # catalog for CI schemasOptional:
| Variable | Default | Description |
|---|---|---|
JIRADE_DATABRICKS_TOKEN |
-- | Databricks PAT (if auth_type=token) |
JIRADE_DATABRICKS_CATALOG |
-- | Default catalog for production lookups |
JIRADE_DBT_EVENT_TIME_LOOKBACK_DAYS |
3 |
Days of data for incremental CI builds |
JIRADE_DBT_CI_SCHEMA_PREFIX |
jirade_ci |
Prefix for CI schema names |
JIRADE_LOG_LEVEL |
INFO |
Logging level |
ANTHROPIC_API_KEY |
-- | Optional: advisor auto-suggestions only (Claude Code is the harness) |
JIRADE_CLAUDE_MODEL |
claude-opus-4-5-20251101 |
Model for the optional direct API calls above |
jirade auth login # all services (GitHub + Databricks)
jirade auth login --service=databricks # validate Databricks connection
jirade health # verify everything worksThese tools are available to Claude Code when jirade is configured as an MCP server.
| Tool | Description |
|---|---|
jirade_list_prs |
List PRs for a repository |
jirade_get_pr |
Get PR details including reviews and comments |
jirade_get_ci_status |
Get CI check status for a PR |
jirade_watch_pr |
Poll CI status until all checks pass or fail (default: 30s interval, 30min timeout) |
| Tool | Description |
|---|---|
jirade_run_dbt_ci |
Build models on Databricks in isolated CI schemas, compare against prod, post report to PR |
jirade_analyze_deprecation |
Find downstream models affected by deprecating a table or column |
jirade_generate_schema_docs |
Read model + upstream SQL from manifest for writing lineage-aware schema descriptions |
jirade_cleanup_ci |
Drop CI schemas after a PR is merged |
jirade_uat_report |
Run analytical aggregate queries against CI tables and post the report to the PR (returns the markdown for the agent to post to Jira via the Atlassian MCP server) |
jirade_test_airflow_dag |
Validate an Airflow DAG's SQL by running it in a CI schema and checking idempotency |
| Tool | Description |
|---|---|
jirade_activity_report |
Pull the PR data needed for a jirade activity audit, plus the JQL queries for the agent to run via the Atlassian MCP server. Surfaces self-authored PRs, other-author PRs the user reviewed or committed to, and other users running jirade tools (cross-user discovery). Returns structured data — agent writes the narrative each run. Designed for weekly/monthly cadence. |
jirade_run_dbt_ci is the main CI tool. When invoked:
- Checks out the PR branch
- Detects changed models and seeds from the git diff
- Loads changed seeds via
dbt seed— a changed seed that is not loaded into the CI schema aborts the run (otherwise downstream models would read the production seed and report "no changes") - Builds modified models +1 dependents in isolated schemas (
jirade_ci_{pr_number}_{catalog}_{schema}) - Uses
--defer --state --favor-stateso upstream models resolve to production - Compares all built models (changed + downstream) against production using metadata queries
- For incremental/microbatch models with
event_time, date-filters comparisons to the CI lookback window - Skips comparison for downstream models whose upstream is time-limited (CI data inherently incomplete)
- Posts a diff report to the PR
dbt run and dbt test are separate steps so test failures don't skip downstream model builds. If some models fail but others succeed, you still get a report with a "Build Failures" section.
Only results written by this CI run count: target/run_results.json is cleared before each dbt step, so a run that dies before executing anything (expired Databricks token, parse error, empty selection) fails with the dbt output tail rather than reporting whatever an earlier dbt command left behind.
CI tables persist after the run for manual inspection. Use jirade_cleanup_ci after the PR is merged.
The DatabricksMetadataClient enforces a strict regex whitelist on every SQL query:
DESCRIBE TABLE,SHOW COLUMNS-- column names and typesSELECT COUNT(*)-- row counts (with optional WHERE for date filtering)SELECT COUNT(*) WHERE col IS NULL-- null countsSELECT COUNT(DISTINCT col)-- cardinalitySELECT col, COUNT(*) GROUP BY col-- value distributionsSELECT MIN/MAX(col)-- numeric rangesCREATE/DROP SCHEMA,DROP TABLE-- CI lifecycle
Everything else is rejected. No SELECT *, no raw rows, no freeform SQL.
Your dbt project needs generate_schema_name and generate_database_name macros that check the DBT_JIRADE_CI environment variable to redirect models into CI schemas.
jirade list-prs --config .jirade.yaml # List GitHub PRs
jirade health # Test all connections
jirade auth status # Show auth status
jirade config validate .jirade.yaml # Validate config
jirade env check --config .jirade.yaml # Check environment
jirade learn status # Show pending learningsThe CLI requires a .jirade.yaml config file. Generate one with:
jirade initMIT