Support multiple mcp servers coming from same repo

[weshaggard]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

For a number of reasons (consistency, lower maintenance, shared development and testing) we plan to develop multiple mcp servers in one repo (https://github.com/microsoft/mcp) repo. However, as it stands today my understanding is that the registry requires a 1:1 mapping between server and github repo which would block us from registering multiple mcp servers from one repo.

Without this support we would be forced to artificially create another repo for each mcp server we want to register and that repo would essentially be empty and point back to our main repo.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[KalleBylin]

Yeah, seems like this is an existing pattern with others also organizing servers in a monorepo. For example, AWS maintains many MCP servers in awslabs/mcp.

While repository.url seems to be used for provenance and must point to the repo root (e.g., current validation rules enforce the https://github.com/user/repo type of format), I haven't seen any uniqueness constraints. A quick check in seed.json also showed at least https://github.com/mendableai/firecrawl-mcp-server being used twice.

In that sense, I would be inclined to think that there is not necessarily a 1:1 server-to-repo requirement and installation details could come come from packages (or remotes). This makes it possible to publish one installable artifact per server (npm/PyPI/NuGet/OCI or a direct .mcpb release URL), even if they live in the same repo.

Would that be a viable solution to this?

[tadasant]

While repository.url seems to be used for provenance and must point to the repo root (e.g., current validation rules enforce the https://github.com/user/repo type of format)

Actually good catch on this - this is not the intent of the spec. We should allow any subfolders there.

OR, we introduce a separate subfolder field or similar. I don't have a strong opinion yet on which way we go, but we should do one or the other. Happy for someone to open an Issue and flesh out a proposal for going one way or the other.

[KalleBylin]

Opened issue #360 to cover this in more detail 👌🏼

[tadasant]

I agree this is a common pattern that we must support, but @weshaggard could you clarify what about our schemas suggests this is not supported?

repository is an optional field, and if you choose to use it, the repository.url field can point all the way to any subfolder. Happy to accept PRs if you see contrary information / implications anywhere in the docs or code.

Perhaps it is confusing in that a subfolder URL would suggest it is not a "repository's URL" exactly. I'd be open to a suggestion to split the field into something like url and subfolder, but I'm not sure it's definitely necessary.

[weshaggard]

The information I got was from @toby who we are working with to register our mcp servers. I've not dug deep into the spec so perhaps this is just a registry implementation issue as opposed to a spec issue. I will have to defer to @toby to help answer that question.

[toby]

@tadasant indeed, I'd love to see that split with url and subfolder as I didn't even know that was supported :D When I think repo, I think top level where the .git folder lives.

[KalleBylin]

I agree with this approach, created issue #360 to flesh out the proposal