Publish versioned types (TypeScript, Zod, etc) for server.json

[felixrieseberg]

Is your feature request related to a problem? Please describe.

I'd like to align https://github.com/anthropics/dxt as much as possible server.json. I believe a first good step here would be to create an "importer" that is able to create a valid manifest.json from a server.json - before we eventually tell everyone to just create a server.json instead.

To do so, I'd need types.

Describe the solution you'd like
In my dreams, we'd have versioned https://zod.dev types for server.json, but I'd also be happy about being able to call npm i @modelcontextprotocol/registry/types.

Describe alternatives you've considered
While I could make this entire repo a git submodule and run an OpenAPI converter to get TypeScript types, I'd feel better knowing that I'm importing the "official" types.

[tadasant]

This makes sense as a need!

I think long-term we'd want these server.json specs and types to live in a repo that is not tied to the registry (seeing as registry is just one use case of server.json). Which probably means getting it into the official schema, and then making sure you have a path to getting the types from there: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-03-26/schema.ts.

My expectation is that eventually the server.json schema will just be part of the official MCP spec, versioned alongside it, etc. And that already has the TS types (not Zod unfortunately, but maybe that's an enhancement convo to consider there as a separate convo).

In the meantime though, in the interest of moving quickly, we should probably come up with a strategy for where the "registry SDK(s)" will live, and we could publish the server.json types alongside the TypeScript implementation of that to serve your use case.

My inclination is just to use modelcontextprotocol/registry as a monorepo and start a folder called sdk at the root, first subfolder typescript. We could set up an npm package like @modelcontextprotocol/registry-sdk and include the types in that so you can do npm i @modelcontextprotocol/registry-sdk/types.. Eventually you could swap that out with perhaps npm i @modelcontextprotocol/sdk/types when server.json is in the official spec and in the core SDKs.

Is that making sense to balance short term vs. long term path?

cc @connor4312 @joelverhagen as I suspect you will thoughts on this SDK layer in general.

cc @toby - Would we be ok treating modelcontextprotocol/registry as a monorepo with a bunch of SDK code in it too? Unlike the core MCP SDK's, I think these SDK's should largely be OpenAPI wrappers, maybe we can code-generate them all.

[joelverhagen]

I don't have a strong feeling about it beyond the root schema.json.

On NuGet/NuGetGallery, we have our own minimal models used for reading the .mcp/server.json embedded in a NuGet package and then mapping it to the VS Code configuration format. I think it would be cool if these .NET types existed, and even client-specific mappers, but the code is pretty small so I can see it going any way (copy paste code, make your own, or use an SDK).

[connor4312]

I think it would probably make sense to have these types eventually live in the existing MCP SDKs, or something in the area. I do wish there was a minimal types-only package of the TS SDK we could consume, but that's a separate discussion, and I don't think we should proliferate types elsewhere in the meantime,

[felixrieseberg]

I think it would probably make sense to have these types eventually live in the existing MCP SDKs, or something in the area.

That'd make importing them really easy and also allow us to easily propagate them across different languages