Enhancement: Refactoring tool macro

[jokemanfire]

Due to some historical reasons, there are some different logical operations in the macro of the tool for template and non template operations. The purpose of this refactoring is to unify the operations of these two different types of macros and make the tool macro support multiple tool macro declarations for structures. For the implementation of service macros, it may be necessary to split them.

[4t145]

The design of macros do requires thorough discussion.

[jokemanfire]

I will provide a specific plan and demo in the next few days, and we will review them together later.

[jokemanfire]

I think the tool macro doesn't need to be too complex or even use the static variable TOOL_BOX. I think the entire tool macro can be implemented like codegen, which can easily cover template and non template types, and the code will be very simple and obvious. What do you think @4t145

[4t145]

There's a gap: the tool router implementaion is in trait Service, while the tool defination is in the impl block.

I came up with two solutions:

One solution is to generate some router functions, so user can call it from handler implementation.

The another one, is to create a static type with shared state just like build a service in axum. And then we can discard the macro.

[4t145]

#62 #159

[4t145]

1. For current CallToolHandler<'a, S, A>, we can remove the lifetime a. Since we always call on Arc<S>
2. We can have a router type Router<S = ()>

pub struct Router<S> {
    tool_router: ToolRouter<S>,
    resource_router: ResourceRouter<S>,
    // ... and so on.
    service: S,
}

pub fn build_router() {
    Router::new(Calculator::<u64>::default())
        .tool(
            Calculator::<u64>::sum,
            Tool::builder()
                .name("sum")
                .discription("sum two numbers")
                .parameters_type::<SumRequest>()
                .build(),
        )
        .build()
}

and then implement Handler for Router, router will filter the tool related request, can call it by tool handlers in tool router, which is the toolbox now. So we don't need static toolbox anymore, therefore the generic type would not be an issue.

Pros: this would be much easier to implement, and no magic for user.
Cons: user need to write the tool defination and implementation in different place.

[4t145]

And also @yIllusionSky. Maybe you could have a discussion here before writing any code.

[jokemanfire]

I think macros should still exist. and I think we can refer to the implementation of routing macros in actix web, which can generate adapted code without using any static variables.

[4t145]

We should not use static router in a lib anyway.

[4t145]

@jokemanfire
https://github.com/modelcontextprotocol/rust-sdk/pull/201/files#diff-ce4632077fe5bb8c0c5c6acf054464f194cd1fcffe38b875d67d047971f19d58

here's draft, a preview look like below:

    let router = Router::new(test_handler)
        // build with function
        .with_tool(
            TestHandler::sync_method
                .name("sync_method")
                .description("a sync method tool")
                .parameters::<Request>(),
        )
        // build with closure
        .with_tool(
            (|Parameters(Sum { a, b }): Parameters<Sum>| (a + b).to_string())
                .name("add")
                .parameters::<Sum>(),
        )
        // build with generator function, which can be generated by macros
        .with_tool(attr_generator_fn)
        .with_tools(tool_router);

And so does the promt

[jokemanfire]

Actually, from my perspective as a developer who calls RUST-SDK, I prefer to use macros, so I don't really want to use this method until I confirm that macros are completely unsuitable.