Absence of configuration data

[BobDickinson]

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

TLDR;

Many servers in the registry do not provide any kind of configuration information, even though they require configuration (this applies to both packages and remotes). Should we encourage broader participation in specifying configuration? As clients how do we distinguish between "configuration not provided" and "configuration not required".

Details

I have an MCP security product called TeamSpark MCP ToolVault that has a catalog of MCP servers that users can choose from (the catalog is something crude that I rolled myself by scraping the Official servers page and the associated GitHub README files to find sample configs). The catalog is open sourced here: https://github.com/TeamSparkAI/ToolCatalog (though I expect it will go away in favor of a mildly curated version of the official registry).

One area where the official registry is a huge improvement is in the support for metadata-driven configuration - especially versus the "sample-based" configuration I'm using now and most users are used to (seeking out the server config JSON in a registry/repository README and copy-pasting).

With this metadata-driven configuration we have an ideal situation where the user selects a server and we can give them a guided configuration experience using the specified configuration elements and their properties (as if the MCP server implemented it's own custom config UX). This is extremely well designed in the spec and results in a great experience when it is present in the server definition. Chef's kiss. No notes.

The issue we have run into in deploying this in our UX is that only about half of the server packages and remotes in the current registry provide any kind of configuration information. I have spot-checked about two dozen of the servers that do not specify any configuration, and in all cases they actually do require configuration to run properly (these are back to the old "go look at the README in the registry/repo and find a server config JSON to copy/paste").

My initial reaction was that we would just treat the absence of configuration as "no configuration specified" instead of "no configuration required" (our initial naive approach). This is probably fine, except that there might be well-managed entries for servers that actually don't require any config (like the sample "memory" server, or an internal remote that requires no headers). I'd hate to punish a server that actually required no config. I wonder if providing an empty config (arguments/env var/headers) would be the proper way to indicate that those configuration elements are explicitly not required (versus just not provided by the publisher)?

My other observation is that the Publish Your MCP Server doc does not provide guidance about specifying package configuration. I'm not sure how much that guidance would help given that it is provided for the remote headers and those have about the same participation rate. But it couldn't hurt to add it.

I'm new here and didn't want to rush in with an issue or PR without having the full context, so I figured it would be better to post here.

Scope

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

[BobDickinson]

After digging into the currently published data in more detail, I think the issue a little more broad. I'll open a new discussion thread when I have a more data and a constructive solution to offer. Closing this one.