fix(client): omit empty _meta on outbound requests

[kokhlo]

Description

Fixes #3473.

JSONRPCDispatcher.send_raw_request attached _meta to params unconditionally, so with no progress callback and a no-op tracer every outbound request carried _meta: {} on the wire. Strict JSON-RPC servers reject that as invalid params — Meta's hosted Ads MCP server (https://mcp.facebook.com/ads) answers -32602 "_meta for Request must be a dict or null" with HTTP 400 on initialize, making it unreachable from any client built on this SDK (_meta: null is rejected identically; the field must be absent).

Reported downstream from Hermes Agent: NousResearch/hermes-agent#105637 (includes a curl repro against the real server: 400 with _meta:{}}, 200 without).

Changes

• src/mcp/shared/jsonrpc_dispatcher.py: _meta is attached only when non-empty after inject_trace_context (so a real trace context still goes out per SEP-414); a caller-supplied empty _meta is dropped rather than forwarded. out_meta was already built before the otel span, so this only moves the wire decision to where its content is final.
• tests/shared/test_jsonrpc_dispatcher.py: the pinned behaviour test now asserts omission when _meta would be empty (both no-key and caller-supplied-empty cases), and still asserts preservation of caller keys + progress token.

This intentionally changes the behaviour pinned by test_send_raw_request_always_carries_meta_on_the_wire — the spec makes _meta optional, and an always-present empty object is rejected by real servers.

Tests

tests/shared/test_jsonrpc_dispatcher.py ... 79 passed
tests/shared/ + tests/client/test_client.py . 974 passed

Motivation

Any strict MCP server that rejects an empty _meta object is currently unreachable natively. Meta's hosted Ads MCP server is the first confirmed case.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3473.

If a maintainer assigns you to #3473, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.