Add end-to-end tests for server-client communication

[jkawamoto]

This PR introduces end-to-end tests to detect potential miscommunication issues between servers and clients (e.g. #280).

The implementation includes:

• Basic end-to-end test suite using an Echo server
• Verification of session initialization
• Testing of resource templates, tools, and prompts listing functionality

Motivation and Context

End-to-end testing is essential for validating reliable communication between servers and clients, ensuring system integrity and proper interaction across components.

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

This PR only adds new tests and doesn't change any existing code.

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

[mcp-shadow]

Thank you for your contribution to the MCP Python SDK.

After careful review, I'm recommending closing this PR for the following reasons:

1. Redundancy with existing tests: The codebase already contains comprehensive integration tests in tests/server/fastmcp/test_integration.py that verify server-client communication across different transport methods (SSE, StreamableHTTP, stateless StreamableHTTP).

2. Limited test coverage: The proposed tests only verify listing capabilities (resource templates, tools, prompts) but don't test actual invocation or error handling scenarios, which are covered in the existing integration tests.

3. Increased maintenance burden: Adding another test approach without significant benefits would increase the maintenance burden with minimal gain. The existing integration tests already handle the communication issues you're hoping to detect.

4. Issue #280 is already addressed: The AttributeError issue you referenced has been fixed in the main codebase and doesn't require this specific test approach to catch similar problems in the future.

While I appreciate the intention to improve testing, enhancing the existing integration test framework would be more effective than adding a parallel testing approach. If you'd like to improve testing, consider extending the existing tests with additional scenarios or edge cases.

Thank you again for your contribution. If you have other ideas for improving the SDK, we'd be happy to review them!