feat: deprecate roots, sampling, and logging (SEP-2577)

[rohitg00]

Fixes #881

Motivation and Context

SEP-2577 deprecates three core protocol features: Roots, Sampling, and Logging. The deprecation is advisory. The features stay fully functional and there is no wire-level change; the SDK should signal the deprecation so downstream users get compiler warnings and migration guidance.

This marks the corresponding Rust APIs with #[deprecated]:

• Operations. Peer::create_message (sampling), Peer::list_roots (roots), Peer::set_level and Peer::notify_logging_message (logging). These are generated by the method! macros, which previously had no way to attach an attribute to a single entry, so the macros now forward an optional attribute list to the generated function.
• Capability builders. The generated enable_roots, enable_sampling, and enable_logging (and their _with variants), plus the hand-written enable_roots_list_changed, enable_sampling_tools, and enable_sampling_context. The builder! macro now forwards per-field attributes to the generated enable_* methods.
• Docs. Deprecation notes on the capability types and fields, and in the README Sampling/Roots/Logging sections.

The capability data structs (RootsCapabilities, SamplingCapability, SamplingTaskCapability) and the wire request/result types are documented as deprecated but not annotated with #[deprecated]. They carry no behavior, the spec makes no wire change, and the schemars::JsonSchema derive re-emits the lint past an item-level #[allow(deprecated)], which would force a broad module-level allow. Keeping the annotations on the API surface that users actually call gives the same advisory signal without the noise.

#[allow(deprecated)] is added at the crate's own call sites (handlers, the logging/sampling test suites, the sampling example, and the conformance server) so the build stays warning-clean. The test_message_schema snapshots are refreshed to pick up the new descriptions.

How Has This Been Tested?

cargo clippy -p rmcp --all-features --all-targets -- -D warnings
cargo test -p rmcp --all-features
cargo +nightly fmt --all -- --check

All pass. The sampling example and conformance server also build without deprecation warnings.

Breaking Changes

None. Deprecation attributes are advisory and do not change behavior or the wire format.

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

Additional context

The since value is set to 1.8.0, matching the most recent #[deprecated] added in #855.

[alexhancock]

This is really good and thanks for the quick turnaround!

The macros are getting kind of crazy... do you think it's worth modifying all of them for this or would it be better to find another way?

[rohitg00]

Good catch @alexhancock

I think that's the best way, I also went back and forth on this, so let me lay out why I kept the macro route.

The change is fully additive: every arm gets an optional leading $(#[$meta:meta])*, so all existing invocations match unchanged. Only the three deprecated call sites pass anything.

The alternative is pulling list_roots, set_level, and notify_logging_message out of method! and writing full pub async fn bodies just to hang one attribute on each. That duplicates the exact boilerplate the macro exists to remove, and splits the surface: some peer methods generated, a few written for no reason other than the attribute. Next time we need to deprecate or cfg a generated method, we need to write it again.

Forwarding the attribute fixes that once. Any arm can then carry #[deprecated], #[cfg(...)], or doc comments without further surgery, and every method stays generated the same way.

builder! is the same story for enable_roots / enable_sampling / enable_logging. They come out of the const-generic typestate muncher, so they can't be written without reimplementing the typestate, and an inherent method can't be shadowed. Threading the attribute through is the only way to deprecate them in place.