The MCP specification defines _meta as a valid field on every request, including initialize, via the RequestParams base type:
// schema.ts (2025-11-25)
interface RequestParams {
_meta?: {
progressToken?: ProgressToken;
[key: string]: unknown;
};
}
interface InitializeRequestParams extends RequestParams {
protocolVersion: string;
capabilities: ClientCapabilities;
clientInfo: Implementation;
}
McpSchema.InitializeRequest in the Java SDK correctly models this (the _meta field was added in #344). However, McpSyncClient#initialize() / LifecycleInitializer#doInitialize always constructs the request with the 3-arg convenience constructor, hardwiring _meta to null. There is no API to populate it.
Impact
Servers that rely on _meta of the initialize request will always receive null metadata when called from a Java client, even though the spec explicitly allows it. This is inconsistent with tools/call, where CallToolRequest._meta is fully caller-controlled.
Workaround (current)
The only workaround is to wrap the McpClientTransport and intercept the outgoing initialize JSONRPCRequest in sendMessage, rebuilding it with _meta populated. This works but couples application code to internal wire-format details (JSONRPCRequest, InitializeRequest record structure) that should be opaque to callers.
Proposed solution
Expose _meta on the McpClient builder, consistent with the pattern used in PR #906 for paginated list methods:
// Option A — builder-level (static meta per client lifetime)
McpClient.sync(transport)
.initializeMeta(Map.of("server_id", "…", "invocation_id", "…"))
.build();
// Option B — overloaded initialize() (dynamic meta per call)
client.initialize(Map<String, Object> meta);
Related
The MCP specification defines
_metaas a valid field on every request, includinginitialize, via theRequestParamsbase type:McpSchema.InitializeRequestin the Java SDK correctly models this (the_metafield was added in #344). However,McpSyncClient#initialize()/LifecycleInitializer#doInitializealways constructs the request with the 3-arg convenience constructor, hardwiring_metatonull. There is no API to populate it.Impact
Servers that rely on
_metaof theinitializerequest will always receivenullmetadata when called from a Java client, even though the spec explicitly allows it. This is inconsistent withtools/call, whereCallToolRequest._metais fully caller-controlled.Workaround (current)
The only workaround is to wrap the
McpClientTransportand intercept the outgoinginitializeJSONRPCRequestinsendMessage, rebuilding it with_metapopulated. This works but couples application code to internal wire-format details (JSONRPCRequest,InitializeRequestrecord structure) that should be opaque to callers.Proposed solution
Expose
_metaon theMcpClientbuilder, consistent with the pattern used in PR #906 for paginated list methods:Related
_metafield toMcpSchemaclasses (schema layer, no client API)_metato paginated list client methods (listTools, etc.)_meta