swift-sdk

Motivation and Context this PR adds support for progress notifications (aka ) from the 2025-03-26 spec. How Has This Been Tested? i validated this change locally within a private codebase that uses this swift package. i updated that codebase to point to this feature branch via and confirmed that i received progress notifications when i attached a to a request. the spec mandates that both clients and servers should be capable of subscribing to progress notifications, but i only validated the client case. however, i believe the logic i wrote should work for servers subscribing to clients as well. if reviewers know of any sample projects in which i might validate this behavior, please let me know! i also wrote some unit tests for the new ProgressNotification type following the existing pattern set by the ResourceUpdatedNotification unit tests. Breaking Changes there shouldn't be any! i followed @stallent's first suggestion in https://github.com/modelcontextprotocol/swift-sdk/issues/82, which avoids breaking changes. Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [x] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [ ] I have added appropriate error handling [x] I have added or updated documentation as needed i roughly adhered to the pattern set by ResourceUpdatedNotification, which has no special error handling. however, please let me know if there's something i missed, and i'd be happy to update this PR! Additional context there are multiple ways to support progress notifications within this repository, most of which @stallent outlines in https://github.com/modelcontextprotocol/swift-sdk/issues/82. i'll summarize them here briefly, and explain why i chose this particular design: 1. require that callers must pass a in arguments when invoking a method (e.g., ). sender does not deliver progress directly; instead, the caller must subscribe to the stream for notifications (messages) with the passed into the method. 2. add an optional progress closure to all methods that support progress tracking. sender invokes this closure when it wishes to notify caller of progress. 3. modify the return types of all methods that support progress tracking to include an AsyncStream for progress notifications. callers can optionally process the progress updates that come through this stream. i did not consider option 2 because it doesn't feel like a modern iOS design pattern, and chose option 1 over option 3 because i like that it should work for all eligible methods with a minimal code footprint. the downside of option 1, however, is that the SDK does not make subscribing to progress notifications very obvious 😅 maintainers and community users, let me know what you think!