| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
InitializeRequestParams already inherits Meta (_meta) from RequestParams, but McpClientImpl.ConnectAsync built the params without reading from McpClientOptions, so callers had no way to populate it. Add an InitializeMeta property on McpClientOptions and thread it through the handshake. Fixes modelcontextprotocol#1593
|
This is a new feature, but it might be worth backporting @jeffhandley |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #1593.
Problem
InitializeRequestParams inherits Meta ([JsonPropertyName("_meta")]) from RequestParams, in line with the 2025-11-25 schema, but McpClientImpl.ConnectAsync constructs the params without reading from McpClientOptions. So the type supports _meta on initialize while the public client API offers no way to populate it. The current workaround is a custom IClientTransport that writes out-of-band data before the handshake, which couples the mechanism to the transport layer the SDK is meant to abstract.
Fix
Add an InitializeMeta property to McpClientOptions and pass it as Meta when building the InitializeRequestParams. The protocol layer already models the field, so this is options-to-params plumbing only. When InitializeMeta is null, no _meta is sent, so existing behavior is unchanged.
Testing
Added two tests to McpClientMetaTests that use a server-side incoming message filter to capture the initialize request:
dotnet build of ModelContextProtocol.Core is clean (warnings-as-errors). The full McpClientMetaTests class passes (5/5) on net10.0.