Allow for templated variable cascading scenarios across packages and remotes
Follow on to https://github.com/modelcontextprotocol/registry/pull/570
See https://github.com/modelcontextprotocol/registry/pull/570#issuecomment-3367417636 for the starting point
My rough understanding of what we want to accomplish here is to, at minimum:
- Collect nested variables in the validators so that parametrized schemas like this are allowed:
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-16/server.schema.json",
"name": "io.github.SamYuan1990/i18n-agent-action",
"description": "An i18n github action for language translate",
"version": "mcp",
"packages": [
{
"registryType": "oci",
"registryBaseUrl": "https://ghcr.io",
"identifier": "SamYuan1990/i18n-agent-action",
"version": "mcp",
"runtimeHint": "docker",
"transport": {
"type": "sse",
"url": "https://example.com:{host_port}/sse"
},
"runtimeArguments": [
{
"description": "Port mapping from host to container",
"value": "{host_port}:8080",
"type": "named",
"name": "-p",
"variables": {
"host_port": {
"description": "The host (local) port",
"isRequired": true,
"format": "number",
"default": "8080"
}
}
}
]
}
]
}
- Properly document the scenarios where these template variables cascade (and what to do in case of conflicts / which layers have precedence).
(2) Might potentially deserve an extension to syntax to do things like {-p.host_port} or {p.host_port} in order to disambiguate more explicitly. But my inclination is to not add the extra syntax (just do blind {host_port} with some precedence order of where to look), as this won't be a commonly used feature and some reasonable precedence cascade would be sufficiently intuitive that users don't have to learn the syntax and can just intuit how variables would cascade.