Changelog
Changelog
Section titled “Changelog”All notable changes to the MCP Description Specification will be documented in this file.
The format is based on Keep a Changelog.
This project uses specification versioning aligned with its mcpdesc field.
- [0.8.0] — 2026-09-09
- [0.7.0] — 2026-03-23
- [0.6.0] — 2026-03-20
- [0.5.2] — 2026-03-18
- [0.5.1] — 2026-03-17
- [0.5.0] — 2026-03-17
- [0.4.0] — 2026-03-16
- [0.3.0] — 2026-01-15
- [0.1.0] — 2025-11-01
[0.8.0] — 2026-09-09
Section titled “[0.8.0] — 2026-09-09”Version 0.8 adds protocol-version-scoped declarations and deterministic views for each supported MCP protocol version.
It also introduces reusable components, richer examples and interaction scenarios, client capability requirements, elicitation declarations, extension support, and stronger validation across JSON and YAML documents.
The accepted proposals represented by this release are listed in the 0.8.0 proposal revision manifest.
Breaking
Section titled “Breaking”- Removed
info.protocolVersionand added required rootprotocolVersionsusing the closed set of MCP revisions whose semantics 0.8.0 validates (Proposal 0001). - Changed root
capabilitiesfrom one object to an array of protocol-scoped Capabilities Objects (Proposal 0001). - Replaced inline security definitions with named root
securitySchemesand Security Requirement Arrays (Proposal 0003). - Required every Tool to contain an object-rooted
inputSchema(Proposal 0001).
- MCP
2026-07-28support and protocol applicability across transports, capabilities, and primitive declarations (Proposal 0001). - Deterministic Effective Protocol Views with projection and conflict-detecting merge behavior (Proposal 0001).
- Root
instructions, formal MCP extension declarations, and primitiveclientRequirements(Proposals 0001, 0012). - Named Tool, Resource, Resource Template, and Prompt examples, plus Tool interaction and completion examples (Proposals 0004, 0005, 0015, 0016, 0017).
- Reusable typed
componentsreferenced through local$componentRefobjects (Proposal 0009). - Operation-level elicitation declarations and object-level
x-*specification extensions (Proposals 0007, 0011). - JSON and restricted YAML serializations, canonical versioned schema URIs, and expanded semantic validation (Proposals 0010, 0019).
Changed
Section titled “Changed”- Defined the root Info Object as document-wide metadata independent of MCP protocol revisions, preserving all Info properties during migration and projection and removing runtime
Implementationavailability gates (Proposal 0022). - Made
transportsoptional and defined omission of an optional section as no declaration rather than evidence of runtime non-support (Proposal 0013). - Required ordinary declaration collections to be non-empty when present and projection or merge to omit collections that become empty (Proposal 0013).
- Defined MCP 2025-06-18 as the floor for complete revision-specific semantic validation; older recognized revisions produce incomplete-validation diagnostics (Proposals 0001, 0002).
- Aligned Tool, Resource, Resource Template, Prompt, annotation,
_meta, and extension validation with their applicable MCP revisions (Proposals 0001, 0002). - Treated pre-standard or unrecognized MCP extension declarations and unresolved external Tool schema references as warning-and-preserve conditions (Proposals 0001, 0021).
- Distinguished MCP 2025-11-25 core Tasks from MCP 2026-07-28 Tasks extensions (Proposal 0001).
- Made active specification examples vendor-neutral and removed bundled vendor-specific extension metadata (editorial).
[0.7.0] — 2026-03-23
Section titled “[0.7.0] — 2026-03-23”Changed
Section titled “Changed”- Simplified tags to flat structure — removed hierarchical nesting. The Tag Object no longer includes a recursive
tagsproperty. All tags are now declared in a flat array at the root level. - Tag uniqueness requirement simplified — tag names MUST be unique across all tags (previously “across the entire tag tree”).
- Tag reference validation simplified — per-entity tags must reference tag names declared in the root
tagsarray (no nesting levels to traverse). - Added
uniqueItems: trueconstraint to per-entitytagsarrays on tools, resources, resource templates, and prompts to prevent duplicate tag references.
Removed
Section titled “Removed”- Removed hierarchical tag support — Tag Objects no longer support nested
tagsarrays. The tag taxonomy is now a simple flat list.
Updated
Section titled “Updated”- Section 12 (Tags) — completely rewritten to reflect flat tag structure. Removed hierarchical examples and references to “tag tree” and “nesting levels”.
- All examples — converted from hierarchical tags to flat tag lists (stdio-server, http-server, full-featured examples in both JSON and YAML formats).
[0.6.0] — 2026-03-20
Section titled “[0.6.0] — 2026-03-20”Removed
Section titled “Removed”- Removed the
metadataobject from the root document structure. Theauthors,documentation, andrepositoryfields are redundant withinfo.contactandinfo.websiteUrl, or belong in vendor extensions. - Removed the
lifecycleobject from the root document structure. Server lifecycle management belongs in a server manifest or registry, not in a static capability description.
- Root-level
tagsarray with structured Tag Objects (name,description,tags) replacingmetadata.tags. Tags support hierarchical nesting via nestedtagsarrays (Option C). Tag names MUST be globally unique across the entire tree. - Tag reference validation requirement — per-entity
tagson tools, resources, resource templates, and prompts MUST reference tag names declared in the roottagsarray when present. Undeclared tag references are a validation error.
Changed
Section titled “Changed”- Section 12 rewritten from “Metadata” to “Tags” — defines the Tag Object, uniqueness constraints, and tag reference semantics.
- Sections 9, 10, 11 — per-entity
tagsdescription updated with normative cross-reference to Section 12.3 tag declaration requirement. - Section 3 root object table —
metadataandlifecyclerows removed;tagsrow added. - Sections renumbered — removal of lifecycle (formerly Section 12) shifts Tags to 12, Specification Extensions to 13, Serialization to 14, Conformance to 15.
[0.5.2] — 2026-03-18
Section titled “[0.5.2] — 2026-03-18”Changed
Section titled “Changed”- Documented MCP
Implementationtype provenance in the Info Object —name,title,description,version,icons, andwebsiteUrlare now explicitly traced to the MCPImplementationtype returned in theinitializeresponse (serverInfo), with protocol version annotations:title— MCPBaseMetadata, since 2025-06-18description— MCPImplementation, since 2025-11-25websiteUrl— MCPImplementation, since 2025-11-25icons— MCPImplementation(viaIconsmixin), since 2025-11-25
- Updated Info Object example to include
iconsandwebsiteUrlfields - Clarified
contactandlicenseas OpenAPI-style additions not present in the MCPImplementationtype
[0.5.1] — 2026-03-17
Section titled “[0.5.1] — 2026-03-17”Changed
Section titled “Changed”- Removed
_generatedfrom the core MCP Description specification (mcpdesc: "0.5.1"), including the root object definition and current schema. - Updated Cisco extension to
x-cisco-metadatav0.2.0 shape with extension-levelversionand nesteddumppayload - Removed
_generatedfrom Cisco extension examples, with provenance retained inx-cisco-metadata.dump(toolName,toolVersion,createdAt)
[0.5.0] — 2026-03-17
Section titled “[0.5.0] — 2026-03-17”Changed
Section titled “Changed”- Renamed
transportfield totransports(plural) for consistency withtools,resources,promptsand OpenAPI’sservers— see DECISION-001 - Added transport-scoped
security— each transport MAY include its ownsecurityarray that overrides the root-level default (see Section 6.4) - Root-level
securityis now the default; transport-levelsecurityoverrides it (OpenAPI-style inheritance)
[0.4.0] — 2026-03-16
Section titled “[0.4.0] — 2026-03-16”- MCP 2025-11-25 support: icons, websiteUrl, task capabilities, tool execution properties
- Tool
outputSchemawith explicit$schemadialect support (MCP 2025-06-18+) - Tool
execution.taskSupportproperty for task-augmented execution (MCP 2025-11-25 only) iconsdefinition for server, tools, resources, resource templates, and promptscapabilities.tasksfor task-augmented request supportcapabilities.completionsandcapabilities.loggingdeclarations
Changed
Section titled “Changed”- Renamed
mcpspecfield tomcpdescto clearly distinguish the description format version from the MCP protocol specification version protocolVersionenum now includes2025-11-25- Tool
annotationsnow supportsadditionalPropertiesfor forward compatibility
[0.3.0] — 2026-01-15
Section titled “[0.3.0] — 2026-01-15”titlefield on all MCP entities (BaseMetadata, since MCP 2025-06-18)- Tool
outputSchemafor structured tool output _metaprotocol-reserved metadata on tools, resources, resource templates, and promptstagsfor categorization on tools, resources, resource templates, and promptsdeprecatedflag on tools, resources, resource templates, and prompts
Changed
Section titled “Changed”- Aligned more closely with MCP 2025-06-18 protocol structures
[0.1.0] — 2025-11-01
Section titled “[0.1.0] — 2025-11-01”- Initial specification draft
- Core document structure:
mcpspec,info,transport,tools,resources,resourceTemplates,prompts - Transport definitions:
streamable-http,stdio,sse - Security schemes aligned with OpenAPI 3.1
capabilitiesobject from MCP InitializeResultmetadatafor authors, documentation, repository, tags_generatedprovenance tracking- Specification extension mechanism (
x-prefix) anyOfconstraint requiring at least one of tools, resources, resourceTemplates, or prompts