Test Failure Analysis

Summary: A pre-existing flaky test unrelated to this PR's changes (docs-only) failed on Python 3.10/ubuntu-latest due to non-deterministic timing and protocol overhead assumptions in the rate limiting integration test.

Root Cause: test_rate_limiting_blocks_rapid_requests (tests/server/middleware/test_rate_limiting.py:307) has two sources of flakiness:

1. Token refill timing: The middleware is created with max_requests_per_second=10.0 — that's 1 new token every 100ms. On a slower system, elapsed time between requests can cause token refill mid-test, allowing more requests to succeed than expected.

2. Uncertain overhead request count: The test assumes exactly 3 MCP protocol requests flow through the middleware during Client initialization (e.g. initialize + notifications/initialized + tools/list). If only 2 overhead requests are intercepted (e.g. initialize + tools/list), then with burst_capacity=6, the 4th call_tool becomes the 6th request and consumes the last available token — succeeding instead of failing.

On this particular run, Python 3.10/ubuntu-latest took long enough between requests that the token bucket partially refilled, and/or only 2 overhead requests were counted, leaving the 4th call_tool with a token still available.

Suggested Solution: Two changes to tests/server/middleware/test_rate_limiting.py:

1. Drastically lower max_requests_per_second (e.g. 0.001) so token refill is negligible regardless of test duration.
2. Reduce burst_capacity by 1 to add a safety margin against overhead request count variance — or restructure the test to only require it to fail after fewer call_tool attempts so the exact overhead count doesn't matter.

Example hardened version of the test:

async def test_rate_limiting_blocks_rapid_requests(self, rate_limit_server):
    """Test that rate limiting blocks rapid successive requests."""
    # Use a near-zero refill rate so timing doesn't affect token count
    rate_limit_server.add_middleware(
        RateLimitingMiddleware(max_requests_per_second=0.001, burst_capacity=5)
    )

    async with Client(rate_limit_server) as client:
        # After init overhead (2-3 requests), at most 2-3 call_tools can succeed
        await client.call_tool("quick_action", {"message": "1"})
        await client.call_tool("quick_action", {"message": "2"})

        # Next should be rate limited (5 tokens exhausted by overhead + 2 calls)
        with pytest.raises(ToolError, match="Rate limit exceeded"):
            await client.call_tool("quick_action", {"message": "3"})

This is a pre-existing test flakiness issue — the PR's changes (animated banner assets and MDX) have no bearing on the failure.

FAILED tests/server/middleware/test_rate_limiting.py::TestRateLimitingMiddlewareIntegration::test_rate_limiting_blocks_rapid_requests

    async def test_rate_limiting_blocks_rapid_requests(self, rate_limit_server):
        ...
        rate_limit_server.add_middleware(
            RateLimitingMiddleware(max_requests_per_second=10.0, burst_capacity=6)
        )

        async with Client(rate_limit_server) as client:
            await client.call_tool("quick_action", {"message": "1"})
            await client.call_tool("quick_action", {"message": "2"})
            await client.call_tool("quick_action", {"message": "3"})

>           with pytest.raises(ToolError, match="Rate limit exceeded"):
E           Failed: DID NOT RAISE <class 'fastmcp.exceptions.ToolError'>

tests/server/middleware/test_rate_limiting.py:322: Failed