Support static metadata input for MCP methods (e.g., tools/list, tools/call) to enable enterprise-specific configuration

[sunishsheth2009]

Is your feature request related to a problem? Please describe.
Enterprises operating managed MCP servers often need a way to customize server behavior based on static, client-provided context. Examples include filtering criteria for the tools/list method or inference parameters such as topK and topP for tools/call. These values are not tool arguments and should not be dynamically inferred by the LLM. Currently, the MCP spec provides no standard mechanism to support this kind of static configuration, limiting the ability of clients to influence server behavior in a structured and scalable way.

Describe the solution you'd like
We propose extending the MCP spec to support static metadata that clients can pass when invoking methods like tools/list and tools/call. This metadata would be user-defined and persistent—especially important in enterprise-managed environments where server behavior may need to be tailored for different users or teams.
This capability could be implemented in one or both of the following ways:

• Option 1 [Recommended]: Support structured queryParams in method URLs to carry static configuration metadata.

• Option 2: Extend the MCP client spec to allow defining static configuration when setting up an MCP server. Client applications (e.g., Claude Desktop) could then offer UI options for users to input this static metadata, which would automatically be included in relevant method calls.

Describe alternatives you've considered

• Encoding static values as tool arguments: This is problematic because LLMs can override these arguments, and it does not support configuring tools/list, where tool selection must happen before tool invocation.

• Custom out-of-band server configuration: This leads to brittle, proprietary implementations that do not generalize well across clients and MCP-compliant servers.

Additional context
This feature is especially important for enterprise scenarios where MCP servers are centrally managed. It enables consistent, policy-driven behavior (e.g., tool visibility, routing preferences, inference tuning) without modifying client code or relying on prompt engineering. Introducing a standard way to pass static metadata makes the protocol more flexible, maintainable, and interoperable.

[pwwpche]

MCP has support for _meta (https://modelcontextprotocol.io/specification/2025-06-18/basic/index#meta)

Anything that goes beyond what _meta supports?

[sunishsheth2009]

Thank you for the quick reply. Really appreciate it :)
This is super helpful. I think the above should hopefully solve it.
I guess users can pass in arbitrary dictionary in the _meta other than reserved keywords when calling list/tools or call/tools? Is that correct?

[ccreighton-apptio]

Currently, while Request defines the _meta property under params:

export interface Request {
  method: string;
  params?: {
    /**
     * See [General fields: `_meta`](/specification/2025-06-18/basic/index#meta) for notes on `_meta` usage.
     */
    _meta?: {
      /**
       * If specified, the caller is requesting out-of-band progress notifications for this request (as represented by notifications/progress). The value of this parameter is an opaque token that will be attached to any subsequent notifications. The receiver is not obligated to provide these notifications.
       */
      progressToken?: ProgressToken;
      [key: string]: unknown;
    };
    [key: string]: unknown;
  };
}

A PaginatedRequest will redefine the params property and overwrite the definition from Request:

export interface PaginatedRequest extends Request {
  params?: {
    /**
     * An opaque token representing the current pagination position.
     * If provided, the server should return results starting after this cursor.
     */
    cursor?: Cursor;
  };
}

As a result, ListToolsRequest does not contain params._meta in either the TypeScript or JSON Schema definitions. This prevents clients from passing metadata on a tools/list request in the manner described & prevents servers from utilizing metadata in determining the appropriate tools to list.

I've opened #1520 as a proposed approach towards ensuring that _meta is not erased on requests that also define params.