feat: derive Tool description and parameters from function

[gaurav0107]

Related Issues

• fixes Add parameter and description creation from create_tool_from_function into Tool #9006

Proposed Changes:

Tool currently requires an explicit name, description, and JSON-schema
parameters. The schema-generation logic that turns a typed function into
parameters lived only inside create_tool_from_function, so there was no way to
build a Tool directly from a function without going through the separate
create_tool_from_function / @tool helpers — awkward when constructing tools from
config/YAML that already carry a callable.

This PR makes description and parameters optional and derives them from the tool's
function (or async_function) when they are not provided, matching the API the
maintainers outlined in the issue:

from haystack.tools import Tool

def get_weather(city: Annotated[str, "the city"] = "Munich") -> str:
    """A simple function to get the current weather for a location."""
    return f"Weather report for {city}"

tool = Tool(name="get_weather", function=get_weather)
# tool.description == "A simple function to get the current weather for a location."
# tool.parameters   == JSON schema generated from the type hints

Implementation:

• Extracted the signature→JSON-schema logic from create_tool_from_function into a
  shared, reusable _create_tool_parameter_schema(function, inputs_from_state) helper
  (no behavior change to create_tool_from_function).
• Made Tool.description and Tool.parameters optional (None default). In
  __post_init__, any missing field is derived from the available callable via a new
  _derive_description_and_parameters() method (description from the function
  docstring, parameters from _create_tool_parameter_schema). The helper is imported
  lazily to avoid a circular import (from_function imports Tool).
• Each field is derived only when missing, so an explicitly-provided value is never
  regenerated. name stays required.

The change is fully backward compatible: callers that pass description and
parameters explicitly get identical behavior.

How did you test it?

• Added unit tests in test/tools/test_tool.py (TestToolAutoDeriveFromFunction)
  covering: derivation from sync and async functions, equivalence with
  create_tool_from_function, backward compatibility (explicit values untouched),
  partial derivation (only the missing field), empty description when the function has
  no docstring, exclusion of inputs_from_state parameters from the derived schema,
  serialization round-trip, and the missing-type-hint error path.
• Ran the full test/tools/ suite (276 passed, 11 skipped), plus ruff format --check,
  ruff check, mypy, and the CI import smoke (.github/utils/check_imports.py,
  242 modules) locally — all green.
• Added a release note under releasenotes/notes/.

Notes for the reviewer

• name is intentionally kept required to keep the change minimal; name inference from
  the function could be a follow-up if desired.
• This PR was fully generated with an AI assistant. I have reviewed the changes and run
  the relevant tests.

Checklist

• I have read the contributors guidelines and the code of conduct.
• I have updated the related issue with new insights and changes.
• I have added unit tests and updated the docstrings.
• I've used one of the conventional commit types for my PR title: feat:.
• I have documented my code.
• I have added a release note file, following the contributors guidelines.
• I have run pre-commit hooks and fixed any issue.

[vercel]

@gaurav0107 is attempting to deploy a commit to the deepset Team on Vercel.

A member of the Team first needs to authorize it.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}