Expose RequestParams._meta in ClientSession.call_tool

[samchenatti]

Motivation and Context

This change allow clients to send metadata through the _meta field as specified by the protocol.

It is important to expose _meta since there might be some metadata required by the server to control how the tool works (such as client preferences, its localization and so on). In some cases we also don't want the Agent/LLM to be aware of such data; it should be known by the MCP Host and Server only; therefore it cannot be exposed as tool usual arguments.

This feature has already been requested by me and another user - so it might benefit another people as well.

I also started a discussion about _meta being exposed by FastMCP Client, but they will wait until its implemented in here.

How Has This Been Tested?

I tested it on my local environment using a self-made MCP Server.

Since _meta is currently being used for progress report tokens, I also ensured this feature doesn't break progress_callback.

I'd be happy to implement the required unit-tests if someone can point the best test-file for it.

Breaking Changes

There are no breaking changes. The python-sdk already considers that _meta can carry data other than progressToken.

Also types.RequestParams.Meta model is already configured to allow extra key-values.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

I decided to expose meta as a plain dict instead of types.RequestParams.Meta since, from my understanding, mcp.types shouldn't be exposed to final users.

Metadata could be exposed by another interfaces as well, such as list_tools, list_prompts and etc. I'm sticking with tool_call for now, but would be happy to replicate it to the other interfaces.

[dsp-ant]

I am okay with this change, but I think we should make the ordering such that it's BC compatbile, and create a follow up for the SDK version 2.0 to reconsider the ordering and force named arguments.