Nimbus

What nimbus-agent/Nimbus MCP server does

The nimbus-agent/Nimbus MCP server gives MCP clients access to a locally maintained index of an engineering toolchain. The documented sources include GitHub, Jira, Slack, PagerDuty, Datadog, source control, CI/CD, cloud infrastructure, monitoring, and incident-management systems. Its intended use is operational investigation: finding incident context, relating deployments to pull requests, checking code ownership, tracing dependencies, and reviewing release or security signals.

Nimbus also supports local repository analysis. Its why workflow can identify who changed a line, when it changed, and which commit introduced it using local Git history. With connected services, that context can be extended to related pull requests, tickets, and incidents. The project is listed in the 💻 Developer Tools category and is aimed at engineers working in production operations, platform engineering, and SecDevOps.

How it works

A headless Nimbus Gateway runs on the developer’s machine and stores the index in SQLite. Credentials, the local Vault, and the audit log remain local according to the README; Nimbus does not provide a cloud service. The engine uses connectors to gather data and answers queries from the local index rather than calling cloud APIs directly for each question.

As an MCP server, Nimbus exposes 21 read-only tools: nine index tools and 12 built-in agent tools. Examples of the agent tools include explainWhy, findExpert, assessImpact, and getCatchup. Nimbus can also operate as an MCP client, driving connectors that are themselves MCP servers, and can host registered third-party MCP servers in restricted working directories with approved paths and hosts.

Writes and outbound actions are consent-gated. The README describes approval prompts for actions such as posting an incident summary, triggering a rollback, or creating tickets. An optional [mcp_sink] setting adds the capture_note tool, which stores an agent-authored note in the local index for later review or revocation.

Setup and configuration

The nimbus-agent/Nimbus MCP server can be installed for MCP clients with npx -y @nimbus-dev/mcp. A checkout can instead run nimbus mcp-server --stdio, providing a standard stdio MCP transport. The project supports Windows, macOS, and Linux and requires Bun 1.2 or newer when running the project directly.

For a first local indexing pass, run nimbus init in a repository. The nimbus demo command creates an isolated synthetic environment for trying the workflows without changing real configuration or data. Connector setup is used to extend the index beyond local Git data. Telemetry is opt-in and disabled by default; the README identifies the setting as [telemetry] enabled = false.

Tools and capabilities

• Search indexed incidents, pull requests, deployments, alerts, and engineering records.
• Ask cross-service questions with nimbus ask.
• Trace line-level authorship and related change context with nimbus why.
• Find likely experts, assess impact, and retrieve operational context through agent tools.
• Inspect egress history with nimbus prove.
• Preview and approve multi-step automation with nimbus run.
• Expose the local index to another MCP client over stdio.

Limitations and notes

The standard MCP interface is read-only unless the optional sink is enabled. Connector availability and answer coverage depend on what has been indexed and which services have been connected. The README states that every write, send, or delete requires explicit approval, but it does not make those actions automatic.

Third-party MCP servers registered with Nimbus run with approved read paths and hosts. On Windows, approving any host grants that server access to the whole network, and the approval prompt communicates this scope. If a registered server is also offered to the nimbus ask model, results can reach the configured remote LLM vendor. Nimbus itself has no cloud account or Nimbus-hosted service, but connected vendors and services remain relevant to the data path.