[Bug] dspy.ReAct aperiodically returns a AdapterParseError with Expected to find output fields in the LM response: [next_thought, next_tool_name, next_tool_args] Actual output fields parsed from the LM response: [next_thought, next_tool_name]
What happened?
I followed the DSPy with MCP tutorial from https://dspy.ai/tutorials/mcp/. The code is exactly the same apart from using my custom MCP server. The code runs most of the time but aperiodically run into the issue above.
Is this exception supposed to be a catch all? Note that the trace shows that tools are executed without an issue. Cannot post the entire trace since the data being used is proprietary, but happy to answer any follow ups to debug this.
Steps to reproduce
with dspy.context(lm=lm_sonnet_35v2): async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: # Initialize the connection await session.initialize() # List available tools tools = await session.list_tools()
# Convert MCP tools to DSPy tools
dspy_tools = []
for tool in tools.tools:
dspy_tools.append(dspy.Tool.from_mcp_tool(session, tool))
# Create the agent
react = dspy.ReAct(DSPyOrchestrator, tools=dspy_tools)
result = await react.acall(user_question=user_question)
return result
DSPy version
2.6.27
Adding more details from the trace. Seems like the last response uses 'tool_args' instead of 'next_tool_args'. Why could this happen? Exception from the 'Events' tab in the trace below (with proprietary references removed):
Adapter ChatAdapter failed to parse the LM response.
LM Response: [[ ## next_thought ## ]]
<Proprietary>
[[ ## next_tool_name ## ]]
fetch_semantically_relevant_data
[[ ## tool_args ## ]]
{"input_question": <Proprietary>}
Expected to find output fields in the LM response: [next_thought, next_tool_name, next_tool_args]
Actual output fields parsed from the LM response: [next_thought, next_tool_name]
@buchannan162 Sometimes model doesn't follow the instruction well. Try adding this to your signature's instruction (docstring):
Make sure when you decide the tool arguments, the section header should use `next_tool_args` instead of `tool_args`.
and see if that works.
Thanks! Have added it to my signature; will test more to see if that reliably fixes the issue.
Wonder if there's a more structured way to address this. I am using Claude Sonnet3.5 V2/ Sonnet 3.7, so I would expect the model to follow instructions specified in the ReAct module itself.
when i use qwen 32b, it fails everytime. generate "name_tool_args", not stable enough
Try using the model's recommended/default temperature. DSPy uses 0.0 by default, which was a problem in my case with certain models, causing the exact same issue...