--- title: "16. Conformance" description: "MCP Description specification v0.9.0-rc.3 — 16. Conformance." source: "https://mcpdesc.org/docs/specification/0.9.0-rc.3/conformance/" --- ### 16.1 Document Conformance [](/docs/rules/0.9.0-rc.3/mcpdesc/document-schema#required-by "This requirement is part of rule: mcpdesc.document.schema") A conforming MCP Description document MUST: 1. Decode from one conforming JSON or restricted YAML serialization to the JSON-compatible MCP Description data model (Sections 3.1 and 15). 2. Include the `mcpdesc` property with a recognized specification version (Section 4). 3. Include the `info` object with at least `name` and `version` (Section 5). 4. Include non-empty root `protocolVersions` containing only protocol versions supported by mcpdesc 0.9.0 (Section 4). 5. Contain at least one entry in every present ordinary declaration collection (Section 3.3). 6. When `transports` is present, contain at least one Transport Object and provide complete root protocol coverage (Section 6). 7. [](/docs/rules/0.9.0-rc.3/mcpdesc/document-schema#required-by "This requirement is part of rule: mcpdesc.document.schema") Validate against the JSON Schema for the declared `mcpdesc` version. 8. Satisfy semantic scope, identifier, Elicitation Declaration, client-requirement, security-reference, tag-reference, component-reference, protocol version-applicability, embedded Tool schema and example, and `x-mcp-header` constraints. 9. Not contain unknown properties on closed MCP Description-defined objects except specification extensions matching `^x-` at eligible locations. ### 16.2 Implementation Conformance A conforming implementation (tool, validator, or platform) MUST: 1. Support at least one conforming serialization and declare JSON, YAML, or both for each applicable input or output capability. 2. Accept and correctly parse conforming documents in every serialization for which it claims input support. 3. Emit only conforming documents in every serialization for which it claims output support. 4. Reject documents that fail the requirements in Section 16.1 or the restricted profile of a claimed input serialization. 5. Ignore unrecognized specification extensions when interpreting core semantics and accept them without error at eligible locations (Section 14.4). 6. Preserve root and object-level specification extensions when processing, projecting, merging, and reserializing documents unless explicitly requested to strip them (Sections 14.4 and 14.5). Native MCP projection produces MCP values, not documents, and omits them (Section 4.14). 7. Apply the same structural JSON Schema validation and cross-object semantic requirements after decoding JSON or YAML. 8. Use safe YAML parsing and reject unsupported YAML constructs when claiming YAML input support (Section 15.3). 9. Apply reasonable document-size, nesting-depth, scalar-length, and collection-size limits to supported input serializations. 10. Resolve `$componentRef` only within the same parsed document, without network access, before contextual semantic validation. The published JSON Schema expresses structural constraints only. JSON-Schema-only acceptance is insufficient for document conformance because protocol scope, protocol version applicability, Client Capability Requirements, Elicitation Declarations, security and component reference resolution, embedded Tool schemas and examples, extension namespace diagnostics, and other cross-object rules require semantic validation. A warning condition defined by this specification is non-fatal and does not by itself make a document non-conforming. An implementation MAY offer a stricter profile that promotes warnings to errors, but it MUST identify that profile separately from baseline mcpdesc conformance. Complete protocol-version-specific `_meta` validation begins with MCP 2025-06-18\. [](/docs/rules/0.9.0-rc.3/mcpdesc/legacy-protocol-validation-scope#required-by "This requirement is part of rule: mcpdesc.legacy-protocol.validation-scope") For the recognized legacy compatibility protocol versions MCP 2024-11-05 and MCP 2025-03-26, validators MUST apply sound structural and selected checks, SHOULD warn that validation is incomplete, and MUST NOT report partial validation as complete MCP semantic conformance. A conforming implementation SHOULD: 1. Support at least the current specification version. 2. Provide clear error messages when rejecting non-conforming documents. 3. Support JSON Schema validation against the published schema. ### 16.3 Partial Conformance Implementations that support only a subset of the specification (e.g., only tools, or only a specific transport type) SHOULD document their limitations clearly. ### 16.4 Versioned Conformance Conformance is assessed against a specific specification version. An implementation claiming conformance MUST state which `mcpdesc` version(s) it supports. ### 16.5 Validation Results Validation rules identify the requirements that validators check (Section 2.3). The validation result format, published as [validation/result.schema.json](https://github.com/mcpdesc/mcpdesc-specification/blob/v0.9.0-rc.3/spec/draft/validation/result.schema.json), represents diagnostics and rule results; [validation/README.md](https://github.com/mcpdesc/mcpdesc-specification/blob/v0.9.0-rc.3/spec/draft/validation/README.md#rule-results) explains them. Each diagnostic that a validator reports MUST identify the registered validation rule it reports, its severity, and the location it concerns in the document. When the finding depends on an MCP protocol version, the diagnostic SHOULD identify that version. A diagnostic MAY carry a code and a message; their values belong to the validator and are not defined by this specification. The location of a diagnostic MUST identify a value or member name present in the document as written, before component references are replaced. A diagnostic for a missing member MUST identify the closest enclosing object; in validation result format `1.4.0`, its `detail.member` MUST identify the missing member and its message, when present, SHOULD identify it. A diagnostic for an unexpected or invalid member name MUST identify that member. A diagnostic for content reached through `$componentRef` MUST identify the reference object at the use site as its primary location. In format `1.4.0`, it MUST also include the location within the component as a related location with relation `component-definition`. When chained references are resolved, the related location is in the final component definition. For a finding at resolved path `P`, the resolver selects the provenance entry whose `referencePath` is the longest prefix of `P` (including `P` itself). The primary location is that `referencePath`; the related location is the entry’s `targetPath` followed by the remainder of `P`. When no entry matches, `P` is already a source-document location. The related location for a missing member identifies the enclosing component object. The document schema MUST express every union with a deterministic, portable selector as guarded conditionals using JSON Schema 2020-12\. A guard MUST use a discriminator value, the presence of `$componentRef`, a JSON type, or defining members; a discriminator guard MAY be combined with defining members. The conditionals MUST select only the applicable alternative and preserve the original acceptance constraints, including closure, required members, and specification extensions, except for the explicit closure of the Elicitation Interaction Response Object in [Section 9.4](https://github.com/mcpdesc/mcpdesc-specification/blob/v0.9.0-rc.3/spec/draft/sections/09-tools.md#req-interaction-response-closed). A selector typo does not authorize a validator to infer the intended alternative. A schema check MUST reject unreviewed `oneOf`/`anyOf` occurrences and conditional guards outside these forms. An allowlisted `anyOf` remains inclusive and MUST produce one `missing-alternative` finding at the union value when it fails; failures of its individual alternatives MUST NOT be emitted. For each discriminated object union, the parent schema MUST declare the union of member names accepted by its alternatives, keep the discriminator’s constraint, and reject other members while preserving its specification- extension pattern. Other parent member schemas MUST be `true` so value constraints remain in the selected branch. Alternative schemas retain their own closure; a member allowed by a different alternative remains invalid in the selected alternative. Findings from the selected `then` or `else` branch MUST be retained. A failure reported for an `if` keyword MUST NOT be emitted when another finding exists at or below the same instance location. Otherwise it MUST be emitted as kind `constraint` with keyword `if`. A `not` failure over `required` members MUST produce one `conflicting-members` finding at the object. Its member list names the enclosing guard’s required members followed by the members forbidden by `not`; when selected by a discriminator, it also identifies that selector. Unselected alternatives MUST NOT be reconstructed or inferred. A schema-derived finding MUST be attributed to the rule whose catalog schema pointer is the longest prefix of the absolute schema pointer of the subschema containing the failing keyword. This is the location in the document schema, not an engine evaluation path relative to a `$ref`. A shared definition is therefore attributed to the same rule wherever it is used. A validator MUST NOT attribute a finding to an enclosing union by choosing a best-matching alternative. Findings removed by conditional or `anyOf` reduction MUST NOT cause a rule to be reported as `failed`. Validation result format `1.4.0` defines factual `detail` for findings derived from the document schema. It identifies missing, unexpected, or invalid members and values; expected types; conflicting members; missing alternatives; and the failing keyword for other constraints. `allowedValues`, `allowedMembers`, and `expectedTypes` describe the subschema that reported the finding. The format also defines related component locations. `kind` is extensible; consumers MUST fall back to `message` for an unrecognized kind. Detail states facts, not remedies. The location, rule, severity, conditional reduction, and generic handling of remaining `anyOf` and `not` findings are specified; raw engine error counts, schema paths, `code`, and `message` wording are not. Duplicate findings share their source path, rule, severity, kind, and relevant member or member-list facts; constraint findings are distinguished by failing keyword. Only one duplicate MUST be emitted: the one whose failing keyword has the longest absolute schema pointer. Independent findings MUST be retained. Diagnostic order is not part of the contract; producers SHOULD order findings by document position. A validator MAY report rule results. A validator that claims conformance with this specification’s validation fixtures MUST report them: one status for each rule and each protocol version declared by the document, or one status for a rule whose applicability does not depend on the protocol version. A status is `passed`, `failed`, `warning`, `not-applicable`, `not-evaluated`, or `delegated`. Rule results do not change document validity, which errors alone determine. A rule result MUST come from the checks the validator executed. A validator MUST NOT report `passed` for a rule that it did not check for that protocol version, including when an earlier validation stage failed, when it does not implement the check, or when the check is not applied to a legacy compatibility protocol version.