rust-sdk

Is your feature request related to a problem? Please describe.* Since this project is a library, it is unfavorable that it includes/requires the runtime from . If a project using the runtime or some other runtime tries to use this project, the runtime will now be needed to be running in addition to it, if there are no compatibility issues. Additionally, if a project uses a different version of the runtimes may be incompatible. Specifically, calls to will panic if not called within a Tokio runtime. This is bad news for projects that include this crate and use a different runtime. Describe the solution you'd like Remove dependency on feature, and any calls to in library code. Describe alternatives you've considered N/A Additional context* A library crate bringing it's own async runtime is bad, and forces the consuming project of this crate to make more significant decisions about using the same runtime, having a larger binary size with two runtimes, or in the worst case, compatibility issues. Note that removing the feature means that some portions that rely on can not compile. Consider refactoring these areas with from the crate. Additionally, some spots that use and may be replaceable with plain s (but will now need polled/awaited somehow! took care of that before). And in complex cases, you may even consider to poll or await the same future from multiple spots. I understand this may be a large refactor, perhaps one for a major release. Async Rust also gets a lot harder when we can't just tasks, adding to the complexity of this refactor.

Summary When an MCP server returns a with , the scopes are correctly parsed and stored in , and used for the authorization URL. However, they are never included in the Dynamic Client Registration (DCR) request. Per RFC 7591, the DCR request should include a field so the authorization server knows what scopes the client intends to use. Servers that enforce scope-matching between registration and authorization reject the flow without this. Changes Add optional field to with for backward compatibility — servers that don't expect in DCR won't see it Update to accept a parameter and include it in the DCR request body and returned Thread scopes from into both call sites Re-export trait so downstream consumers (e.g., Goose) can call on token responses to extract granted scopes Add serialization tests verifying the field is present when and absent when Test plan [x] — both new tests pass [ ] Connect to an MCP server that returns scopes in and verify the DCR request includes the field (inspect via ) [ ] Verify backward compatibility: servers that don't expect in DCR continue to work (field omitted when no scopes)