Validating parameters before hitting the query

[jasdeep06]

Prerequisites

• Search the current open issues

Question

As in most real world consumption of this project, LLMs will be used to trigger these tools. LLMs might pick incorrect parameter or we might want to alter the parameters on some conditions. In a fastmcp implementation, we can put the validation/alteration inside the tool but here as only queries can be fired, what's the best place to put the validation/alteration in? Please keep in mind, langchain gives no way to interrupt tool call when parameters are picked before calling the tool.

Code

No response

Additional Details

No response

[Yuan325]

Hi @jasdeep06 Thanks for the question! To interrupt during stages of LLM in LangChain, you can setup callbacks. However, I believe that callback might not be intended to alter tool parameter. That being said, I'm not sure if there are any better ways to interrupt tool call to alter argument before a tool call with LangChain implementation.

I'm not sure how mature your project dev currently is, but I'd highly recommend using LangGraph. LangGraph will allow you to set up custom nodes for validation/alteration before running any tool calls. There's also a lot of other benefits for using LangGraph. Please let me know if you have more questions! I'll keep this open for a couple days.

[jasdeep06]

Hi @Yuan325 Thanks for your response!
We are currently using LangGraph.
My reservation in keeping tools specific parameter validation/alteration logic inside an agent(my langGraph code) would not be maintainable/scalable as I would have to duplicate it every time I intent to use that tool with a different agent. Don't you think it should live somewhere with tools?

[Yuan325]

@jasdeep06 Agree, it will probably be duplicated in cases where you are using multi-agent. It is currently in our milestone to support callbacks within Toolbox! :)

[jasdeep06]

@Yuan325 Thats great to hear!
Can you briefly point out to me the direction in which this will be implemented using the yaml approach?
How and where do you plan to let the user define these callbacks? If you can point me in the right direction, maybe I can pitch in!

[kurtisvg]

Hey @jasdeep06 -- thanks for your questions.

We aren't quite sure how exactly we are planning on adding this kind of pre/post processing.

An easy method would be to just add callbacks to our toolbox-core package so that it can clients can specify these on their own. The downside to that is as you mentioned, the callbacks are specific to each client.

Another (easier) way would depend on the type of validation required. Maybe we add an 'enum' parameter that only allows specific parameters.

A more complicated way would be allowing the user to provide code as a pre/processing step. We've discussed a few different ways to do this:
a) a plugin system that would enable adding callbacks (in Go). You could then specify them with "preprocessing" or "postprocessing" in the yaml somewhere.
b) Specifying some file(s) with code in them, which Toolbox could load and execute (hopefully supporting languages other than go)
c) Waiting until Toolbox has a proper control plane, and allowing serializable code to be pushed through it (e.g. pickleable python functions).

Can you provide a little more detail on your use case? Do any of the above options sound appealing to you?

[jasdeep06]

Hi @kurtisvg
Thanks for your reply!
We have a multi-agent system with multiple toolsets with tools built on top of huge telecom bigquery tables. Over 90% of contents of each tool is the query and rest 10% is split between pre and post processing.

A recurring theme of preprocessing can be validating the date format passed by llm to the tool(llms sometimes pass the dates in incorrect format), enforcing minimum number of days in case of a date range(Let's say a user says "Give me number of issues for the mdn xyz", the LLM sometimes passes the same current_date and end_date in the date range, we automatically set the end_date to current_date - X where X depends on the tool) etc.
Postprocessing on the other hand is extremely rare, but is pretty heavy when it is required. Like converting the returned results into a dataframe and doing some pandas operations on top of it.
Out of the 3 options you cited, option b) seems most appropriate for our usecase due to independency from Go(as the project is in python) and flexibility of freeflowing code.

Do tell me if you have any other impressions from our usecase!

[kurtisvg]

@jasdeep06 -- thanks for the info.

Do you have a POC at Google that we can reach out to? Would love to chat with you account team and see how we can better align Toolbox's roadmap to your usecase.

For immediate workarounds, we do have the HTTP tool, which would allow you to deploy some custom logic (e.g. to a Cloud Function or something similar) and expose it as a Tool for those 10% of use cases that are more complicated.

A recurring theme of preprocessing can be validating the date format passed by llm to the tool(llms sometimes pass the dates in incorrect format), enforcing minimum number of days in case of a date range(Let's say a user says "Give me number of issues for the mdn xyz", the LLM sometimes passes the same current_date and end_date in the date range, we automatically set the end_date to current_date - X where X depends on the tool) etc.

Would it be a useful feature to build this in? e.g. if we had a "date" parameter that allowed you to specify things like format, minimum, or maximum would that help?

We will definitely look into pre/post processing options -- just want to make sure we handle it carefully as arbitrary code execution can introduce new vulnerabilities.