This changeset addresses issue #1250: after the MCP client refreshes its token and starts using the new one, server‑side tools still receive the old (expired) token from get_access_token().

CI failed on coverage for the new branch in _handle_request. I added a small, low‑level unit test to cover it, but it’s fairly close to internals and I’m not sure this is the preferred approach. If there’s a better way to cover this path, please let me know what you recommend.

Motivation and Context

We've hit the bug and found this matching GitHub issue. I provided test code to reproduce the bug. Eventually I noticed project fastmcp hit the same problem and a patch was committed.

How Has This Been Tested?

• The changes include a regression test. Without the patch, the Framework does not handle refreshed tokens correctly #1250 bug is hit (AssertionError: assert 'token-a' == 'token-b').
• The changes also include a unit-test. Which fails without the patch.
• Verified the test code provided to reproduce the bug, isn't showing tokens with negative validity.
• Ran our OAuth MCP against the patched version and confirm token renewal now works.

Breaking Changes

No.

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

My understanding: The context var is correct inside the ASGI request task where AuthContextMiddleware runs. The problem is that tool execution happens later in a different task. The context var value isn’t visible. StreamableHTTPSessionManager only wraps the request in a ServerMessageMetadata and writes it to a MemoryObjectSendStream. When that message is processed later, unless it's re-set, the context var isn’t the correct one.

The fastmcp fix patches get_access_token() to read the token from the current request (available via request metadata in the tool execution context). Which permits to avoid reading the stale context var. This change instead updates auth_context_var from the current request’s scope["user"] inside _handle_request, so each message sees the latest token in the context var.