Skip to content

ADR-0004: MCP-Only Tool-Level Connectors

Target architecture — not the current operating contract

This accepted decision guides product direction. Use Connector administration for implemented behavior.

Status

Accepted — 2026-08-19

Context

An enterprise AI estate can accumulate proprietary adapters, SDK-specific tools, direct APIs, and integration labels that are difficult to discover, govern, version, and operate consistently. Classifying an entire server or vendor as read, decision, or action is also too coarse: one MCP Server can expose a harmless search tool, a material business-rule decision, and a side-effecting transaction.

Mission Control needs one integration boundary and a product abstraction granular enough to assign identity, ownership, risk, access, policy, lifecycle, health, and evidence to the actual capability being requested.

Decision

MCP is the only enterprise integration protocol supported by Mission Control. The platform registers MCP Servers, discovers their typed tools, and exposes each individual tool internally as a Connector.

Classification is per tool. Every Connector has exactly one primary class:

  • Data reads or supplies information without changing enterprise state.
  • Decision evaluates, scores, recommends, validates, or applies business rules without changing enterprise state.
  • Action changes enterprise state, emits an externally meaningful event, or initiates work with side effects.

Data and Decision Connectors are side-effect-free from the caller's perspective. Any externally meaningful side effect makes a tool Action. Composite behavior is a Workflow using multiple Connectors rather than one ambiguously classified tool.

Each Connector has its own identity, owners, immutable version, risk and data class, capability grants, policy bindings, certification, health, usage, incidents, and environment promotion. Models are not Connectors and remain behind Model Management and the Model Gateway.

Consequences

  • Product policy, approval, idempotency, evidence, and operating defaults match the actual effect of each requested tool.
  • One MCP Server can safely expose tools across all three classes without sharing an inaccurate server-level risk label.
  • Existing non-MCP enterprise capabilities require an MCP facade before Mission Control can govern them; arbitrary protocol adapters are not added to the product core.
  • Registration requires discovery, per-tool ownership and classification, schema and failure certification, grants, policy, and environment promotion before production use.
  • MCP schema changes create candidate Connector versions, and breaking or unreviewed versions remain quarantined.
  • Tool authors cannot avoid Action controls by labeling a side effect as a notification, recommendation, request, asynchronous operation, or low-value change.
  • Future integration work must extend MCP registration, certification, and gateway behavior rather than introduce a parallel connector framework.

Current governance mapping

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.