Skip to content

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.

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.

  • Removed info.protocolVersion and added required root protocolVersions using the closed set of MCP revisions whose semantics 0.8.0 validates (Proposal 0001).
  • Changed root capabilities from one object to an array of protocol-scoped Capabilities Objects (Proposal 0001).
  • Replaced inline security definitions with named root securitySchemes and Security Requirement Arrays (Proposal 0003).
  • Required every Tool to contain an object-rooted inputSchema (Proposal 0001).
  • MCP 2026-07-28 support 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 primitive clientRequirements (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 components referenced through local $componentRef objects (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).
  • 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 Implementation availability gates (Proposal 0022).
  • Made transports optional 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).
  • Simplified tags to flat structure — removed hierarchical nesting. The Tag Object no longer includes a recursive tags property. 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 tags array (no nesting levels to traverse).
  • Added uniqueItems: true constraint to per-entity tags arrays on tools, resources, resource templates, and prompts to prevent duplicate tag references.
  • Removed hierarchical tag support — Tag Objects no longer support nested tags arrays. The tag taxonomy is now a simple flat list.
  • 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).
  • Removed the metadata object from the root document structure. The authors, documentation, and repository fields are redundant with info.contact and info.websiteUrl, or belong in vendor extensions.
  • Removed the lifecycle object from the root document structure. Server lifecycle management belongs in a server manifest or registry, not in a static capability description.
  • Root-level tags array with structured Tag Objects (name, description, tags) replacing metadata.tags. Tags support hierarchical nesting via nested tags arrays (Option C). Tag names MUST be globally unique across the entire tree.
  • Tag reference validation requirement — per-entity tags on tools, resources, resource templates, and prompts MUST reference tag names declared in the root tags array when present. Undeclared tag references are a validation error.
  • Section 12 rewritten from “Metadata” to “Tags” — defines the Tag Object, uniqueness constraints, and tag reference semantics.
  • Sections 9, 10, 11 — per-entity tags description updated with normative cross-reference to Section 12.3 tag declaration requirement.
  • Section 3 root object table — metadata and lifecycle rows removed; tags row added.
  • Sections renumbered — removal of lifecycle (formerly Section 12) shifts Tags to 12, Specification Extensions to 13, Serialization to 14, Conformance to 15.
  • Documented MCP Implementation type provenance in the Info Objectname, title, description, version, icons, and websiteUrl are now explicitly traced to the MCP Implementation type returned in the initialize response (serverInfo), with protocol version annotations:
    • title — MCP BaseMetadata, since 2025-06-18
    • description — MCP Implementation, since 2025-11-25
    • websiteUrl — MCP Implementation, since 2025-11-25
    • icons — MCP Implementation (via Icons mixin), since 2025-11-25
  • Updated Info Object example to include icons and websiteUrl fields
  • Clarified contact and license as OpenAPI-style additions not present in the MCP Implementation type
  • Removed _generated from the core MCP Description specification (mcpdesc: "0.5.1"), including the root object definition and current schema.
  • Updated Cisco extension to x-cisco-metadata v0.2.0 shape with extension-level version and nested dump payload
  • Removed _generated from Cisco extension examples, with provenance retained in x-cisco-metadata.dump (toolName, toolVersion, createdAt)
  • Renamed transport field to transports (plural) for consistency with tools, resources, prompts and OpenAPI’s servers — see DECISION-001
  • Added transport-scoped security — each transport MAY include its own security array that overrides the root-level default (see Section 6.4)
  • Root-level security is now the default; transport-level security overrides it (OpenAPI-style inheritance)
  • MCP 2025-11-25 support: icons, websiteUrl, task capabilities, tool execution properties
  • Tool outputSchema with explicit $schema dialect support (MCP 2025-06-18+)
  • Tool execution.taskSupport property for task-augmented execution (MCP 2025-11-25 only)
  • icons definition for server, tools, resources, resource templates, and prompts
  • capabilities.tasks for task-augmented request support
  • capabilities.completions and capabilities.logging declarations
  • Renamed mcpspec field to mcpdesc to clearly distinguish the description format version from the MCP protocol specification version
  • protocolVersion enum now includes 2025-11-25
  • Tool annotations now supports additionalProperties for forward compatibility
  • title field on all MCP entities (BaseMetadata, since MCP 2025-06-18)
  • Tool outputSchema for structured tool output
  • _meta protocol-reserved metadata on tools, resources, resource templates, and prompts
  • tags for categorization on tools, resources, resource templates, and prompts
  • deprecated flag on tools, resources, resource templates, and prompts
  • Aligned more closely with MCP 2025-06-18 protocol structures
  • 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
  • capabilities object from MCP InitializeResult
  • metadata for authors, documentation, repository, tags
  • _generated provenance tracking
  • Specification extension mechanism (x- prefix)
  • anyOf constraint requiring at least one of tools, resources, resourceTemplates, or prompts