Rich server configuration experience

We should allow a user to find a server via an MCP registry (any registry mirror implementing the official MCP Registry API) or by using a URL that can be used to locate a ServerCard.

Note: The shapes of the MCP Registry server.json and the ServerCard are very similar, and may be converging to a single schema/shape (the ServerCard WG is still finalizing that shape, and the Registry WG will coordinate). We will refer to this generally as the "Server Definition".

Using the Server Definition, we can render rich server information (using metadata like title, icon, etc) as well as custom configuration UX. We would build a form for server configuration not unlike how we use JSON schema to drive dynamic UX for tool input.

We would presumably need to store a reference to the Server Definition (a URL that either points to the registry entry or the ServerCard) in our catalog so that we can access the server metadata for display, and so that if the user goes to edit the server configuration we can use the server definition to regenerate the config UX (like we did on initial install/configuration).

For servers installed from a registry or ServerCard this will provide a much richer experience (branded MCP server UX and custom config UX that will guide configuration and ensure validity).

In terms of discovery:

For the registry case, the user would configure a registry URL and we would provide a registry browser/search experience, where they could pick a server and add/configure it. Here is repo that implements this functionality (happy to donate anything from there that is useful): https://github.com/TeamSparkAI/mcp-registry

For the ServerCard case, when the user adds a new server by URL, we will attempt to locate a ServerCard at that location (via .well-known semantics), and if found, switch to the rich server add mode.

Issues:

It may or may not make sense to store the server.json/ServerCard in the Inspector catalog instead of just storing a reference to it if we are worried about performance (tracking down the remote JSON every time we need the icon/title, for example), or if we are worried about the reachability/durability of the remote JSON blob.

Start by reviewing the MCP Registry API, ServerCard/.well-known discovery flow, and the existing Inspector catalog and server-add experience. Compare the donated mcp-registry implementation for relevant entry points. Done means registry or ServerCard discovery can drive rich metadata and configuration, with a durable catalog reference and editable configuration behavior.