Skip to content

Module V — MCP, skills & capability management

Module V is the capability management overlay: it governs the tools and capabilities of your agents — which MCP server exposes which tool, what its transport, scope and configuration are, which origin is wired to which capability, its version history, and its basic connection health. It sits in the Management layer and has no actuation surface: it catalogs, governs and audits, but never runs a tool or mutates a live MCP runtime.

The managed configs in /capabilities and /v1/m/capabilities/configs are observation metadata, with audited changes and immutable revision history. Saving, changing enabled, or deleting a definition does not configure the MCP gateway, start or stop a server, resolve a secret reference, or change a discovered server’s transport or endpoint. The gateway uses its own configuration seam. Stored definitions and their history remain available after a restart or after turning the capabilities module off and back on.

The module is an overlay built on top of the passive discovery of module I and the introspection of the connectors. It does not re-implement the MCP client, and it deliberately does not re-materialize the core entities that inventory already owns (the MCP server, skill, tool and resource records). Instead it reads those core entities and stores only its own overlays, keyed by the connectors’ already-redacted natural references and resolved to core entities at read time — a single-writer discipline that keeps it from racing inventory’s materializer.

This is distinct from module III. Module V answers “which capability is an agent connected to”; module III answers “which resource did an origin read or write”. They are separate views and the product never conflates them.

Module V owns four overlay entities (each prefixed capabilities.):

Entity What it holds
mcp_config The managed configuration of an MCP server — transport, scope, an endpoint reference and secret references. There is no column that can hold a usable credential.
config_revision An append-only snapshot per config version — the immutable version history, surviving deletion of the config.
wiring The capability-connection graph: an origin → capability edge stored by natural reference, never by core entity id.
health The last observed connection signal of a capability (connected / degraded / down / unknown) — a basic signal, not an SLA.

Two contract properties are non-negotiable. MCP tool annotations are untrusted: a tool’s readOnlyHint/destructiveHint are a declared hint from the server, which the MCP specification says clients must treat as untrusted — every tool projection carries an explicit untrusted flag, never a security badge. No secret values on the wire: a config references secrets by name, kind and a masked hint; the backend rejects inline credentials in an endpoint or spec rather than storing them. Minimal-data is a property of the wire, not an afterthought.

Reading the catalog is RBAC-gated and tenant-scoped. Changing a config — and the secrets it references — is a privileged change recorded in the append-only, hash-chained ledger and attributed to the real principal.

Module V is fed by the event bus, not by its own polling. It reacts to two channels:

  • edge.observed — runtime capability use becomes wiring edges. The Source field distinguishes observed signals (otel) from declared ones (mcp_annotation), and a newer config-discovery feeder tags statically-declared capabilities with a config source.
  • finding.reported — the connectors’ connection-health findings feed the health overlay’s last-signal status.

It produces no events of its own and dispatches nothing to live infrastructure; its output is read by the management UI and by other modules over its typed routes.