Very interested in this, is there a corresponding SEP Issue for it to facilitate discussion?

Some previous discussion: https://github.com/orgs/modelcontextprotocol/discussions/84

I strongly suggest adopting/embedding the server.json spec we're working on in the registry repo, as it provides mechanisms for command and input customization and runtime specifications which are not covered here https://github.com/modelcontextprotocol/registry/tree/main/docs/server-json In fact usage of that sever.json spec on well-known is an explicit goal :)

Very interested in this, is there a corresponding SEP Issue for it to facilitate discussion?

Not yet, sorry mind catching me up on what SEP means? Would it just be something like this? https://github.com/orgs/modelcontextprotocol/discussions/84

strongly suggest adopting/embedding the server.json spec we're working on in the registry repo

Ooh, thanks for letting me know! Will take a look, definitely happy to unify the proposals if it makes sense 👍

Very interested in this, is there a corresponding SEP Issue for it to facilitate discussion?

Not yet, sorry mind catching me up on what SEP means? Would it just be something like this? https://github.com/orgs/modelcontextprotocol/discussions/84

strongly suggest adopting/embedding the server.json spec we're working on in the registry repo

Ooh, thanks for letting me know! Will take a look, definitely happy to unify the proposals if it makes sense 👍

Yep! full details here: https://modelcontextprotocol.io/community/sep-guidelines

But we've gained a way to decide on these things :)

Some previous discussion: https://github.com/orgs/modelcontextprotocol/discussions/84

I strongly suggest adopting/embedding the server.json spec we're working on in the registry repo, as it provides mechanisms for command and input customization and runtime specifications which are not covered here https://github.com/modelcontextprotocol/registry/tree/main/docs/server-json In fact usage of that sever.json spec on well-known is an explicit goal :)

+1 on this!

You should feel free to evolve that shape to include the features important to the .well-known use case. We'd all benefit from aligning on this static representation of servers we can unify across all the relevant use cases.

I think the only thing missing from the current iteration of server.json for you is icon. I haven't proposed adding it there yet as that shape is under discussion here - probably worth aligning that SEP with this + the server.json.

Couple small thoughts from earlier conversations on .well-known:

1. mcp.json is a term that most people associate with configuring MCP servers on a local machine. I would highly suggest using server.json for this purpose instead; no ongoing collisions there and alignment with how the Registry is thinking about it
2. I think there'd be a lot of merit to considering declaring a .well-known directory instead of a single file, i.e. /.well-known/mcp/server.json. For one, it keeps the naming of the file consistent and simple, while still providing the mcp context in the directory name (anyone looking at that URL will know what it means in any context). Further, I expect there may be other non-server uses to expand into (MCP clients? auth-related needed? security-related notices? Although we could squeeze it all in one mcp.json-esque file in theory, it's probably cleaner to separate out those concerns and just reserve a directory)
3. One point to address is how a domain can declare several MCP servers. e.g. do we need this to be /.well-known/mcp/servers.json, where servers.json is an array of server.json object? Maybe both servers.json and server.json are valid?
4. Small detail, but I think we should require that the MCP endpoint be aligned with the domain where the .well-known file is hosted. This way we don't have the possibility of many different domains all trying to provide the reference data for a single server.

Thank you for taking this on! Very much needed.

Edit: As a follow-on to point 2, the registry working group is about to propose another .well-known endpoint for the purpose of storing HTTP-based domain verification. Something like /.well-known/mcp/domain-verify. More reason to use the subdirectory approach. cc @toby

Please change the label from SEP-requested to SEP once a SEP is available.

(Why was it closed?)

Hi! Sorry, I just don't have the bandwidth to navigate the convo and align on format and next steps here, but I suspect this is still very much needed. If no one else can pick this up then I can try to find time to reopen