Is rmcp macro too complicated?

[yIllusionSky]

I think some parts are a bit redundant, such as having to mark each variable with #[tool(param)] or #[tool(aggr)]. I looked at the source code of rcmp-macros, and I think we can simply judge by the number of variables after excluding variables such as self. When it is greater than 1, pack them together, and use a single one in other cases. The effect is as follows:

use rmcp::{
 ServerHandler,
 handler::server::wrapper::Json,
 model::{ServerCapabilities, ServerInfo},
 schemars, tool,
};
use serde::Serialize;

#[derive(Debug,Serialize, serde::Deserialize, schemars::JsonSchema)]
pub struct SumRequest {
 #[schemars(description = "the left hand side number")]
 pub a: i32,
 pub b: i32,
}
#[derive(Debug, Clone)]
pub struct Calculator;
#[tool(tool_box)]
impl Calculator {
 #[tool(description = "Calculate the sum of two numbers")]
 fn sum(&self, sum: SumRequest) -> String {
 (sum.a+sum.b).to_string()
 }

 #[tool(description = "Calculate the difference of two numbers")]
 fn sub(
 &self,
 a: i32,
 b: i32,
 ) -> Json<i32> {
 Json(a - b)
 }
}

[4t145]

I also think the current macro design is not good.

When it is greater than 1, pack them together, and use a single one in other cases.

So what about a structure with merely one field?

[yIllusionSky]

I also think the current macro design is not good.

When it is greater than 1, pack them together, and use a single one in other cases.

So what about a structure with merely one field?

I tried to modify it yesterday, and of course I encountered several problems. It may be related to my failure to read the mcp specification carefully.

When you say struct has only one variable, do you mean A(i32)?

[yIllusionSky]

I also think the current macro design is not good.

When it is greater than 1, pack them together, and use a single one in other cases.

So what about a structure with merely one field?

哦好吧你是国人啊，我还特意搞机翻了。我刚刚稍微看了一下，你的意思应该是mcp应该是强制将传输对象限制为object的原因，所以对于单个string这种可能会出问题这样的意思吗。我想是有解决办法的。

有些地方我其实有点疑惑，比如在macro中的tool_impl_item对于范型参数你是进行了单独处理，而对于非范型参数你则使用了rmcp的tool_box!宏，我昨天暂时没去看tool_box!的实现，我省事直接将tool_box这部分移除掉，直接使用为范型的那一部分，也就是

input.items.push(parse_quote! {
 async fn call_tool(
 &self,
 request: rmcp::model::CallToolRequestParam,
 context: rmcp::service::RequestContext<rmcp::RoleServer>,
 ) -> Result<rmcp::model::CallToolResult, rmcp::Error> {
 self.call_tool_inner(request, context).await
 }
 });
...

它给我的反馈也是没什么问题的

[4t145]

@yIllusionSky 一般来讲，用英语还是为了其他可能关心同样问题的人也能有一个参与讨论的机会

比如有一个结构体InternalStruct, 然后你现在只有一个参数is: InternalStruct，你期望的工具的参数类型是InternalStruct还是

struct Param {
 is: InternalStruct,
}

你能理解我的意思吗？

泛型支持是后来添加的，可能修改者在添加的时候并没有考虑到代码复用的问题，如果你觉得可以优化这方面的代码，欢迎你提PR！

[yIllusionSky]

Param

在目前。根据我的改动我将此处改成了当只有一个结构体的时候，如果属于单元结构体或者元组结构体，如i32,A(i32)一类，我将其划分为了Param自动构建。对于其他类型的结构体，工具类型将直接作为它的类型。

不过我思索了一下有Vec这种类型，还需要进行事后的修改。我想可以为struct添加一个derive，添加这个derive的struct在单参数中将被作为Param的存在

[4t145]

@yIllusionSky 我觉得你这样是不合理的，我提到的情况实际上在使用中是很有可能发生的，开发者可能会先声明一个字段，这个字段下面是一个结构体，后面再逐渐添加新的字段。你这样的“归类”限制了开发者的自由，并且引入的特殊规则，破坏了直觉。

而且你也不需要Derive，本身，结构体只要实现了schemars::JsonSchema就行，这个已经有Derive了。

[yIllusionSky]

@yIllusionSky 我觉得你这样是不合理的，我提到的情况实际上在使用中是很有可能发生的，开发者可能会先声明一个字段，这个字段下面是一个结构体，后面再逐渐添加新的字段。你这样的“归类”限制了开发者的自由，并且引入的特殊规则，破坏了直觉。

而且你也不需要Derive，本身，结构体只要实现了schemars::JsonSchema就行，这个已经有Derive了。

对于一些默认类型是有实现schemars::JsonSchema，比如i32，或者元组结构体如A(i32)，但是我测试过如果直接使用它们当参数会报错，原因跟ensure_object_schema_for_type这个函数的返回有关

for i32
{
 "$schema": String("http://json-schema.org/draft-07/schema#"),
 "format": String("int32"),
 "title": String("int32"),
 "type": String("object"),
}

for struct{a:i32}
{
 "$schema": String("http://json-schema.org/draft-07/schema#"),
 "properties": Object {
 "i": Object {
 "format": String("int32"),
 "type": String("integer"),
 },
 },
 "required": Array [
 String("i"),
 ],
 "title": String("A"),
 "type": String("object"),
}

我的新的想法是将参数默认直接作为#[tool(aggr)]这种格式，而对于开发者想要它作为param时，再添加derive或者直接在变量上标注的形式。

对于大部分开发者来说，其实不需要纠结是将struct打包进params或者作为整个params，并且也不会因为后者对实际效果和性能提升太多。ai并不会因为少了一层包装而提高多少效率，甚至mcp的本身就是大量的描述而非精简化。。对于特定的开发者，想要更高的自定义，就再添加这些过程宏从而实现#[tool(param)]的效果

[yIllusionSky]

@yIllusionSky 我觉得你这样是不合理的，我提到的情况实际上在使用中是很有可能发生的，开发者可能会先声明一个字段，这个字段下面是一个结构体，后面再逐渐添加新的字段。你这样的“归类”限制了开发者的自由，并且引入的特殊规则，破坏了直觉。

而且你也不需要Derive，本身，结构体只要实现了schemars::JsonSchema就行，这个已经有Derive了。

这是我现在的想法，当然我英文不是特别的好，最终命名可以用其他的
就是默认这个pack="param"，以param的形式，至于ServerHandler的内容，我对tool_box也进行了一下修改，现在它会默认实现ServerHandler，并以description或者doc注释来命名工具。如果不想使用可以default_build=false

use rmcp::{
 ServerHandler,
 handler::server::wrapper::Json,
 model::{ServerCapabilities, ServerInfo},
 schemars, tool,
};

#[derive(Debug, serde::Deserialize, schemars::JsonSchema)]
pub struct SumRequest {
 #[schemars(description = "the left hand side number")]
 pub a: i32,
 pub b: i32,
}
#[derive(Debug, Clone)]
pub struct Calculator;
#[tool(tool_box,description="a simple tool")]
impl Calculator {
 #[tool(description = "Calculate the sum of two numbers",pack="aggr")]
 fn sum(&self,SumRequest { a, b }: SumRequest) -> String {
 (a + b).to_string()
 }

 #[tool(description = "Calculate the difference of two numbers")]
 fn sub(
 &self,
 #[schemars(description = "the left hand side number")]
 a: i32,
 #[schemars(description = "the right hand side number")]
 b: i32,
 ) -> Json<i32> {
 Json(a - b)
 }
}

[4t145]

@yIllusionSky 基于现在的设计，参数除了工具请求和&self，还可能是任意实现了FromToolCallContextPart的类型，你这样是不是没有考虑到这些类型提取的兼容？比如一个很重要的，就是CancellationToken。

[yIllusionSky]

@yIllusionSky 基于现在的设计，参数除了工具请求和&self，还可能是任意实现了FromToolCallContextPart的类型，你这样是不是没有考虑到这些类型提取的兼容？比如一个很重要的，就是CancellationToken。

我去看一下这几个trait，我还没注意到这些

[4t145]

Since it looks like the discussion not going on now. I will close this pr.