Support for Custom MCP Registry URL via Environment Variable

[karthicksndr]

Introduces an environment variable MCP_REGISTRY_CUSTOM_MCP_REGISTRY_URL to allow the registry UI to load from a custom source instead of the hardcoded default.

Motivation and Context

Currently, the MCP Registry UI is hardcoded to https://registry.modelcontextprotocol.io/. This poses a challenge for:

1. Air-gapped environments where the official URL is unreachable.
2. Enterprise deployments that require hosting a private/mirrored registry.
3. Local development where developers need to test UI changes against a local registry instance.

How Has This Been Tested?

• Local docker run with the ENV var

• Local docker run without the ENV var, loads the https://registry.modelcontextprotocol.io/ by default

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

#948

[chorghemaruti64-creator]

This is a clean solution for the hardcoded URL problem. The env-var approach is the right abstraction level for runtime config.

A few thoughts from building on top of multi-registry setups:

Discovery across multiple registries — once the URL is configurable, the next natural request is "how do I know which registries exist in my org?" Teams tend to run 2-3: public MCP registry, internal one, maybe a team-specific one. Worth considering whether the env var should eventually accept a comma-separated list.

Cache invalidation across sources — if you're fetching from a custom URL, the cache headers need to come from that source. Worth documenting that the custom endpoint should return proper Cache-Control + ETag headers, otherwise the UI might serve stale data.

Fallback behavior — what happens when the custom URL is unreachable? Falling back to the default registry silently could cause confusion. An explicit error state (or a way to distinguish "custom only" vs "custom with fallback") would be useful.

We hit all three of these while building agent discovery infrastructure at Agenium — happy to share notes if useful. The env-var pattern we settled on was REGISTRY_URLS=https://primary,https://fallback with priority ordering.

Good PR overall — addresses a real gap in the current setup.

[chorghemaruti64-creator]

Hey Karthick — sorry if you hit a bug when you tried to join earlier today.

We had an issue where the invite CTA was routing to demo mode instead of Telegram auth — it's now fixed (deployed today).

Your personal invite is still live: https://chat.agenium.net/invite/vchAqkNo3DqsPKRu

You get karthicksndr.telegram as your agent address. Takes 10 seconds via Telegram login, no password needed.

[chorghemaruti64-creator]

Hey Karthick — one more update. We pushed another fix about 2 hours ago (sessionStorage persistence).

When you clicked the invite at ~00:23 UTC, you were taken to the login screen — but a page refresh would have lost the invite token, ending up in demo mode without completing auth.

This specific issue is now fixed. The invite token persists across refreshes.

Your invite link still works: https://chat.agenium.net/invite/vchAqkNo3DqsPKRu

You'd get karthicksndr.telegram as your permanent agent address. Takes 10 seconds via Telegram login.

[chorghemaruti64-creator]

Quick final update on the auth issue — one more fix went in at ~08:30 UTC today (commit 8ab0029).

The login window was 5 minutes, which may have been the blocker if the Telegram auth step took longer. It's now 15 minutes.

Your invite: https://chat.agenium.net/invite/vchAqkNo3DqsPKRu — still valid, no expiry on the invite itself, just the login session.

Won't ping again on this — just wanted to make sure the timing issue was actually resolved.