fix(mcp): handle integer progressToken in host progress capture

[pdecat]

Relevant issues

Fixes #30976

Type

🐛 Bug Fix

Changes

Per the MCP spec, progressToken is string | integer (schema.json#L2302-L2308, represented as str | int in the Python SDK).

The host-progress-capture block in litellm/proxy/_experimental/mcp_server/server.py logged the token with f"...{host_token[:8]}...". The [:8] slice assumes a string, so an integer token raises TypeError: 'int' object is not subscriptable. That exception was swallowed by the surrounding try/except and surfaced as a misleading Could not capture host progress context warning on every tool call from a client using an integer progress token.

The f-string is built eagerly regardless of log level, so it fired even with debug logging off. host_progress_callback is assigned before the failing log line, so progress forwarding still worked — this was log noise only, no functional impact.

This wraps the token in str() before slicing so both string and integer tokens format safely, and adds a regression test that drives a tool call with an integer progressToken and asserts the warning is not emitted.

Proof of Fix

The regression test reproduces the exact warning before the fix:

AssertionError: integer progressToken should be handled gracefully, got warning(s):
[call("Could not capture host progress context: 'int' object is not subscriptable")]

and passes after the fix:

tests/.../test_mcp_server.py::test_mcp_server_tool_call_handles_integer_progress_token PASSED

[greptile-apps]

Greptile Summary

This PR fixes a TypeError in the MCP server's host-progress-capture block where slicing an integer progressToken with [:8] raised 'int' object is not subscriptable. The exception was swallowed by a surrounding try/except, producing a misleading "Could not capture host progress context" warning on every tool call from clients using an integer token, while progress forwarding itself still worked correctly.

• server.py: Wraps host_token in str() before the [:8] slice so both str and int tokens format without error, matching the MCP spec (ProgressToken = str | int).
• test_mcp_server.py: Adds a regression test that drives mcp_server_tool_call with an integer progressToken (via SimpleNamespace) and asserts the warning is not emitted; fully mock-based with no real network calls.

Confidence Score: 5/5

Safe to merge — the change is a single-character addition that eliminates log noise with no functional side effects.

The fix is a minimal, targeted change to a debug log statement. Progress forwarding was already working correctly before the PR; only the log line was broken. The regression test is well-scoped, mock-only, and directly reproduces the failure condition. No existing tests are modified or weakened.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/proxy/_experimental/mcp_server/server.py	One-line fix: wraps host_token in str() before slicing to handle integer progressToken values per MCP spec
tests/test_litellm/proxy/_experimental/mcp_server/test_mcp_server.py	Adds a focused regression test using mocks and SimpleNamespace to verify integer progressToken no longer triggers a spurious warning

_{Reviews (2): Last reviewed commit: "fix(mcp): handle integer progressToken i..." | Re-trigger Greptile}

[codspeed-hq]

Congrats! CodSpeed is installed 🎉

🆕 16 new benchmarks were detected.

You will start to see performance impacts in the reports once the benchmarks are run from your default branch.

Detected benchmarks

• test_cost_per_token_openai: 627.5 µs
• test_get_model_info_with_provider: 79.9 µs
• test_token_counter_long_content: 1.7 ms
• test_get_llm_provider_anthropic: 148 µs
• test_get_model_info_openai: 81.7 µs
• test_cost_per_token_anthropic: 621.4 µs
• test_token_counter_with_tools: 417.2 µs
• test_token_counter_multi_turn: 567.1 µs
• test_get_llm_provider_azure: 147.9 µs
• test_token_counter_simple_message: 234.7 µs
• test_token_counter_raw_text: 184 µs
• test_get_llm_provider_openai: 143.9 µs
• test_get_model_cost_key_exact_match: 80 µs
• test_get_llm_provider_with_prefix: 140.5 µs
• test_get_model_info_anthropic: 80.8 µs
• test_get_model_cost_key_case_insensitive: 82.3 µs

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Sameerlite]

@pdecat please rebase this PR to "litellm_internal_staging"

[pdecat]

@Sameerlite oops, rebase done!

[Sameerlite]

Thanks for the PR! The Greptile review is stale after the rebase — triggering a fresh pass. (The fork CI checks — Block fork dependency changes, Verify PR source branch, osv-scan — are standard fork limitations; no action needed on those.)

@greptileai

[caldito]

This is causing issues in different MCP clients after upgrading to from v1.88.0 to v1.92.0.

Can we merge with priority and include in the next release please? @tin-berri @Sameerlite

[pdecat]

Rebasing to fix conflicts...

[pdecat]

Actually, this is superseded by #32402

[pdecat]

The first stable tag to include the fix from the other PR is v1.93.0 from 2026/07/18.

[caldito]

okay that's great then, thank you