Configuration

[calclavia]

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

I would like to propose adding configuration as part of the official MCP spec. Most stdio servers have some CLI arguments or environmental variables, but it's impossible to configure SSE servers within the protocol itself.

Configuration can be designed as a request method to be MCP-compatible. This will be an endpoint that allows SSE servers to be configured with things like API keys, etc.

I have implemented a working draft of this. Example:

The following request performs a method: "config" call to the MCP server. The MCP server can define an arbitrary JSONSchema to tell the client how to make this configuration.
https://github.com/smithery-ai/typescript-sdk/blob/c8c88cd8b89434450afb4c98cfdcc3737aa26c16/src/examples/simple.ts#L40

Here's the request schema:
https://github.com/smithery-ai/typescript-sdk/blob/c8c88cd8b89434450afb4c98cfdcc3737aa26c16/src/config.ts#L28

On Smithery, we've cataloged 100+ configs for spawning stdio MCPs and we find that JSONSchema covers pretty much all configs out there necessary to start a server.

Open to discussing any improvements or modifications!

(This is somewhat related to: #64)

Scope

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

[jspahrsummers]

Thanks for opening this! We have discussed similar ideas in the past, but struggled to identify the concrete use cases for configuration. Knowing those might help clarify whether we need something highly generic, or whether something more specific might do. The roots feature actually emerged out of these discussions, as that felt like a specific reification of configuration that's quite useful.

Do you happen to have examples of the sorts of things that Smithery servers use for configuration?

[calclavia]

Typically servers need to be configured for the following reasons:

• They need API key access to certain services (Exa, Browserbase) https://smithery.ai/server/exa
• They need to point to some local path (File system / Obsidian MCP) https://smithery.ai/server/mcp-obsidian
• They need to specify the name of the database they're connecting to (Postgres/Neon DB related MCPs)

I went through the roots feature but it's unclear how roots will solve the above since it's not just about file roots. Many of these MCPs will not run until they have the configuration, as defined by their CLI args. Having a config protocol will make it so any UI applications can generate dynamic forms (based on JSON Schema of config) to allow non-technical end users to enter these values to configure their servers.

[jspahrsummers]

Roots are specifically designed to resolve the second case you mentioned (pointing to some local path). I agree they don't, and are not meant to, solve the others.

API keys should generally not be provided over the MCP connection—I think it would be best to solve that with a proper auth solution.

Setting a database name seems highly relevant, though! I wonder if this configuration is something that the user might set once (e.g., upon initial install of the MCP server), or if they might want to change it later. The former might suggest it could be encoded into URL structure for HTTP servers, perhaps based on information reported from a well-known URI.

[calclavia]

• For the use cases I've seen for configs, they're usually set once. By encoding into the URL structure, do you mean the /sse endpoint itself should allow get parameters to specify the config? e.g., https://myprocotol.com/sse?param1=config
• My understanding is the OAuth setup helps use cases where you would authenticate via a UI/browser. For applications where you want to exchange things like API keys, or authentication JSONs keys (Google cloud access, for example) during a one-time setup, is OAuth still the best setup?

[jspahrsummers]

By encoding into the URL structure, do you mean the /sse endpoint itself should allow get parameters to specify the config?

Hypothetically, yes. This, or putting information into the path where relevant—e.g., https://myapp.com/postgres/database_name/sse

For applications where you want to exchange things like API keys, or authentication JSONs keys (Google cloud access, for example) during a one-time setup, is OAuth still the best setup?

I generally don't think these things should be provided from the MCP client to a remote MCP server. I'd instead suggest either:

1. The MCP server is deployed with direct access to the secrets it needs. For example, it can read API keys or JSON credentials from a cloud-based secret store. This would be applicable for privately deployed remote MCP servers.
2. The MCP server is deployed with support for OAuth, and it's via OAuth that the user delegates permission to the MCP server to interact with their resources. This would be applicable for remote MCP servers that are "open" or multi-tenant.

Directly submitting credentials seems like a security risk, especially so in a multi-tenant environment (you wouldn't want your GCloud credentials to be stored as a row in a DB next to many others').

[calclavia]

Closing this, since I think OAuth and Well known (#69) should resolve this use case