MCP Registry question

[kbsquared]

Is it the intention that context forge would be able to function as an MCP Registry in the context of being able to plug it into GitHub to restrict co-pilot usage to the list that's in the registry?

See this documentation for additional information: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-registry#endpoint-and-specification-requirements

[gcgoncalves]

Hi, @kbsquared! The virtual servers exposed by Context Forge have a different standard, as it aggregates all MCP tools configured under it in a single endpoint (/{uuid}/mcp), rather than listing multiple MCP servers. This registry pattern is interesting for a future release, though.

[crivetimihai]

Hi @kbsquared, thanks for the question. @gcgoncalves is right — ContextForge doesn't currently implement the MCP Registry specification that GitHub Copilot expects for registry-based server management.

ContextForge operates as an MCP gateway/proxy that aggregates multiple upstream MCP servers into virtual servers, each exposed as a single endpoint (/servers/{id}/mcp). The GitHub registry spec expects a different pattern — a catalog listing multiple MCP server endpoints that Copilot can individually connect to.

We do have an internal MCP Registry catalog (Admin UI → MCP Registry tab) for discovering and registering pre-configured MCP servers from a curated catalog, but this is an admin-facing feature, not the external-facing registry endpoint that GitHub's spec requires.

What you can do today: Point Copilot directly at a ContextForge virtual server URL as an individual MCP server. Copilot will see all tools aggregated under that virtual server. This gives you centralized governance (auth, rate-limiting, RBAC) without the registry discovery pattern.

Roadmap: Implementing a GitHub-compatible MCP Registry catalog endpoint is something we're considering for a future release. If this is a priority for your use case, please open a feature request so we can gauge demand.