ARCS/Crosswalks/ARCS / MCP Crosswalk

This informative crosswalk describes how ARCS relates to the published Model Context Protocol specification. It is provided as an interpretive instrument for readers assessing the boundary between protocol-level interoperability and record-lifecycle governance. It is not part of the normative ARCS control text and does not purport to restate, amend, or supersede the MCP specification.

Interpretive status

This document provides an informative mapping between the published Model Context Protocol specification and ARCS control themes at the level of protocol boundary, retained artifact status, and lifecycle governance. It does not restate the MCP specification or assess protocol conformance.

Protocol scope

MCP standardizes how hosts, clients, and servers communicate through JSON-RPC messages, negotiate capabilities, and expose resources, prompts, and tools. The specification describes stateful connections, initialization and shutdown behavior, and an OAuth 2.1 authorization framework for HTTP-based transports.

ARCS relevance

ARCS becomes relevant when interaction artifacts created or handled through MCP are retained, exported, logged, replicated, preserved, or published as records subject to custody, deletion, preservation, verification, or disclosure obligations. MCP governs runtime coordination. ARCS governs what happens to the records those runtimes create.

Lifecycle boundary conditions

Resources may expose material that is cached, exported, or logged. Tools generate invocation records and execution traces. Sampling and elicitation generate prompts, approvals, and user-supplied information. Logging creates a distinct observability layer. The governance question is whether MCP-mediated activity remains transient or becomes a retained record surface.

Selected mappings

Table A maps selected MCP protocol surfaces to ARCS control families at a category and theme level. It does not claim one-to-one equivalence between MCP requirements and ARCS controls. MCP is a protocol specification; ARCS is a record-custody and lifecycle-governance standard. The mapping is therefore interpretive and boundary-focused.

MCP protocol surfaceARCS familiesInterpretive note
Connection lifecycle and session stateARCS-LIF, ARCS-CUS, ARCS-PV, ARCS-VERMCP defines initialization, operation, and shutdown behavior. ARCS becomes relevant when session metadata, traces, or state transitions persist as governed records.
Capability negotiationARCS-OPB, ARCS-CUS, ARCS-VERNegotiated capabilities may become audit, evidence, or governance artifacts when stored in logs, receipts, or operational records.
ResourcesARCS-TAX, ARCS-CUS, ARCS-PUB, ARCS-PVThe issue is not resource access alone, but retained copies, derived artifacts, metadata, and disclosure boundaries once contextual material is cached, logged, or exported.
ToolsARCS-OPB, ARCS-CUS, ARCS-NCR, ARCS-VERTool invocations can generate action logs, approval records, outputs, and execution traces requiring lifecycle controls once they become durable artifacts.
PromptsARCS-TAX, ARCS-CUS, ARCS-PUB, ARCS-PVPrompt templates and instantiated prompt content may become governed records if stored, synced, reviewed, or disclosed.
SamplingARCS-OPB, ARCS-CUS, ARCS-PV, ARCS-VERServer-initiated model interaction can produce approval artifacts, prompts, and outputs with downstream record consequences.
ElicitationARCS-TAX, ARCS-CUS, ARCS-PUBAdditional user-supplied information can alter both record taxonomy and disclosure posture once persisted.
Logging and progress utilitiesARCS-OPB, ARCS-TAX, ARCS-CUS, ARCS-PVObservability surfaces can become independent record layers distinct from substantive interaction content.
Authorization artifactsARCS-OPB, ARCS-VER, ARCS-CUSTokens, approvals, consent events, and related metadata can generate operational records with preservation and review implications.
Connection lifecycle and session state
ARCS Families
Note
MCP defines initialization, operation, and shutdown behavior. ARCS becomes relevant when session metadata, traces, or state transitions persist as governed records.
Capability negotiation
ARCS Families
Note
Negotiated capabilities may become audit, evidence, or governance artifacts when stored in logs, receipts, or operational records.
Resources
ARCS Families
Note
The issue is not resource access alone, but retained copies, derived artifacts, metadata, and disclosure boundaries once contextual material is cached, logged, or exported.
Tools
ARCS Families
Note
Tool invocations can generate action logs, approval records, outputs, and execution traces requiring lifecycle controls once they become durable artifacts.
Prompts
ARCS Families
Note
Prompt templates and instantiated prompt content may become governed records if stored, synced, reviewed, or disclosed.
Sampling
ARCS Families
Note
Server-initiated model interaction can produce approval artifacts, prompts, and outputs with downstream record consequences.
Elicitation
ARCS Families
Note
Additional user-supplied information can alter both record taxonomy and disclosure posture once persisted.
Logging and progress utilities
ARCS Families
Note
Observability surfaces can become independent record layers distinct from substantive interaction content.
Authorization artifacts
ARCS Families
Note
Tokens, approvals, consent events, and related metadata can generate operational records with preservation and review implications.

Outside scope

This crosswalk does not assess whether a given MCP implementation is secure, compliant, or operationally appropriate. It addresses a narrower question: when MCP-mediated interactions produce retained artifacts, what record-custody and lifecycle-governance considerations become relevant under ARCS. MCP is not a records-governance standard for retention, preservation, deletion, verification, or compelled-production posture once artifacts persist beyond session scope. The following domains identify ARCS controls relevant to record-lifecycle questions that MCP does not address.

Deletion verifiability for tool and session logs

ARCS-LIF (LIF-12, LIF-13), ARCS-VER (VER-01 to VER-03)

MCP does not govern deletion of tool invocation logs, session traces, or cached resource content after connection shutdown. ARCS requires deletion claims for those artifacts to be verifiable and requires retention that persists beyond session scope to be documented.

Preservation and legal hold for cached resources

ARCS-PV (PV-01 to PV-07)

MCP does not define preservation triggers. When cached resources, tool outputs, or session logs become subject to legal, regulatory, or investigative hold, ARCS governs suspension of deletion and coordinated preservation across host, client, and server infrastructure.

Multi-vendor custody across MCP server boundaries

ARCS-CUS (CUS-01 to CUS-12)

MCP connections may span organizational boundaries when hosts connect to servers operated by different vendors. ARCS requires documentation of possession, control, access, and deletion authority at each custodian in the resulting record chain, including cases where a single session produces records on infrastructure controlled by multiple organizations.

Non-creation claim verification for transient sessions

ARCS-NCR (NCR-01 to NCR-06)

MCP does not specify how claims of non-retention are established after session termination. Where an operator asserts that MCP-mediated interactions do not yield governed records, ARCS requires architectural verification of that assertion, including evidence that session state, tool logs, and cached content were not persisted.

Disclosure posture for tool invocation records

ARCS-PUB (PUB-01 to PUB-06)

MCP tool invocations produce request-response records that may document what was queried, what was returned, and when. ARCS governs disclosure classification, production readiness, and privilege assessment for those records when they persist on reachable infrastructure.