modelcontextprotocol / modelcontextprotocol/registry

Add some sort of contact_email field to server.json

Open
#480 10 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

product requirements work v1
Dominant language
Go
Stars
7.3k
Forks
994
Avg merge
4d 12h
Merged PRs (30d)
19

Description

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:

  1. Notify the MCP Registry userbase of major changes/announcements. For example breaking changes or database wipes, especially while in Preview.
  2. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the server.json schema and the issue's proposed contact-email use cases. Clarify whether the field should be encouraged or required, which publisher notifications it supports, and what validation or takedown behavior would count as complete.

Written by the indexing model from the issue text.

Assessment

Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.