A batch of wording/terminology alignment items. None is individually large, but all four leave the spec disagreeing with itself or with a recorded ADR.
1. "Media type" leftovers from before ADR 0014
ADR 0014's stated motivation for renaming mediaType to type was that "using the name mediaType implies support for any valid IANA media type ... which is not the intent". But the Terminology section still defines a Catalog Entry as "identified by a media type", and Design Goal 2 still says each entry "MUST declare its artifact type using a media type". The type field definition and the MCP appendix note already use the correct "open type identifier" framing; the intro material should match.
2. Discovery step 4 is stricter than Location Independence allows
"Link Relation Discovery" step 4 treats a response as a catalog only "if the response has a media type of application/ai-catalog+json", but "Location Independence" makes serving that media type a SHOULD, and the docs explicitly accept application/json as fine in practice. A catalog served as application/json would pass the well-known flow but fail the link-relation flow. Step 4 should tolerate generic JSON media types (e.g. check for a JSON media type plus a valid specVersion).
3. ADR 0010 follow-up: "AI Card" terminology entry is missing
ADR 0010's consequences say: "The spec should define 'AI Card' in its terminology section as the umbrella concept for any AI artifact metadata document." The Terminology section has no such entry.
4. ADR 0007 follow-up: url vs uri naming is inconsistent
ADR 0007's consequences say "The field is named url across all objects (catalog entries, collection references, attestations)", but the Attestation object uses uri, and the spec mixes suffix conventions overall: documentationUrl, logoUrl, privacyPolicyUrl, termsOfServiceUrl vs governanceUri, registryUri, statementUri, and attestation uri. Either normalize the field names, or update ADR 0007 to record the deliberate split (e.g. url for fetchable HTTP resources, uri where non-fetchable identifiers are allowed) so implementers know it is intentional.
A batch of wording/terminology alignment items. None is individually large, but all four leave the spec disagreeing with itself or with a recorded ADR.
1. "Media type" leftovers from before ADR 0014
ADR 0014's stated motivation for renaming
mediaTypetotypewas that "using the name mediaType implies support for any valid IANA media type ... which is not the intent". But the Terminology section still defines a Catalog Entry as "identified by a media type", and Design Goal 2 still says each entry "MUST declare its artifact type using a media type". Thetypefield definition and the MCP appendix note already use the correct "open type identifier" framing; the intro material should match.2. Discovery step 4 is stricter than Location Independence allows
"Link Relation Discovery" step 4 treats a response as a catalog only "if the response has a media type of
application/ai-catalog+json", but "Location Independence" makes serving that media type a SHOULD, and the docs explicitly acceptapplication/jsonas fine in practice. A catalog served asapplication/jsonwould pass the well-known flow but fail the link-relation flow. Step 4 should tolerate generic JSON media types (e.g. check for a JSON media type plus a validspecVersion).3. ADR 0010 follow-up: "AI Card" terminology entry is missing
ADR 0010's consequences say: "The spec should define 'AI Card' in its terminology section as the umbrella concept for any AI artifact metadata document." The Terminology section has no such entry.
4. ADR 0007 follow-up: url vs uri naming is inconsistent
ADR 0007's consequences say "The field is named
urlacross all objects (catalog entries, collection references, attestations)", but the Attestation object usesuri, and the spec mixes suffix conventions overall:documentationUrl,logoUrl,privacyPolicyUrl,termsOfServiceUrlvsgovernanceUri,registryUri,statementUri, and attestationuri. Either normalize the field names, or update ADR 0007 to record the deliberate split (e.g.urlfor fetchable HTTP resources,uriwhere non-fetchable identifiers are allowed) so implementers know it is intentional.