modelcontextprotocol
Add some sort of contact_email field to server.json
I think it would be helpful to encourage (or require?) publishers to include a contact email when publishing a server.
This would empower at least a few downstream functionalities for us:
- Notify the MCP Registry userbase of major changes/announcements. For example breaking changes or database wipes, especially while in Preview.
- Automated checks that ensure server.json data is valid / working, and automatic takedown (with notification) in the case that something is nonworking
In particular I expect (2) is going to quickly become a problem, whether intentionally or unintentionally I expect many server.json's to have typos and other bugs. And if MCP Clients can't rely on us to serve working data, they won't use us as a source of truth. I'm not sure yet if it's necessary to solve this at the centralized layer (maybe sub-registries could handle it), but having email addresses for notifications would at least make this conceivable to manage. Otherwise we would be modifying/taking down server entries with no feedback loop back to the publishers.
@tadasant @rdimitrov @domdomegg After looking at users being unclear on why the mcp-publisher is not working as expected after the release of breaking changes, I think this issue will help a lot in notifying them.
If the requirements are clear then can I pick this issue? Happy to discuss this further if we have to come to conclusion on point 2 specially.
Would that affect how the data is stored since I’m assuming it would now be considered PII?
I am not completely sure on this point, possible related to the policies registry is adhering to when it comes to storing sensitive information. May be others can help with this answer.
I would be slightly concerned with holding more PII. We do already store some PII (e.g. GitHub usernames, domains) but email does feel much more abusable (I'd be worried for example about having an email publicly on the registry). We could maybe make this hidden somehow, although that introduces its own challenges (e.g. who has access and how).
Fair point in that this just becomes a giant email spam surface if we publish it publicly, regardless of whether folks are thoughtful about e.g personal vs [email protected] type emails.
I like this thought:
We could maybe make this hidden somehow, although that introduces its own challenges (e.g. who has access and how).
... but acquiring that information is tricky as it wouldn't be as simple as including it as a field in server.json. Need more thinking here before actioning, but I maintain it's fairly critical for us to figure this out.
@tadasant May be completely out of the blue solution but what do you think about sending these updates on a webhook?
Hmm webhook feels like too big of an ask of most publishers (to set up an always-on service that accepts notifications from us and forwards it to something more reasonable like an email inbox).
Maybe we just accept this in the CLI publication flow (required for new servers) and store it in the database without exposing it to anyone publicly? Manage it similarly to the way we're handling status (status ends up exposed publicly, but we don't need to do the same for email).
@tadasant I was thinking github webhook. From that webhook user can redirect wherever they want to, can control all actions from that.
If we want to go ahead with email then we have to also allow update, delete of this user property. What about verification of email?
I think publishing the email address in the registry is problematic for a bunch of reasons (PII, likelihood of abuse). But at least having the registry maintainers be able to contact the publisher seems useful.
I have a situation now where I have identified a bunch of servers that fail schema validation or have invalid configs (128 of these are from the same publisher). It would be great to have a mechanism to reach out to the publisher to resolve the issue (even if that involved going through an intermediary).
