chore: Update SDK documentation

[marvin-context-protocol]

This PR updates the auto-generated SDK documentation to reflect the latest source code changes.

📚 Documentation is automatically generated from the source code docstrings and type annotations.

Note: This PR is fully automated and will update itself with any subsequent changes to the SDK, or close automatically if the documentation becomes up-to-date through other means. Feel free to leave it open until you're ready to merge.

🤖 Generated by Marvin

[marvin-context-protocol]

Test Failure Analysis

Status Update (Latest): ✅ The underlying test issue has been resolved on main. The most recent test run on main (#4448) is now passing. This PR is based on the latest passing commit (8d80299), so re-running the tests should succeed.

Summary: The Windows test job failed during this run. Previous analysis identified this as a test_uv_transport timeout issue that was affecting the main branch.

Root Cause: The test was hanging during subprocess connection, likely related to changes in PR #2719. However, subsequent commits to main have resolved this issue.

Suggested Solution:

Re-run the failed tests. Since main is now passing and this PR is based on the latest main commit, the tests should pass on retry.

If tests still fail after re-run:

1. Check if the PR branch needs to be rebased (though current state shows it's up to date)
2. Investigate any Windows-specific issues in the latest workflow logs

---

Comment updated: Analysis reflects latest test status on main branch

Previous Analysis (Historical)

The original failure was related to test_uv_transport timing out after 10 seconds when attempting to connect to a FastMCP server via UvStdioTransport.

The timeout occurred at:

tests/client/transports/test_uv_transport.py:48
async with client:
    result: CallToolResult = await client.call_tool("add", {"x": 1, "y": 2})

The subprocess started successfully but the client connection never completed, suggesting:

• The subprocess was running but not responding to MCP initialization
• Possible deadlock in parallel provider query logic
• Stdio transport connection handshake failing silently

Error cascade after timeout:

1. Timeout (>10.0s) from pytest-timeout
2. BrokenPipeError: [Errno 32] Broken pipe during subprocess cleanup
3. RuntimeError: Event loop is closed in BaseSubprocessTransport.__del__

This issue was introduced in PR #2719 ("Consolidate get_* and list* methods into single API") and has since been fixed.

Related Files

• tests/client/transports/test_uv_transport.py:26 - Previously failing test
• src/fastmcp/client/transports.py:653 - UvStdioTransport implementation
• src/fastmcp/client/transports.py:384 - StdioTransport.connect_session
• src/fastmcp/server/server.py:793 - get_tools (recently changed in Consolidate get_* and _list_* methods into single API #2719)

[marvin-context-protocol]

Test Failure Analysis

Summary: The integration test test_call_tool_ko timed out after 30 seconds while attempting to call a non-existent tool on GitHub's remote MCP API at https://api.githubcopilot.com/mcp/.

Root Cause: This appears to be a flaky test caused by intermittent issues with the external GitHub Copilot MCP API service. The test expects an McpError to be raised when calling a non-existent tool, but instead the call hangs indefinitely until the pytest timeout triggers.

Evidence that this is flaky:

• ✅ Integration tests passed in workflow run #20515284210 (same PR, 30 minutes earlier)
• ✅ Integration tests passed in workflow run #20515285793 (main branch, same time period)
• ❌ Integration tests failed in this run #20515291837
• This PR only changes documentation files (docs/python-sdk/**) and contains no code changes

Suggested Solution:

Re-run the workflow - this is a transient failure. The test passed successfully on the same PR commit earlier and should pass again.

If the test continues to fail intermittently, consider:

1. Adding retry logic to the integration test
2. Increasing the timeout for this specific external API test
3. Adding better error messages to distinguish between "API down" vs "test failure"

Detailed Analysis

The test test_call_tool_ko at tests/integration_tests/test_github_mcp_remote.py:90-97 attempts to verify error handling by calling a non-existent tool:

async def test_call_tool_ko(
    self, streamable_http_client: Client[StreamableHttpTransport]
):
    """Test calling a non-existing tool"""
    async with streamable_http_client:
        assert streamable_http_client.is_connected()
        with pytest.raises(McpError, match=r"unknown tool|tool not found"):
            await streamable_http_client.call_tool("foo")

The failure shows the test hanging in the asyncio event loop waiting for a response that never arrives:

E           Failed: Timeout (>30.0s) from pytest-timeout.

This indicates the GitHub Copilot MCP API endpoint either:

• Didn't respond within 30 seconds
• Is experiencing degraded performance
• Has a bug in error handling for non-existent tools

Related Files

• tests/integration_tests/test_github_mcp_remote.py - Contains the failing test
• All changed files are documentation only (docs/python-sdk/**/*.mdx)