Extension
Compatibility Mode
Hold an omcp implementation to MCP-defined behaviour, and decide for yourself when to take what omcp adds
omcp is a superset of the Model Context Protocol. Everything it adds is additive, so an MCP client or server interoperates with omcp untouched — that direction is guaranteed by the rule every omcp change is held to.
Compatibility mode is the other direction. It lets an operator hold an omcp implementation to MCP-defined behaviour only, and decide for themselves when to take what omcp adds, rather than having that decided for them by whoever ships the implementation.
The setting
| Name | compatibility_mode |
| Values | no (default), yes |
| Environment | OMCP_COMPATIBILITY_MODE |
Precedence is explicit configuration, then the environment, then the default. An empty or absent environment variable is not a configured value.
# The default: omcp's additions are available.
OMCP_COMPATIBILITY_MODE=no
# Hold this implementation to MCP-defined behaviour.
OMCP_COMPATIBILITY_MODE=yes
yes, true, 1 and on all mean yes; no, false, 0 and off all mean no; case and
surrounding whitespace do not matter. Anything else is an error, deliberately: reading
enabled as "no" would switch compatibility off for an operator who was asking for it on, which
is the one way this setting must not fail.
What yes does
An implementation in compatibility mode behaves as plain MCP: it advertises no omcp extensions, does not fetch server attestations, and emits no omcp-only fields, including tamper-evident audit records.
Some of that this repository enforces, and some of it belongs to the implementation. It is worth being exact about which:
| Enforced here | Left to the implementation |
|---|---|
admitServer does not evaluate an attestation; it returns "not applied" |
Not advertising omcp extensions on connect |
verifyAttestation raises an error if called anyway |
Not fetching the well-known attestation resource |
| The error names the addition and the variable to change | Not emitting audit records |
const outcome = admitServer(document, trustRoot, context);
if (!outcome.applied) {
// Compatibility mode: attestation was not evaluated. Decide what that means
// for this deployment — it is not an admission.
} else if (outcome.result.admitted) {
// Verified.
}
What yes does not do
It does not reject omcp traffic. An omcp-specific element arriving from a peer is ignored, exactly as MCP already treats unknown fields — in both modes.
Rejecting would be the stricter reading, and it is the wrong one: it would make an omcp peer fail against a compatibility-mode implementation, breaking the interoperability the setting exists to protect. Compatibility mode constrains what an implementation does, not what it tolerates.
Why it exists
A protocol used in production evolves on the timeline of whoever governs it, and that timeline is not always yours. omcp's answer is to make evolution available without making it compulsory: take the additions when they are useful to you, or pin to MCP-defined behaviour and lose nothing.
The default is no because omcp's additions are safe by construction — additive, ignorable, and
invisible to a peer that does not implement them. An operator who wants the guarantee in writing
rather than by construction sets it to yes.
Implementing it
The reference implementation is in this repository at extensions/compatibility-mode, with tests
covering resolution order, the accepted spellings, the refusal to guess at unrecognised values,
and the guard that fires when an addition is used while the mode is on.
npm test