Co-authored-by: David Soria Parra <davidsp@anthropic.com>
Co-authored-by: Basil Hosmer <basil@anthropic.com>
Co-authored-by: ihrpr <inna@anthropic.com>
* refactor: improve typing with memory stream type aliases
Move memory stream type definitions to models.py and use them throughout
the codebase for better type safety and maintainability.
GitHub-Issue:#201
* refactor: move streams to ParsedMessage
* refactor: update test files to use ParsedMessage
Updates test files to work with the ParsedMessage stream type aliases
and fixes a line length issue in test_201_client_hangs_on_logging.py.
Github-Issue:#201
* refactor: rename ParsedMessage to MessageFrame for clarity
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* refactor: move MessageFrame class to types.py for better code organization
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* fix pyright
* refactor: update websocket client to use MessageFrame
Modified the websocket client to work with the new MessageFrame type,
preserving raw message text and properly extracting the root JSON-RPC
message when sending.
Github-Issue:#204
* fix: use NoneType instead of None for type parameters in MessageFrame
🤖 Generated with [Claude Code](https://claude.ai/code)
* refactor: rename root to message
* Close resources
* Close all resources
* Update pyproject.toml
* Close all resources
* Close all resources
* try now...
* try to ignore this
* try again
* try adding one more..
* try now
* try now
* revert ci changes
* feat: allow lowlevel servers to return a list of resources
The resource/read message in MCP allows of multiple resources
to be returned. However, in the SDK we do not allow this. This
change is such that we allow returning multiple resource in
the lowlevel API if needed. However in FastMCP we stick to
one, since a FastMCP resource defines the mime_type in the decorator
and hence a resource cannot dynamically return different mime_typed resources.
It also is just the better default to only return one resource.
However in the lowlevel API we will allow this.
Strictly speaking this is not a BC break since the new return value
is additive, but if people subclassed server, it will break them.
* feat: lower the type requriements for call_tool to Iterable
Adds sampling and list roots callbacks to the ClientSession, allowing the client to handle requests from the server.
Co-authored-by: TerminalMan <84923604+SecretiveShell@users.noreply.github.com>
Co-authored-by: David Soria Parra <davidsp@anthropic.com>
This test ensures that the server properly preserves and returns the same request ID in responses,
which is a fundamental part of the JSON-RPC protocol. The test initializes the server, sends
requests with custom IDs, and verifies that these IDs are correctly returned.
Github-Issue:#192
Add comprehensive documentation for lifespan support:
- Add usage examples for both Server and FastMPC classes
- Document startup/shutdown patterns
- Show context access in tools and handlers
- Clean up spacing in test files
Adds comprehensive tests for lifespan functionality:
- Tests for both low-level Server and FastMCP classes
- Coverage for startup, shutdown, and context access
- Verifies context passing to request handlers
This commit adds support for request cancellation and tracking of
in-flight requests in the MCP protocol implementation. The key
architectural changes are:
1. Request Lifecycle Management:
- Added _in_flight dictionary to BaseSession to track active requests
- Requests are tracked from receipt until completion/cancellation
- Added proper cleanup via on_complete callback
2. Cancellation Support:
- Added CancelledNotification handling in _receive_loop
- Implemented cancel() method in RequestResponder
- Uses anyio.CancelScope for robust cancellation
- Sends error response on cancellation
3. Request Context:
- Added request_ctx ContextVar for request context
- Ensures proper cleanup after request handling
- Maintains request state throughout lifecycle
4. Error Handling:
- Improved error propagation for cancelled requests
- Added proper cleanup of cancelled requests
- Maintains consistency of in-flight tracking
This change enables clients to cancel long-running requests and
servers to properly clean up resources when requests are cancelled.
Github-Issue:#88
