What's broken?
The boundary between Registry server.json, Server Card, and client installation behavior for local stdio MCP servers is unclear.
Where in the spec or docs?
What should happen?
There should be a clear answer for whether server.json, Server Card, or another manifest is intended to be the portable install manifest for local stdio MCP servers across clients.
The existing Registry docs already describe package metadata, stdio transport, environment variables, supported package types, and MCPB integrity metadata. What is not clear is whether clients should treat that metadata as normative installation/runtime guidance or registry-only discovery metadata.
In particular, it would be useful to clarify:
- How clients should resolve, install, and run stdio packages from
server.json.
- Which
server.json fields are normative for client installation behavior.
- How commands, args, environment variables, secrets, hashes, provenance, and user consent should be represented.
- Whether
server.json is expected to align with or become part of Server Card.
- Whether this is already covered by an existing SEP, Registry WG work item, or Server Card alignment proposal.
What actually happens?
The current documentation provides the building blocks, but I could not find a dedicated SEP or normative specification for portable stdio package installation manifests.
SEP-1024 is adjacent, but it focuses on client security requirements for local server installation consent and command transparency. It does not define a full interoperable manifest format or client behavior for resolving/installing/running stdio MCP server packages.
The Registry WG charter says the group owns the registry service, server.json schema, package metadata, runtime configuration, and Server Card alignment. That makes this seem in scope for Registry WG / Server Card work, but it is not obvious from the docs whether a SEP or proposal already tracks it.
Anything else?
What's broken?
The boundary between Registry
server.json, Server Card, and client installation behavior for local stdio MCP servers is unclear.Where in the spec or docs?
server.json: https://modelcontextprotocol.io/registry/quickstartWhat should happen?
There should be a clear answer for whether
server.json, Server Card, or another manifest is intended to be the portable install manifest for local stdio MCP servers across clients.The existing Registry docs already describe package metadata, stdio transport, environment variables, supported package types, and MCPB integrity metadata. What is not clear is whether clients should treat that metadata as normative installation/runtime guidance or registry-only discovery metadata.
In particular, it would be useful to clarify:
server.json.server.jsonfields are normative for client installation behavior.server.jsonis expected to align with or become part of Server Card.What actually happens?
The current documentation provides the building blocks, but I could not find a dedicated SEP or normative specification for portable stdio package installation manifests.
SEP-1024 is adjacent, but it focuses on client security requirements for local server installation consent and command transparency. It does not define a full interoperable manifest format or client behavior for resolving/installing/running stdio MCP server packages.
The Registry WG charter says the group owns the registry service,
server.jsonschema, package metadata, runtime configuration, and Server Card alignment. That makes this seem in scope for Registry WG / Server Card work, but it is not obvious from the docs whether a SEP or proposal already tracks it.Anything else?