MCP server

Every external system TruStacks agents interact with (code, policy, tools, customer infrastructure) is reached through the Model Context Protocol. This is a deliberate architectural choice. It keeps the agent runtime ignorant of which tools you use, lets the Environment Profile drive what gets connected, and gives every agent a uniform shape for tool calls regardless of whether the underlying system is GitHub, Gitea, Datadog, or our own rules engine.

Why MCP

• The agent runtime stays ignorant of your stack. Agents call MCP tools by name and shape, not vendor-specific SDKs. A swap from Datadog to New Relic is a Profile change, not an agent change.
• The Environment Profile drives connection. The Runner reads the Profile at startup and wires up MCP clients for the tools you have declared. Tools you have not declared are not connected, and the agents do not know they exist.
• Every agent uses the same shape. Tool calls are uniform across agents, which makes the multi-agent dialogue (Coordinator delegating to a specialist) tractable.
• Customer-facing integrations come almost free. When you say “we use $TOOL,” the answer is “what is your $TOOL MCP endpoint?” instead of “we will add it to the roadmap.”

What runs where

The Runner pod in your cluster is both an MCP server (it hosts one) and an MCP client (it consumes others).

┌────────────────────────────────────────────────────────────────┐
│  Your cluster (Data Plane)                                     │
│                                                                │
│  ┌────────────────────────────────────────────────────────┐    │
│  │  Runner pod                                            │    │
│  │  ┌──────────────────────────────────────────────────┐  │    │
│  │  │  TruStacks MCP server (we host)                  │  │    │
│  │  │  ───────────────────────────────────             │  │    │
│  │  │  • Active rules (constitution + packs + overlay) │  │    │
│  │  │  • Environment Profile                           │  │    │
│  │  │  • OPA policy evaluation                         │  │    │
│  │  │  • Rule-bundle fetching                          │  │    │
│  │  └──────────────────────────────────────────────────┘  │    │
│  │                                                        │    │
│  │  MCP clients (we consume):                             │    │
│  │   - Git MCP (GitHub, Gitea)                            │    │
│  │   - Filesystem MCP (Anthropic-published)               │    │
│  │   - Customer-environment MCPs (Datadog, Jira,          │    │
│  │     ServiceNow, Snyk, Splunk ...)                      │    │
│  └────────────────────────────────────────────────────────┘    │
└────────────────────────────────────────────────────────────────┘

Servers TruStacks hosts

Custom TruStacks MCP server

The bottom edge of the Knowledge Plane and the queryable interface to the Environment Profile. Every agent calls this server. It is not optional.

What it exposes:

• Active rules · the merged constitution + Specialist Packs + customer overlay, evaluated against any proposal.
• Environment Profile · the signed, declarative inventory of your stack, queryable by category.
• OPA policy evaluation · run a proposed change through the policy engine and return the verdict, with the citation back to the rule that decided.
• Rule-bundle fetching · pull the latest signed bundles from the TruStacks registry, verify Cosign signatures, hand them to the OPA evaluator.

This is the only MCP server whose output the agents treat as authoritative. The Runner built it. The Runner verifies its inputs. The Runner signs its outputs. Everything else is untrusted by design.

Clients TruStacks consumes

The Runner ships with MCP clients for the systems it always needs. Other clients are connected based on the Environment Profile.

Always connected

• Git MCP · GitHub MCP in production, Gitea-compatible in local dev. Used to read application repositories, open PRs against the platform and overlay repositories, comment on PRs, and manage branches.
• Filesystem MCP · Anthropic-published. Bounded read access to checked-out repositories for code analysis. What the Code Reviewer uses during discovery.

Profile-driven

• Datadog MCP · for the SRE Specialist agent (when subscribed). Surfaces SLO breaches, recent incidents, error budgets.
• Jira / ServiceNow MCP · for change management. The DevOps Engineer links PRs to tickets. The Coordinator opens change records when the constitution or a Pack requires one.
• Splunk / Sentry MCP · for incident triage. The Cluster Operator add-on consumes these to draft remediation PRs.
• Snyk and other scanner MCPs · when the scanner is named in the Environment Profile. The Baseline Security agent ingests findings through the MCP and renders them with stack-shaped recommendations.

The Runner reads the Profile at startup to know which Profile-driven clients to wire up. Adding a new tool is a Profile PR, not a runner release.

Trust boundary

This is the load-bearing property and worth calling out explicitly.

The reasoning: MCP is a tool protocol, not a policy protocol. A third-party MCP server is a vendor surface that can be misconfigured, compromised, or simply wrong. The TruStacks runtime treats every external MCP response the way a careful engineer treats user input. The rules engine is the only authority on what is allowed.

Strategic note: public MCP exposure

The MCP-based integration substrate is the seam where the TruStacks rules engine can later be exposed as a public MCP server. External agents (Cursor, Devin, customer-built tools) could query the constitution and the active Specialist Packs through MCP.

This is out of MVP scope. The artifact model already supports it (signed Rego bundles, OCI distribution). Watch this space.

Where to go next

• Architecture · how MCP fits into the three-plane model
• Constitution · the rules the TruStacks MCP server exposes for evaluation
• Runner CLI · operator surface, including MCP-related operations