fix: use MSRV-aware dependency resolver

[DaleSeo]

Motivation and Context

uuid 1.27.0 came out on Oct 2 and requires Rust 1.89. We don't commit Cargo.lock, so every CI run resolves the newest versions. The MSRV job now picks uuid 1.27.0 and fails with rustc 1.88.0 is not supported (seen on #1248). main passed only because its last run finished before the release. The next run will hit the same failure.

resolver = "2" was set explicitly, which turned off MSRV-aware fallback. The key has to stay explicit: the root Cargo.toml is a virtual manifest, so without it Cargo falls back to resolver 1 even though the members use edition 2024. With resolver 3, Cargo picks the newest version that works with 1.88 instead. Resolver settings apply only inside this workspace, so downstream users of rmcp are not affected.

How Has This Been Tested?

cargo +1.88 check --all-targets --all-features

Breaking Changes

None.

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

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

[chrikrah]

Approve at ad6f3e7. The resolution flips exactly as you describe. One premise behind it does not hold here: on a virtual manifest, edition 2024 would not have given you resolver 3. That matters the next time somebody reads the key as redundant.

$ cargo --version
cargo 1.96.1 (356927216 2026-06-26)

# exported tree at 8f9a28e
$ grep '^resolver' Cargo.toml
resolver = "2"
$ cargo generate-lockfile 2>&1 | tail -3
      Adding generic-array v0.14.7 (available: v0.14.9)
      Adding matchit v0.8.4 (available: v0.8.6)
      Adding sse-stream v0.2.6 (available: v0.3.0)
$ grep -A1 '^name = "uuid"' Cargo.lock
name = "uuid"
version = "1.27.0"

# exported tree at ad6f3e7
$ grep '^resolver' Cargo.toml
resolver = "3"
$ cargo generate-lockfile 2>&1 | tail -3
      Adding matchit v0.8.4 (available: v0.8.6)
      Adding sse-stream v0.2.6 (available: v0.3.0)
      Adding uuid v1.26.1 (available: v1.27.0, requires Rust 1.89.0)
$ grep -A1 '^name = "uuid"' Cargo.lock
name = "uuid"
version = "1.26.1"

non-blocking: the description reads "the workspace uses edition 2024, where resolver 3 is the default". Deleting the key from your branch says otherwise:

$ sed -i '/^resolver = "3"/d' Cargo.toml && rm Cargo.lock && cargo generate-lockfile
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2024 which implies `resolver = "3"`
$ grep -A1 '^name = "uuid"' Cargo.lock
name = "uuid"
version = "1.27.0"

A virtual manifest has no root package, so there is no package.edition to infer the resolver from, and the fallback is 1. Cargo.toml:12 declares rust-version = "1.88", which is above the 1.84 that understands resolver 3.

I compiled nothing here, only cargo generate-lockfile; your Check MSRV is the 1.88 build. It went red on #1318 at 01:08 UTC today against 8f9a28e: uuid@1.27.0 requires rustc 1.89.0. Merging this unblocks that one.

@DaleSeo worth one comment line above the key saying a virtual workspace falls back to resolver 1 without it?

[DaleSeo]

@chrikrah Good catch, thanks. You're right that the root manifest is virtual, so edition 2024 on the members doesn't carry over, and the fallback is resolver 1. I added a comment so nobody removes it as redundant, and updated the PR description to match.