Loading ToolBench
Production-Ready Business & Data Intelligence Server for AI Agents
This server has significant definition quality gaps. Of 17 tools, most have basic descriptions (10-150 chars) but lack comprehensive parameter documentation and output schemas. Tool naming follows verb_noun conventions reasonably well (supabase_query, postgres_execute, validate_email), but parameter descriptions are sparse or absent in visible code. No tool explicitly declares output schemas, pagination support, or error handling guidance. Several tools (postgres_execute, slack_send_message, brave_search) expose parameters that could benefit from stricter validation. Database tools (supabase_query, supabase_insert, supabase_update) are particularly concerning because they accept free-form object parameters (filters, data, updates) with minimal type constraint documentation. The server follows basic composition principles (one action per tool) but lacks the polish expected of production systems.
Group by a field and calculate a metric (sum, avg, count)
Analyze CSV string data (Calculate mean, sum, max)
Search the web using Brave Search API
Calculate final price after discount and tax
Filter list of dicts based on exact match conditions
Generate an invoice structure
Get current weather for a city
postgres_execute accepts raw SQL queries with optional parameters array, creating SQL injection risk. No input sanitization or parameterization enforcement documented. Description does mention 'parameterized queries' but does not mandate their use or warn of injection risk.
supabase_query, supabase_insert, supabase_update accept 'filters' and 'data' as free-form objects with minimal type guidance. Descriptions mention 'optional filters with support for operators' but do not enumerate valid operators (lt, lte, gt, gte, like, ilike, neq) formally, only parenthetically. This invites LLMs to guess at operator names.
No tool declares output schema or return type. Descriptions state what the tool does (e.g., 'Query Supabase table') but do not document the structure of the response. This forces LLMs to guess whether results include pagination metadata, total counts, or field lists.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Merge two datasets on a common key (Inner Join)
Execute raw SQL query on PostgreSQL using connection pool
Schedule a reminder (Mock)
List public Slack channels in the workspace. Args: limit: Maximum number of channels to retrieve (default 20).
Send a message to a Slack channel. Args: channel: The channel name (e.g., 'general') or ID (e.g., 'C12345'). Note: The bot MUST be a member of the channel or be invited via `/invite @botname`. text: The message content to send.
Insert data into Supabase table
Query Supabase table with filters
Update records in Supabase table
Transform a list of dictionaries. Operations: uppercase, scale
Validate email format and extract domain
supabase_query accepts 'limit' parameter (default 100) but does not document pagination. Does it return next_cursor or total_count? Can you pass offset? This is ambiguous and will confuse LLMs when retrieving large result sets.
brave_search and slack_list_channels both return results with a 'count' parameter (default 5 and 20), but no details on pagination, ordering, or available filters. LLMs cannot plan multi-call retrieval strategies.
No tool declares required permissions (e.g., 'read:email', 'write:database'). Slack tools (slack_send_message, slack_list_channels) require a bot token with specific scopes, but this is undocumented in the tool definitions.
schedule_reminder is marked as READ_ONLY (mock) but tool description does not clarify that this is a no-op. If users expect scheduled reminders to actually fire, they will be confused by lack of side effects. Description should explicitly state 'Mock implementation; does not persist reminders.'
slack_send_message description includes detailed inline help ('The bot MUST be a member of the channel…') but this critical prerequisite is buried in parameter docs rather than the tool description. LLMs often miss parameter-level warnings. Move to tool description.
No error handling guidance visible. Tools do not document recovery paths for common failures (e.g., 'If SQL syntax error, check PostgreSQL docs'; 'If Slack send fails, verify channel membership'). This leaves LLMs unable to self-correct or suggest alternatives.
transform_json_data accepts 'operations' as an array of dicts with 'type', 'field', and optional 'factor', but valid operation types are not enumerated in the description. LLMs cannot know whether 'uppercase', 'UPPERCASE', 'upper', or 'upcase' is correct.
aggregate_data 'metric' parameter lists 'sum', 'avg', 'count' in description but does not specify format (must 'avg' be 'average'? or 'average'?). Should be an enum or at least explicitly spelled out in description.