One MCP server can connect CI failures, Jira history and support cases — and their credentials

The DCI MCP server exposes an unusually broad troubleshooting surface through one Model Context Protocol endpoint. Its tools can query Distributed CI jobs and files, read Jira history, inspect GitHub and GitLab work, retrieve Red Hat support cases and advisories, and turn the collected evidence into root-cause reports.

That breadth is the point of the project, but it is also its central trust-boundary problem: an AI client connected to the server can potentially reach several systems that normally have separate identities, audiences and retention rules.

A joined evidence path

The project’s dynamic /dci/rca prompt pre-fetches DCI job metadata and files, classifies a failure as an ACM, ZTP, upgrade, day-two, single-node or standard job, and adjusts the file priorities used in the analysis. It downloads artifacts under /tmp/dci/<job id>/ and writes a Markdown report locally.

A separate support-case prompt reaches further. It retrieves a case, follows directly and transitively linked Jira tickets, gathers associated pull requests or merge requests with diffs, checks related errata, and builds a report containing a timeline, code-change classification and proposed next steps. Google Drive tools can then convert Markdown reports into Google Docs.

This is more useful than asking a model to infer a failure from a single log, because the server can assemble operational, planning and code evidence. It also means the resulting report may combine customer case material, internal tickets and source changes in one file or document.

Credentials remain separate, even when the interface does not

The README configures DCI API credentials, a Jira API token, GitHub and GitLab tokens, a Red Hat Customer Portal offline token, and Google OAuth credentials independently. Operators should preserve that separation: each integration should receive only the access required for the intended investigation path.

The Jira integration illustrates one useful control. Read access is configured with a token, while ticket creation, updates, comments and transitions require a separate JIRA_WRITE_ENABLED=true switch. GitLab access also restricts the model-controlled instance URL to the configured host by default, with an explicit allowlist for additional hosts; the project recommends using a corporate CA bundle rather than disabling TLS verification.

Deployment is part of the security model

The server supports local standard-input connections and an HTTP/SSE mode shown binding to 0.0.0.0:8000. The README does not describe an authentication layer for that SSE endpoint. A team using the network transport should therefore place it behind its own authenticated, encrypted boundary rather than assuming MCP transport supplies one.

Local output needs the same care. Root-cause reports and downloaded artifacts are written under /tmp, while Google Drive export can move them into a different access domain. Retention, cleanup and document-sharing policy are not peripheral details here: they determine whether the convenience of joined evidence also creates an unintended joined data store.