feat: Allow instance-level customization of tool parameters

[psdaniel]

Summary

Enable instance-level customization of tools, allowing different instances of the same tool class to have unique configurations:

• Customize name, description, parameters, and provider_params at the instance level
• Instance values take precedence, with automatic fallback to class-level definitions
• Instance setters for post-initialization customization
• Documentation for instance-level customization patterns

Motivation

Closes #418

Currently, RubyLLM tools define descriptions and parameters at the class level only, meaning all instances share the same configuration. This limits flexibility for use cases like:

• Using multiple instances of the same tool with unique names (avoiding name collisions)
• Creating similar tools with different parameters for different contexts
• Allowing end-users to customize tool descriptions
• Supporting dynamic tool configurations without creating multiple classes

Usage

# Create instances with unique names to avoid collisions
berlin_tool = Weather.new(
  name: 'berlin_weather',
  description: 'Get Berlin weather'
)
paris_tool = Weather.new(
  name: 'paris_weather',
  description: 'Get Paris weather'
)

# Both tools available with unique names
chat = RubyLLM.chat.with_tools(berlin_tool, paris_tool)
chat.tools.keys  # => [:berlin_weather, :paris_weather]

# Or set after initialization
tool = Weather.new
tool.name = 'custom_weather'
tool.description = 'Custom description'

Test plan

• Unit tests for initialize with optional parameters (name, description, parameters, provider_params)
• Unit tests for fallback to class-level definitions
• Unit tests for instance setters
• Unit tests for params_schema with instance parameters
• Unit tests for multiple instances with different configurations
• Integration test for multiple tools with unique names
• Integration tests for instance-customized tools with Chat
• All existing tests continue to pass

[SpaYco]

With the current implementation, this would fail without giving a name, as both would have the same name and get overwritten.

I think the current name approach is great, as this won't break the overwriting functionality, but we need to be clear in the docs.

[SpaYco]

Suggested change

	if @instance_parameters
	return SchemaDefinition.from_parameters(@instance_parameters)&.json_schema if @instance_parameters.any?
	return nil
	end
	if @instance_parameters
	return SchemaDefinition.from_parameters(@instance_parameters)&.json_schema
	end

ruby_llm/lib/ruby_llm/tool.rb

Line 122 in bd2bb14

return nil if parameters.nil? || parameters.empty?

SchemaDefinition.from_parameters would return nil if the value is nil or empty.

we can also just one line it

Suggested change

	if @instance_parameters
	return SchemaDefinition.from_parameters(@instance_parameters)&.json_schema if @instance_parameters.any?
	return nil
	end
	return SchemaDefinition.from_parameters(@instance_parameters)&.json_schema if @instance_parameters