Repository navigation
Allow for vendor extensions to registry API #81
Description
Activity
Will this be only for metadata that consumers generate during ETL? Or will this also be for metadata that server authors add to target particular aggregators and clients?
It's a good clarifying question.. I saw it as the former. And I think @toby and @sridharavinash's proposal is aligned with that:
"x-github": { "stargazer_count": 2723, "uses_custom_opengraph_image": false, "is_in_organization": true, "pushed_at": "2025-06-09T14:36:59Z", "opengraph_image_url": "https://opengraph.githubassets.com/2bfc402f087cd45c5fdc74b09bb25c9d6919fb51817d53220c1dd42395ce1d29/21st-dev/magic-mcp", "primary_language": "TypeScript", "name": "magic-mcp", "name_with_owner": "21st-dev/magic-mcp", "owner_avatar_url": "https://avatars.githubusercontent.com/u/199367026?v=4" }
The latter idea is interesting, but I would propose we leave it out of scope until we at least see what kind of
x-*data starts getting put into place by registries (or someone comes in with a very compelling use case that'd be useful immediately).Edit: Also adding my comment from Discord here:
It seems to me like using x-* is something you can decide to do without the official Registry getting involved or having a meaningful opinion. I don't think there's any particular need to namespace with domain names either -- whatever you choose is going to be localized to your registry mirror (and its consumers) and does not have to be globally unique across the whole MCP ecosystem
Reacted by Toby Padilla and Avinash SridharYes, I think using the
x-prefix is a good way to go, it's natively supported in OpenAPI as well. @dsp-ant had a good idea of using the domain as a prefix, so combining the two ideas intox-github.comseems reasonable and a way to avoid collisions.I would propose we leave it out of scope until we at least see what kind of
x-*data starts getting put into place by registries (or someone comes in with a very compelling use case that'd be useful immediately).Sounds good. For the ETL case, I agree
x-*makes sense. (And actually, I think it is good to split the cases —x-*for ETL andvendorfor user-specified.)combining the two ideas into x-github.com seems reasonable and a way to avoid collisions.
How would a collision actually manifest / is that a real concern in this context? Presumably,
x-githubwould only exist on the GitHub mirror of the official registry. So GitHub would be in control of whether it wants to add some other details (though it's hard to imagine expanding justx-github), and would be very much in control of naming to avoid collisions, without a need for a verbose DNS-based name.(nothing stopping you from using
x-github.comanyway of course, just wondering if I am missing something)How would a collision actually manifest / is that a real concern in this context?
Collisions are probably not a huge risk, but I do think there will be composition of registries. We may have downstream registries that want the GitHub star info for instance. It's probably more of a good hygiene issue than something super pressing.
It could also potentially be the start of hosting the schema for the extensions at a well known location on that domain.
There is some precedence to this on Azure side and use in generation of SDKs https://github.com/Azure/autorest/blob/main/docs/extensions/readme.md
Also started using this convention for Azure API Center that implements the MCP registry spec. https://github.com/Azure/APICenter-Portal-Starter/blob/mcp-registry-hack/mcp-registry/servers.json
Reacted by Toby Padilla and Daniele MartinoliEDIT: I think this is really targeting #201
Plausible that this is worse, but maybe something like a general 'annotations' map? Then people can reuse the same ones across registries and be more likely to coalesce on similar things.
For example it will be a pain if there's a
x-github.comwith its own shape, which has aniconin it. And then anx-anthropic.comwith iconUrl andx-google.comwith logoUri. If there was a generaliconUrlor evencom.github.iconUrlannotation then other providers could maybe depend on it more? (especially if there was aio.modelcontextprotocol.experimental.iconUrlthat we could move things over to as the ecosystem developed).Inspired by: https://github.com/open-telemetry/semantic-conventions/tree/main
(Appreciate this is fairly similar to the above, but something to me is different between objects under their own namespaces <> flat annotations that the convention is to use your reverse-ordered DNS)
Reacted by Radoslav DimitrovAssigning to @rdimitrov as per conversation on Discord (but GitHub UI doesn't seem to allow me to do this, hence noting this as a comment)
As per #39, official registry consumers will have long tail needs for other kinds of data with which they want to enrich their mirrors of the registry, while maintaining compatibility with the official registry API schema.
Quoting myself:
And @jonathanhefner had the good point:
This issue is for tracking:
Some ideas for how this might be used: