Task: Enhance Tool Parameter Descriptions for LLM Agent Integration

You are working with an LLM (Large Language Model) agent that uses a suite of tools to handle user requests. Each tool is designed to perform a specific pre-defined task. The agent determines the most appropriate tool for the given task and invokes its associated Python method to execute it.

Each Python method includes:

- A method signature, which consists of the method name and its input parameters.
- A method body, which defines the functionality of the method.

Your task is to create or improve the descriptions of these input parameters.

Input - You will receive the following details about a tool:

- "tool_name": The name of the tool.
- "current_tool_description": A description of the tool's purpose and functionality.
- "method_name": The name of the Python method associated with the tool.
- "method_signature": The full method signature, including input parameters.
- "method_body": The Python code implementing the method.
- "declarations" : Information about class or parameter declarations in the code.
- "existing_parameter_descriptions": The current descriptions for each input parameter, if available.

Instructions

(1) Generate Missing Descriptions: If a parameter lacks a description, create a clear and concise one that accurately reflects its role.
(2) Improve Existing Descriptions: If a description is already provided, refine it for clarity, conciseness, accuracy and completeness. If the description is already of high quality, retain it as-is.
(3) No Redundancy: Ensure no information in the parameter description repeats itself or include overly verbose details.
(4) Extract Constraints from Code: Analyze the method body and declarations to identify any constraints for the parameters. For string parameters, include details such as allowed values (enums), default values, formats, maximum length, or fixed character limits if specified. For numeric parameters, mention any default values as well as minimum and maximum limits. For boolean parameters, document the default value if it is mentioned in the code or declarations. Include these constraints only when they can be clearly derived from the code or parameter declarations; do not add assumptions or uncertain details.
(5) Exclude Data Types: Avoid mentioning the parameter's data type (e.g., "This is a string parameter.") in the descriptions
(6) Identify Optional Parameters: If you can confidently infer from the method signature that a parameter is optional, add the text "This parameter is optional." at the end of the parameter description.  A parameter is considered optional if it is explicitly annotated as optional in the method signature (e.g., workflow_state: Optional[str]) or has a default value assigned (e.g., workflow_state: str = "draft") . If the parameter is required, do not mention that the parameter is required.
(7) Avoid Internal References: Parameter descriptions must not reference any variables or parameters defined only within the method body or in helper functions from rest_of_the_code, as these are internal implementation details not exposed to the user. Descriptions should be based only on parameters explicitly defined in the method_signature, since these represent the actual inputs available to the user.
(8) Output Format: Provide the final parameter descriptions in JSON format, with parameter names as keys and their corresponding descriptions as values. Do not add any markdown code in the output like ```python, ```json etc.
