Use pip instead of uv pip in upgrade instructions

[jlowin]

Follow-up to #2839. The upgrade message was using uv pip install which assumes users are using uv. Changed to just pip install for tool-agnostic guidance that works for all users.

[coderabbitai]

Warning

Rate limit exceeded

@jlowin has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 12 minutes and 28 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 7628c43 and 0b41058.

📒 Files selected for processing (2)

• src/fastmcp/cli/cli.py
• src/fastmcp/utilities/cli.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[marvin-context-protocol]

Test Failure Analysis

Summary: The test test_tool_execution_parameter_mapping is failing due to a DNS timeout when attempting to connect to https://api.example.com, a non-existent domain used in the test.

Root Cause: The test was introduced in commit 8e1fd1d (#2835) and is experiencing intermittent failures. The test intentionally uses a non-existent URL (https://api.example.com) and expects the HTTP request to fail quickly. However, on Python 3.10 on ubuntu-latest in this specific run, the DNS lookup took longer than the 5-second pytest timeout, causing the test to fail with a timeout error rather than the expected RequestError.

This is a flaky test - the exact same test passed on main branch in run #20884597445 just hours earlier, confirming the test itself is sound but has timing issues.

Suggested Solution: Mock the HTTP client to avoid real network calls and ensure consistent, fast test execution. The test should use pytest-httpx (already in the project dependencies) to mock the HTTP responses.

Detailed Analysis

Error from logs:

ERROR    Error calling tool 'update_user'
ValueError: Request error: [Errno -5] No address associated with hostname
FAILED tests/server/openapi/test_end_to_end_compatibility.py::TestEndToEndCompatibility::test_tool_execution_parameter_mapping - Failed: Timeout (>5.0s) from pytest-timeout.

Why it happens:

• The test creates an httpx.AsyncClient with base_url="https://api.example.com"
• When call_tool is invoked, it attempts to make a real HTTP request
• DNS resolution for api.example.com can be slow depending on network conditions
• The pytest timeout (5s) is hit before the DNS lookup fails
• On other runs (like main #20884597445), DNS fails faster and the test passes

Evidence of flakiness:

• Main branch run #20884597445: PASSED (same test, same Python 3.10 ubuntu)
• This PR run #20885869654: FAILED (timeout)
• Other Python versions/platforms in same run: PASSED

Related Files

• tests/server/providers/openapi/test_end_to_end_compatibility.py:165 - The failing test
• src/fastmcp/server/providers/openapi/components.py:129 - Where the HTTP request is made
• tests/server/auth/test_jwt_provider.py - Example of using httpx_mock fixture correctly
• tests/server/auth/providers/test_introspection.py - Another example using httpx_mock

Note: This failure is not caused by the changes in this PR - it's a pre-existing flaky test introduced in #2835. The PR changes (upgrade instructions) don't affect test behavior.