5 of 6 standards met
These changes aim to remove most calls to and other runtime-intertwined calls. These changes are to support runtime-agnosticism. Motivation and Context This will allow the project to be used in other environments where is not available or cannot be used. I originally raised this issue in #290, but some real demand for this particular change may be present in #379. How Has This Been Tested? This refactor should be testable via the existing unit tests. As development continues, we can add more unit tests if needed. I also hope to perform real smoke-test, minimally using the already existing examples in this repo. Breaking Changes Yes, users will most likely need to update their code. This will very likely be a breaking change. Types of changes [x] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [x] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update 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 Additional context This is an ongoing draft. Please feel free to interject with comments or concerns. Could eventually close #290
Motivation and Context Reduces spam in the logs. How Has This Been Tested? Yes, validated that the log is no longer being printed. Breaking Changes No. Types of changes [x] 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 Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context
Repository: modelcontextprotocol/rust-sdk. Description: The official Rust SDK for the Model Context Protocol Stars: 3075, Forks: 470. Primary language: Rust. Languages: Rust (98.3%), Shell (1.2%), JavaScript (0.4%), Python (0.1%), Just (0%). Latest release: rmcp-v0.17.0 (1d ago). Open PRs: 9, open issues: 23. Last activity: 1d ago. Community health: 87%. Top contributors: 4t145, jokemanfire, dependabot[bot], github-actions[bot], DaleSeo, alexhancock, jamadeo, tanish111, Z9RTM, gpeal and others.
Last 12 weeks ยท 94 commits
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)