MCP standardized the connection, not the trust

The Model Context Protocol arrived with a useful promise: connect AI applications to tools and data through an open protocol instead of building every integration as a private bridge.

V0M3 already had provider adapters on one side and narrow product capabilities on the other. MCP looked like a cleaner way to connect some of those capabilities. It did not make them safe merely by making them interoperable.

A common protocol can tell a client how to discover and call something. It cannot decide whether this person, in this task, against this document revision, may cause that effect now.

I treated the November launch as an integration event, not a transfer of trust.

The standard solved a real layer

Before a shared protocol, each connection needed custom discovery, request mapping, lifecycle handling, and result parsing. Even when two services both offered “search,” their integration envelopes differed.

MCP offered a common client-server shape for exposing contextual resources and callable tools. That reduced repeated transport work and gave application and server authors a vocabulary they could implement independently.

For V0M3, this meant an MCP connection could feed the existing adapter registry. A server could advertise capabilities; the client could inspect them; a reviewed mapping could implement a product operation.

That was substantial progress. I did not need to inflate it into a complete security or product model.

When a server exposed a tool, V0M3 stored its server identity, connection, name, description, input shape, observed protocol version, and schema digest as a discovered candidate.

The tool did not enter model context automatically. It appeared in an integration review surface where I could map it to a narrow V0M3 capability or leave it disabled.

A later discovery snapshot could show added, removed, or changed candidates. Schema and description changes invalidated the old review according to their consequence. A tool with the same name and different digest was not assumed to be the same authority.

Discovery answered what a server offered to describe. Product configuration answered what V0M3 was willing to use.

Server identity was not a display name

“Local files” was a friendly label and a terrible security key. Two connections could use it. A server behind one connection could change implementation. A copied configuration could point to a different executable or endpoint.

V0M3 identified the connection through its configured transport, installation provenance where available, server-reported metadata, credential scope, and a locally assigned registry identity. High-consequence mappings could pin additional evidence such as an executable digest or approved endpoint.

None of these made remote software perfectly trustworthy. Together they prevented a display-name collision from inheriting an old approval.

The interface showed a readable name and let the receipt retain the exact identity underneath.

Protocol validity stopped at the boundary

A request could conform perfectly to the protocol and still be forbidden. A tool argument could match its schema and still name the wrong repository, document, destination, or revision.

V0M3 normalized an MCP tool request into a product capability request. The orchestrator then checked task allowance, requester authority, resource scope, current policy, budgets, target state, and approval requirements immediately before execution.

Only the reviewed adapter held the mapping from product arguments to server arguments. Unknown fields, ambiguous paths, and server-provided defaults could not broaden the effect silently.

Protocol validation established a well-formed envelope. Authorization established whether V0M3 would send it.

The word “tool” covered retrieving a source, reading a file, rendering a preview, changing a document, publishing an artifact, and invoking a remote service. Those operations had different retry, privacy, and recovery properties.

The registry classified the product capability as read, local transformation, reversible mutation, or consequential external effect. It also recorded idempotency, queryability, compensation, sensitivity, concurrency, and approval needs.

Those semantics came from the reviewed adapter and tested server behavior, not the remote tool description alone. An MCP server could say an operation was safe to retry; V0M3 still required an effect identity and fixtures before relying on that claim.

Interoperability made more tools reachable. Effect classification kept reachability from becoming undifferentiated power.

Resources remained untrusted content

A contextual resource could contain valuable evidence, stale data, private material, malicious instructions, or all four at once.

V0M3 ingested it as a source observation with server identity, resource identity, retrieval time, content digest, media type, access decision, and safe metadata. Text stayed quoted data in later model context. It did not become a higher-priority instruction because it came through a standard channel.

The source pipeline applied size limits, type validation, redaction policy, and content handling before indexing. Unsupported or suspicious content could remain available for human inspection without reaching generation.

MCP standardized retrieval. It did not certify truth or erase prompt injection.

Capability names stayed local

A server might advertise publish, send, or write_file. Passing that name directly to the model made remote vocabulary part of V0M3's product contract.

Instead, the application exposed a local capability such as export_reviewed_revision. Its description and arguments referred to V0M3 concepts. The MCP adapter translated to the server tool after policy and approval.

This meant servers could be replaced without rewriting document tasks. It also meant V0M3 could make a broad remote tool narrower, for example by providing an opaque approved-artifact handle rather than an arbitrary filesystem path.

The remote name remained in provenance and diagnostics. It did not define the user's authority.

Where possible, the model never chose raw resource identifiers. V0M3 minted short-lived handles for the source set, document revision, or prepared export already selected by the workflow.

The adapter resolved a handle server-side, rechecked requester and task, and then constructed the MCP arguments. A handle was scoped to one capability, registry mapping, resource state, and expiry. Copying it into another task failed.

This limited both model mistakes and schema injection. A discovered tool could not persuade the model to enumerate arbitrary paths if the product capability accepted only one opaque artifact handle.

The server still enforced its own authorization. Defense at V0M3's boundary did not excuse weakness downstream.

Approval named the product consequence

Reviewing “Call server X tool publish_v2 with this JSON” asked the author to reverse-engineer meaning from integration detail.

V0M3 prepared a deterministic summary: export document revision 24, artifact digest, selected destination, visibility, and known recovery limits. Approval bound that normalized consequence, current policy, mapping revision, and expiry.

If discovery later changed the tool schema or the adapter mapping, the approval no longer matched. If the target revision changed, the artifact required preparation again. The MCP call occurred only after the server consumed the exact approval receipt.

Human control stayed stable even when the connection mechanism changed.

Server errors did not dictate recovery blindly

An MCP error could report invalid arguments, unavailability, or an application-specific failure. Its text might also be incomplete or hostile.

The adapter mapped known structured errors into V0M3 outcomes and preserved safe raw evidence. Unknown errors remained unknown. The orchestrator consulted effect semantics and receipts before retrying.

A read could usually be attempted again under budget. A publish-like call with a dropped response required destination query or human review if completion could not be established. A remote message saying “retry” did not override that policy.

Common error transport improved diagnostics. Recovery still depended on what the operation meant.

Connection lifecycle was product state

Starting a local server, authenticating a remote connection, losing transport, and discovering a changed registry were not incidental socket events. They affected which tasks could safely continue.

V0M3 tracked disconnected, connecting, ready, degraded, review required, and disabled states per connection. Pending calls reached completed, failed, or unknown outcomes before a connection could be forgotten.

Removing a server revoked model exposure, adapter mappings, credentials under local control, scheduled retries, and cached capability handles. Historical traces retained safe identities and schema digests.

A stale task could not rediscover a similarly named server and resume with inherited authority.

Local did not mean trusted

One attraction of the early ecosystem was connecting local tools and data. Running on the same machine reduced some network concerns and introduced process, filesystem, credential, and supply-chain concerns.

V0M3 treated a local server as code with explicitly granted resources. The connection configuration named working directory, environment exposure, allowed paths, and process lifecycle where the host could enforce them. Secrets were not inherited wholesale from the desktop session.

A local server response could still contain hostile source text. A local tool could still be buggy or overbroad. Review and policy did not disappear at the loopback interface.

Location was one trust signal, not a verdict.

The opposite simplification was also wrong. A remote service could have mature authorization, narrow scopes, useful audit records, and a better data lifecycle than a casually installed local process.

V0M3 evaluated the configured connection against task requirements: data allowed to leave, credentials and scopes, server identity, capability mapping, retention assumptions, and effect recovery. A workspace could forbid remote processing for particular source classes.

The result was eligibility, not a global trusted badge. The same server might be allowed to search public documentation and prohibited from receiving a private draft.

Trust attached to a bounded use under current policy.

If a run used a tool on November 25 and the server exposed a different schema in December, replay needed to know what had originally been available.

V0M3 stored the relevant registry snapshot with tool schema digests, descriptions, adapter mapping revisions, and allowed capability set. The trace recorded which subset the model actually received.

Replay mode used fixtures bound to those identities. It did not contact the live server because the protocol made that convenient. A missing fixture stopped with a missing-contract error.

The standard made capturing the connection shape easier. Durable evaluation still required freezing the observed world around it.

Conformance was not behavioral proof

A server could implement the protocol correctly while its underlying operation behaved badly. It might return success before an export was durable, mishandle duplicate requests, expose changing data under a stable resource identity, or ignore cancellation.

V0M3 added adapter contract fixtures for the behaviors its product relied on. Synthetic calls checked schema mapping, duplicate effect identity, query behavior, redaction, output size, error mapping, and shutdown.

Passing protocol conformance would be useful. Passing product fixtures answered a different question: can this mapping uphold V0M3's promises?

Both levels mattered, and neither replaced review of the server's real scope.

Credentials belonged to the connection, not the model

Whether a server used local process access or remote credentials, V0M3 kept secrets outside model-visible context and tool arguments. The connection resolved them at execution time after current policy passed.

Scopes were as narrow as the server and product allowed. A read-only source capability did not share a credential capable of publishing merely because both lived behind one endpoint. Expiry and revocation changed connection eligibility immediately.

Receipts named a safe credential identity or scope revision where useful, never the secret. Rotating credentials did not rewrite old traces, and an old approval did not grant a newly broadened credential the right to act.

The protocol carried a request. Credential management still determined which system identity stood behind it.

Two servers could expose a tool named search and a resource with a similar URI. Displaying them in one flat catalogue invited accidental substitution.

V0M3 kept server registry identity in every discovered object and adapter mapping. Product capabilities could prefer one reviewed mapping and name fallbacks explicitly. A fallback to another server re-evaluated data policy, schema, behavior fixtures, and current health.

The model saw the stable product capability rather than a choice between ambiguous duplicate names. Diagnostics could still trace the selected server and remote object exactly.

Interoperability made composition possible. Namespacing and policy prevented composition from becoming alias confusion.

Server updates were migrations

Connection restart could reveal changed schemas, descriptions, resources, or protocol behavior. V0M3 compared discovery snapshots and classified the difference before returning the mapping to service.

An additive optional field might pass compatibility checks. A changed required argument, broader description, removed resource, or different effect behavior required review and a new adapter revision. In-flight calls stayed attached to their starting snapshot.

Rollback restored the earlier local mapping only if the corresponding server behavior still existed. The registry never claimed that pinning metadata could force a remote endpoint to behave like yesterday.

Treating update as migration created a place for testing, rollout, and retirement rather than making reconnection an implicit upgrade.

Results respected output budgets

A well-formed server result could be enormous, binary, recursively linked, or expensive to place into model context. V0M3 bounded response bytes, item counts, media types, and follow-up retrieval before invocation.

The adapter stored a durable observation or streamed it into approved asset storage, then selected a safe excerpt for the task. Truncation and omitted fields were visible. Raw content was not copied into logs by default.

If the result exceeded the contract, the call failed or returned a reference requiring deliberate inspection. The model did not receive an unlimited context expansion because a standard tool returned it.

Output governance was as important as argument validation.

An investigation needed to connect the author's intended consequence with the MCP interaction that implemented it. V0M3 recorded both.

The trace linked product capability, normalized arguments, policy decision, approval receipt, adapter revision, server identity, tool identity and schema digest, remote request evidence, result digest, and final product state. Sensitive payloads followed retention and redaction rules.

This prevented two incomplete stories. A product-only log could not diagnose server drift. A protocol-only log could show a valid call without explaining why V0M3 considered it allowed.

The boundary was trustworthy only when evidence crossed it without collapsing either side.

The model saw less than discovery found

An MCP server could expose a large catalogue. Sending every tool and resource description into every task consumed context and increased accidental selection.

V0M3 constructed the allowed set after task planning and policy. A source-review task might receive one bounded retrieval capability. A pure rewrite received no external tools. Consequential export remained unavailable until an artifact reached the appropriate state.

The trace distinguished discovered, mapped, eligible, offered, requested, approved, and executed. This made it possible to diagnose whether the problem was integration, selection, or policy.

Interoperability expanded the catalogue. Progressive disclosure kept the working capability small.

The first integration was intentionally boring

I resisted connecting V0M3 to a dramatic external action. The initial MCP adapter exposed a read-only synthetic source library already represented by K81R's evidence contract.

That narrow exercise tested discovery, server identity, resource revisions, content handling, schema drift, disconnection, and replay fixtures without risking a real external effect. Only after those paths were observable did I map a local preview renderer.

The protocol worked as hoped: less bespoke connection code and a clearer boundary for reusable servers. The remaining work was familiar application engineering.

That familiarity was reassuring. A standard should remove accidental differences, not suspend judgment.

The launch validated an old design choice

V0M3's product capabilities had existed before MCP. They kept provider and tool details behind adapters because document state needed stable concepts.

The new protocol fit that boundary. It could become one connection family alongside direct adapters, not a reason to replace the domain model. Existing policy, approval, evidence, and receipts continued to govern consequences.

This was the encouraging part of the launch for me. Interoperability arrived without requiring the document to yield authority to the integration.

A connection is only a connection

MCP made it more plausible for useful tools and contextual resources to connect across applications. That mattered. Shared infrastructure could reduce duplicate adapters and encourage capabilities to be described in a consistent shape.

The shape still carried untrusted names, schemas, content, and results across a boundary. Server identity, requester authority, resource scope, effect semantics, privacy, approval, recovery, and replay remained local responsibilities.

Treating those responsibilities as objections to the protocol would miss its value. Treating the protocol as their solution would create a dangerous gap.

V0M3 chose the middle position: use the standard for what it standardized, preserve evidence about the connection, and keep product authority immediately around every consequence.

The connection became easier. Trust stayed earned, scoped, and revocable.