Loading ToolBench
Production-ready MCP server framework with caching, rate limiting, OpenTelemetry, and 6 pre-built servers for database, web scraping, file processing, analytics, email, and calendar
Scoring was not performed
4 tools have no visible input schemas in source code (query_database, process_file, chunk_text, detect_file_type). These are only inferred from file references or imports. Schema visibility is zero for these.
Output schemas are not documented in any tool descriptions. LLMs cannot plan downstream tool calls without knowing what fields are returned (e.g., does list_events return event_id, event_uuid, or both?). This forces wasteful discovery queries.
Destructive tools (delete_event) and write tools (record_metric, create_event, send_email, create_contact, create_opportunity) lack confirmation/dry-run patterns. Agents cannot preview changes before execution, risking accidental data loss or unwanted actions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No error handling or recovery guidance in any tool description. No indication of what errors are retryable, user-fixable, or fatal. When query_database fails with 'no results', the agent has no guidance on next steps.
Parameter descriptions lack constraints and validation rules. For example, 'aggregation' in query_metrics lists options in description ('avg', 'sum', etc.) but these should be declared as an enum in the schema, not prose. 'z_threshold' in detect_anomalies mentions 'default 2.0' but no min/max bounds are stated.
Several tools accept contact/event/metric identifiers but do not clarify whether they accept system IDs, names, or both. 'event_id' in delete_event and 'metric' in query_metrics are ambiguous, can they resolve human-friendly names, or only opaque IDs?
Multi-step workflows (search_contacts → create_opportunity) do not include chaining field documentation. Response from search_contacts must include contact_id for create_opportunity, but this is not stated in the tool descriptions.
Tools accepting 'variables' as JSON strings (draft_from_template with 'variables: {"name": "John"}') require LLM string serialization, which is error-prone. Consider accepting a structured parameters object instead.
Pagination is not documented. list_events, list_available_metrics, search_emails, and search_contacts accept 'limit' parameters but do not mention offset, cursor, or total_count in their descriptions. Large result sets could exhaust context.
Timestamps use inconsistent formats. Some tools describe 'ISO 8601' (list_events, create_event), others use 'ISO 8601' without specifying timezone behavior. record_metric says 'optional ISO 8601 timestamp', optional to what? System time?