feat: provide blanket implementations for ClientHandler and ServerHandler traits

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge

[tninesling]

Adds blanket implementations for Box<T> and Arc<T> when T implements ClientHandler or ServerHandler.

Motivation and Context

When building an MCP service, we may want to wrap it in a smart pointer before passing it into the tower service constructor. In my case, I want to spawn a background thread to do some work using some session state as requests are processed. However, introducing the Arc results in a compilation error:

use std::sync::Arc;use rmcp::ServerHandler;use rmcp::transport::StreamableHttpService;structMyService;implServerHandlerforMyService{}fnstart_server(){let my_service = Arc::new(MyService);// This gives "the trait bound `Arc<MyService>: ServerHandler` is not satisfied"let http_service = StreamableHttpService::new(move || Ok(my_service),Default::default(),Default::default(),);// ...}

How Has This Been Tested?

Added integration tests and confirmed this fixes the compilation error in my project.

Breaking Changes

I believe adding blanket implementations of this kind is typically considered a breaking change, although it should be a no-op for most users.

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

I omitted blanket implementations for &T and &mut T due to the 'static bound on the traits, and I omitted Rc<T> due to the Sync bound.

[alexhancock]

@tninesling Nice! A good idea

I had a play with macros to see if it could dedupe some of the volume

Let me know what you think of 0b54219

It's somewhat vibecoded so let me know if it does the job and if you like it

[tninesling]

Let me know what you think of 0b54219

Thanks for taking a look @alexhancock. As long as those tests pass, it fixes the issue I ran into. Although, the macros in that commit add a lot of indirection that make it hard to read. I agree with the direction of deduplicating the implementations though. I added some simpler macros in a493962, which are slightly more verbose, but hopefully easier to read and maintain.

[alexhancock]

Yeah this seems like a good middleground, and cuts down on a lot of the original bloat. Thanks!

[alexhancock]

@tninesling Can you run the formatter: cargo fmt and then also make the commit messages only have valid https://www.conventionalcommits.org? Then we can merge