The current tool payload format nests tool request arguments as tool_args
payload_args = {
"tool_name": body["params"]["name"],
"tool_args": body["params"]["arguments"],
"client_session_id": "replaceme",
}
payload = ToolPreInvokePayload(name=body["params"]["name"], args=payload_args)
Ref: https://github.com/kagenti/plugins-adapter/blob/88a37f70f19bd78dfb0da4b6a04803377030f38f/src/server.py#L58C5-L63C83
One issue present is this requires plugins to process potentially nested arguments e.g.
payload_args={
"tool_name": "test2_hello_world",
"tool_args": {
"name": "bob"
},
"client_session_id": "replaceme"
}
Alternate options:
(1) Tool arguments can be flattened like payload_args = { **body["params"]["arguments"] ...} but this could risk collisions such as if "tool_name": "bob" were provided
(2) Other fields moved to another nested field (e.g. metadata) to remove some of the collision risk but still presents one level of nesting that plugins have to process. Naming for arguments vs. tool_args depending on how specific payloads are to MCP primitives can be subject to discussion
payload_args = {
"arguments": body["params"]["arguments"],
"metadata": {
"tool_name": body["params"]["name"],
"client_session_id": "replaceme",
}
}
(3) Potential combination of the above
payload_args = {
**body["params"]["arguments"],
"metadata": {
"tool_name": body["params"]["name"],
"client_session_id": "replaceme",
}
}
In all cases, any alterations to fields will require the ext-proc logic to parse the fields into the expected format to continue the flow (e.g. expected request format or response format)
The current tool payload format nests tool request arguments as
tool_argsRef: https://github.com/kagenti/plugins-adapter/blob/88a37f70f19bd78dfb0da4b6a04803377030f38f/src/server.py#L58C5-L63C83
One issue present is this requires plugins to process potentially nested arguments e.g.
Alternate options:
(1) Tool arguments can be flattened like
payload_args = { **body["params"]["arguments"] ...}but this could risk collisions such as if"tool_name": "bob"were provided(2) Other fields moved to another nested field (e.g.
metadata) to remove some of the collision risk but still presents one level of nesting that plugins have to process. Naming forargumentsvs.tool_argsdepending on how specific payloads are to MCP primitives can be subject to discussion(3) Potential combination of the above
In all cases, any alterations to fields will require the ext-proc logic to parse the fields into the expected format to continue the flow (e.g. expected request format or response format)