Tool Configuration
This page provides comprehensive documentation for configuring tools in PraisonAI, including timeout settings, performance optimization, error handling, and resource management.Tool Timeout Configuration
Basic Timeout Settings
Consolidated ToolConfig (new in PraisonAI 0.0.6x)
PraisonAI now provides a unifiedToolConfig dataclass that consolidates tool-related parameters into a single configuration object. This replaces the previous pattern of separate tool_timeout, parallel_tool_calls, and tool_retry_policy parameters.
ToolConfig Options
| Option | Type | Default | Description |
|---|---|---|---|
timeout | int | None | Tool execution timeout in seconds |
parallel | bool | False | Enable parallel tool execution |
retry_policy | RetryPolicy | None | Tool retry configuration |
Configuration Shortcuts
ToolConfig supports convenient shorthand notation:Deprecation Path
The standalonetool_timeout, parallel_tool_calls, and tool_retry_policy parameters are now deprecated and will emit DeprecationWarning in future versions. They still work for backward compatibility:
- Precedence: If
tool_configis provided, it takes precedence over standalone parameters - Merging: If
tool_configis omitted, standalone parameters are merged into a synthesizedToolConfig - Migration: Update existing code to use
tool_config=ToolConfig(...)instead
Agent-Level Tool Timeout
Each agent can settool_config=ToolConfig(timeout=…) (or tool_config=True for defaults) which applies to all tool executions. When a tool times out, it returns a standardized error dict:
- Each agent has its own 2-thread tool executor (reused across calls)
- Timed-out tools return
{"error": "Tool timed out after Ns", "timeout": True}rather than raising - Thread names are prefixed
tool-<agent_name>— useful for debugging
Why the change?
The consolidation groups timeout + retry + parallel execution settings into one config object instead of three loose kwargs. This provides better organization and prevents parameter conflicts.For complete concurrency control documentation including per-agent limits and sync/async patterns, see Concurrency.
Wrapper-Level Tool Timeout (YAML / CLI — Defense-in-Depth)
When you settool_timeout in YAML (framework: praisonai) or pass --tool-timeout on the CLI, the wrapper now wraps every tool callable with a timeout-enforcing shim before handing the agent to the SDK.
This means the tool_timeout knob is enforced even if the downstream SDK ignores it, even if the tool is a blocking C extension, and even if the tool is a subprocess that does not honour CancelledError.
The wrapper handles sync and async tools differently:
- Sync tools run in a daemon thread (
threading.Thread(daemon=True)); on timeout the wrapper returns a JSON error dict and abandons the thread (daemon threads do not block process exit). - Async tools are wrapped with
asyncio.wait_for(...); on timeout the wrapper returns the same JSON error dict.
tool_timeout to the SDK Agent, so both layers are active — hence “defense in depth”. The SDK’s executor catches the common case; the wrapper catches the pathological one.
Example usage:
fetch_url blocks for more than 15 s, the agent receives the structured JSON dict above instead of an indefinite hang, so the crew keeps moving.
Precedence note: When both wrapper-level and SDK-level timeouts apply, the shorter of the two wins in practice (whichever fires first). Both currently read from the same tool_timeout value, so they fire at the same time; if a user later configures different values at different layers, the first-to-fire semantics still hold.
Advanced Timeout Configuration
Dynamic Timeout Calculation
Performance Tuning
Resource Management
Tool Execution Strategies
Performance Monitoring
Tool-Specific Configurations
Web Scraping Tools
Database Tools
API Tools
File Processing Tools
Error Handling Configuration
Resource Pooling
Complete Tool Configuration Example
Environment Variables
For comprehensive tool whitelisting and collision prevention, see the Allowed Tools feature documentation.
Best Practices
Timeout Guidelines
-
Set appropriate timeouts based on tool type
- Fast operations: 5-15 seconds
- API calls: 15-30 seconds
- Web scraping: 30-60 seconds
- Data processing: 60-300 seconds
-
Use dynamic timeouts for variable workloads
-
Always set connection timeouts lower than read timeouts
Performance Optimization
- Enable caching for idempotent operations
- Use connection pooling for repeated operations
- Circuit breakers for tools are automatic - see Tool Circuit Breaker
- Monitor and alert on performance degradation
See Also
- Tool Development - Creating custom tools
- Agent Configuration - Agent-level tool settings
- Best Practices - Configuration guidelines

