fix: forward _meta to MCP tool calls and fix model_dump alias seriali…

[mananpatel320]

Description

MCPClient doesn't forward the _meta field to ClientSession.call_tool(), so custom metadata per the MCP
spec never reaches the
server. Separately, the OpenTelemetry instrumentation in mcp_instrumentation.py uses model_dump()
instead of model_dump(by_alias=True), which serializes the Pydantic field as "meta" (Python name)
rather than "_meta" (wire name). This causes setdefault("_meta", {}) to create a new empty dict instead
of reusing the existing one, corrupting the outgoing payload.

This PR adds a meta parameter to call_tool_sync, call_tool_async, and _create_call_tool_coroutine that
gets forwarded to ClientSession.call_tool(meta=...), and fixes the instrumentation to use
model_dump(by_alias=True).

Resolves: #1916

Public API Changes

call_tool_sync and call_tool_async now accept an optional meta keyword argument:

python

Before: no way to pass _meta

result = mcp_client.call_tool_sync(
tool_use_id="id", name="my_tool", arguments={"key": "value"}
)

After: meta forwarded to the MCP server

result = mcp_client.call_tool_sync(
tool_use_id="id", name="my_tool", arguments={"key": "value"},
meta={"com.example/request_id": "abc-123"}
)

The meta parameter defaults to None, so this is fully backward compatible.

Related Issues

#1916

Type of Change

Bug fix

Testing

• Updated existing unit test assertions to match the new meta=None kwarg in call_tool calls

• Updated mock model_dump signatures to accept by_alias kwarg

• Added unit tests for meta forwarding in both sync and async paths

• Added unit test verifying instrumentation preserves existing _meta values

• Added integration tests for call_tool_sync/call_tool_async with meta

• Added integration test verifying instrumentation correctly sets _meta on outgoing requests

• I ran hatch run prepare

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs
  are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published