feat: Add nested argument formatting support

[Edison-A-N]

Description

This PR adds support for nested argument formatting in the Tool.to_code_prompt() method, providing comprehensive argument information to LLMs so they can generate correct nested arguments in a single attempt, reducing the need for error correction and reconfiguration cycles.

Changes

• Added format_nested_args() function: Supports recursive formatting of nested argument descriptions
• Supports up to 3 levels of nesting: With proper indentation to show hierarchical relationships
• Fully backward compatible: No impact on existing functionality

Testing

Added 3 new test cases:

• test_tool_to_code_prompt_with_nested_args: Tests basic nested argument formatting
• test_tool_to_code_prompt_with_deeply_nested_args: Tests deeply nested arguments (up to 3 levels)
• test_tool_to_code_prompt_with_mixed_nested_and_simple_args: Tests mixed argument types

All tests pass and code quality checks pass.

Example

Before:

# Complex nested arguments couldn't be properly formatted
inputs = {
    "config": {
        "type": "object",
        "description": "Configuration object",
        "properties": {
            "host": {"type": "string", "description": "Server host"},
            "port": {"type": "integer", "description": "Server port"},
        },
    }
}

After:

# Now provides complete nested structure for LLM understanding:
# Args:
#     config: Configuration object
#         host: Server host
#         port: Server port
# 
# This helps LLMs generate correct nested arguments like:
# {"config": {"host": "example.com", "port": 8080}}

[chahn]

Thanks a lot for this suggestion! I really like the direction you’ve taken with nested argument formatting.

I’d like to build on this and support a JSON schema to describe the input as well. If the input is a more complex object this approach would make a lot of sense, and would be a real improvement over the current implementation with a flat list of parameters.

We could do it the same way as we currently handle the output schema, to keep things consistent and flexible?

[Edison-A-N]

Hi @chahn , thank you so much for your thoughtful feedback!

I really appreciate your suggestion about supporting JSON Schema for input descriptions as well. You're absolutely right that this would provide a significant improvement over the current flat parameter list, especially for complex objects.

The indentation format works well for LLM comprehension (better accuracy, token efficiency, and readability), however, the indentation format still has limitations for complex object representations in input args, as evidenced by my recent fix that properly handles array types that weren't well addressed in the previous commit.

Since the comparison between indentation and JSON descriptions is still under investigation, I focused on extending the current input args to support nested parameter capabilities as an incremental improvement. I'm also considering implementing a pre-scoring function to intelligently determine which description format to use based on the complexity and structure of the input parameters.

I'd love to continue this discussion about the design paradigm for tool in/out description formats. Your insights on maintaining consistency with the existing output schema approach are invaluable. What are your thoughts on how we might best evaluate and potentially integrate both approaches?