Failing test (tests/server/middleware/test_rate_limiting.py:381):
```python
async def test_rate_limiting_with_different_operations(self, rate_limit_server):
rate_limit_server.add_middleware(
RateLimitingMiddleware(max_requests_per_second=9.0, burst_capacity=5)
)
async with Client(rate_limit_server) as client:
await client.call_tool("quick_action", {"message": "test"})
await client.call_tool("heavy_computation")
# Should be rate limited regardless of operation type
with pytest.raises(ToolError, match="Rate limit exceeded"): # <-- DID NOT RAISE
await client.call_tool("batch_process", {"items": ["a", "b", "c"]})
```

Log excerpt:
```
FAILED tests/server/middleware/test_rate_limiting.py::TestRateLimitingMiddlewareIntegration::test_rate_limiting_with_different_operations

• Failed: DID NOT RAISE <class 'fastmcp.exceptions.ToolError'>
  = 1 failed, 4379 passed, 1 skipped, 1 xfailed, 6 warnings in 104.53s (0:01:44) =
  ```

Token bucket logic (src/fastmcp/server/middleware/rate_limiting.py:38):
```python
async def consume(self, tokens: int = 1) -> bool:
async with self._lock:
now = time.time()
elapsed = now - self.last_refill
# Add tokens based on elapsed time
self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
...
```

With refill_rate=9.0, just ~0.11 seconds between requests restores 1 token. A comparable test (test_sliding_window_rate_limiting) comments: # 1 init + 1 list_tools + 3 calls + 1 to fail for max_requests=6, suggesting 5 requests are expected before the failing one. But the rate-limited version uses burst_capacity=5 with only 2 explicit calls, leaving the 3rd with 1 token remaining on Python 3.13.

Only fails on: Python 3.13 / ubuntu-latest
Passes on: Python 3.10 / ubuntu-latest, Python 3.10 / windows-latest

• tests/server/middleware/test_rate_limiting.py — contains the flaky test; lines 381–394 are the failing test case
• src/fastmcp/server/middleware/rate_limiting.py — TokenBucketRateLimiter.consume() at line 38 performs time-based refill that makes the test timing-sensitive