Support an array of commands (multiple commands) to start an MCP server instead of just one

Is your feature request related to a problem? Please describe.

For some ecosystems, multiple commands are needed to install/update and then run an MCP server. For example, before the upcoming .NET 10 release, it is not possible to run a .NET tool in a single-shot manner.

We are working on dnx analogous to npx but the requirement for single-shot essentially forced us to add a dnx experience. This is probably a net good but I am thinking about other ecosystems or complex MCP setups that would need multiple commands to get running.

Describe the solution you'd like

The current schema is pretty specific, not allowing the main command to be set explicitly, except via the runtime_hint (AFAIK).

What this means is private MCP registries adhering to the same protocol don't have a spot to put their language-specific runner.

Current:
https://github.com/modelcontextprotocol/registry/blob/6b22cf09b376ed94c772c69951a2d125e495b26b/docs/openapi.yaml#L182-L200

The OpenAPI YAML could express an array of commands instead of just one. A new command_name optional property be added (instead of implied by the registry type).

For .NET (before dnx exists), the multiple commands to launch a .NET MCP server would be:

dotnet tool install --global ErikEJ.DacFX.TSQLAnalyzer.Cli --version 1.0.25
tsqlanalyze -mcp

This is not to say the main, public MCP registry will not validate or restrict what commands could be run, but it does allow more flexibility for newer language ecosystems or private deployments of an MCP registry.

Multiple commands unlock these kinds of scenarios, generally:

• Interactive auth for the first command, starting the MCP server as the second
• Install, then run (like pre .NET 10).
• configure a private package source first (npm config set registry), then npx

Said another way, this removes the single-shot requirement for a language/runtime ecosystem to onboard to MCP server hosting.

Describe alternatives you've considered

• Run the setup steps out of band (manually). This is a burden on the end user and makes an single click "install" experience not possible.
• Supporting shell scripting as the entry point (which can internally do multiple commands)
  • This feels to flexible and hidden -- where to host the shell script?
  • It is likely OS specific

Additional context
I have opened a similar issue on VS Code (https://github.com/microsoft/vscode/issues/249370) but I now understand this is a more broad discussion than just VS Code. Thanks @connor4312 for chatting with me a bit already.

Start with docs/openapi.yaml around lines 182-200, which defines the current server command schema, and review the linked VS Code issue for related context. Trace how the schema represents commands and registry types before assessing the proposed array and optional command_name. Done means the API contract clearly supports the intended multi-command scenarios without leaving validation or compatibility unspecified.