Skip to content

Conversation

@Edison-A-N
Copy link

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
Copy link
Contributor

chahn commented Oct 24, 2025

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants