Add simplified example of spec compliance schema for sdks #442
Conversation
Co-authored-by: Cliff Hall <[email protected]>
Co-authored-by: Cliff Hall <[email protected]>
Co-authored-by: Cliff Hall <[email protected]>
compliance/schema.json
Outdated
| "schemaVersion": { | ||
| "type": "string", | ||
| "description": "The version of the schema this manifest complies with", | ||
| "pattern": "^[0-9]+(\\.[0-9]+)*(-[a-zA-Z0-9]+)?(\\+[a-zA-Z0-9]+)?$" |
There was a problem hiding this comment.
Adding a more visible note here from the resolved conversation above:
The MCP Spec schema itself uses calendar versioning, however my assumption is that this compliance schema would evolve independently from the spec itself (so it needs its own versions that tooling could reference).
There was a problem hiding this comment.
What do you think about adding a schemaLocation to point to the actual schema as opposed to (or in addition to) schemaVersion?
There was a problem hiding this comment.
Do mean something like: "schema_location": "https://modelcontextprotocol.io/schemas/sdk-compliance/v1.0.0/schema.json)<https://modelcontextprotocol.io/schemas/sdk-compliance/v1.0.0/schema.json"?
olaservo
requested review from
jspahrsummers,
tadasant,
dsp-ant,
ihrpr and
pcarleton
| } | ||
| } | ||
| }, | ||
| "last_updated": "2025-04-30" |
There was a problem hiding this comment.
Is the last update for the spec compliance file?
There was a problem hiding this comment.
Yes, that's what I was thinking.
compliance/schema.ts
Outdated
| | "python" | ||
| | "typescript" | ||
| | "java" | ||
| | "csharp"; |
There was a problem hiding this comment.
should those be added as well?
- kotlin
- go
- ruby
- rust
- swift
compliance/schema.json
Outdated
| "$schema": "http://json-schema.org/draft-07/schema#", | ||
| "title": "MCP SDK Support Manifest", | ||
| { | ||
| "schemaVersion": { |
There was a problem hiding this comment.
| "schemaVersion": { | |
| "schema_version": { |
@ihrpr I think that part is still up for discussion, we were originally talking about starting a support matrix for each sdk manually that references the structure defined here, then moving on to automating it. Lets chat more in the spec-compliance channel. |
|
Are the SDK authors fine with maintaining such a spec? |
|
@olaservo, would it make sense to have separate client and server transport feature fields for better coverage description? |
|
|
||
| export interface ClientFeatures { | ||
| roots?: boolean; | ||
| sampling?: boolean; |
|
Hi, going to close this for now since there are a few other efforts going on in this area. |
Adds a simplified example of a MCP spec compliance schema for SDKs.
Motivation and Context
Taken from @localden 's original document:
Today, developers can use any of the available Model Context Protocol (MCP) SDKs, that include Python, TypeScript, Java, Kotlin, or C#. These SDKs have varied levels of support for the capabilities outlined in the MCP specification.
As MCP evolves, new versions of the protocol specification are released – we started with 2024-11-05, and are now on 2025-03-26. SDKs, in their current implementation, carry no distinguishing information or markers that communicate to developers the fact that the SDK supports the full set or a subset of specific specification versions.
This proposal intends to establish a shared standard for how MCP SDKs declare their support for MCP capabilities outlined in the protocol specification documents.
How Has This Been Tested?
Has not yet been tested with an actual SDK, this is just to align on the structure and format.
Breaking Changes
N/A
Types of changes
Checklist
Additional context
Note that there is already a GitHub Project meant for tracking progress towards SDK compliance, but this PR proposes a structure for populating this information as a JSON file alongside each language SDK.