Loading ToolBench
iOS/macOS application providing tool integrations for Notion, Gmail, Google Calendar, Google Contacts, and Apple system services (Calendar, Reminders, Contacts)
OpenResponses is a Swift-based tool provider for Notion, Gmail, Google Calendar, Google Contacts, and Apple Calendar. Tool definitions are visible in ToolProvider.swift and AppleCalendarRepository.swift with basic schemas and descriptions. However, critical gaps undermine quality: (1) descriptions are minimal (10-50 chars), far below the 194-char baseline for production tools; (2) parameter descriptions are sparse or missing entirely, most params lack context on format, constraints, or valid ranges; (3) no output schemas documented, LLMs cannot predict response structure; (4) no error handling guidance, failures provide no recovery path; (5) duplicate tool names (fetchEvents appears twice with different signatures, violating single-responsibility principle); (6) transport mechanism unknown, preventing protocol assessment. The server reads from external APIs (Gmail, Notion, GCal, Apple Calendar) but lacks the structured, LLM-optimized definitions required for reliable agent integration.
Create a new calendar event in Apple Calendar
Fetch events from Apple Calendar within a date range
Fetch events from Apple Calendar using ISO8601 date strings
List databases under a Notion page
List calendar events within a date range
List recent email threads from Gmail
Search contacts by query string
Descriptions are critically short (10-50 chars vs. 194-char baseline). 'List databases under a Notion page' and 'List recent email threads from Gmail' lack context on when to use each tool, what data is returned, or prerequisites. LLMs cannot reliably select tools without richer descriptions.
Parameter descriptions are missing or trivial. 'max' appears in 3 tools with no explanation of default, range, or impact. 'query' in searchContacts lacks format guidance. 'startISO8601' and 'endISO8601' lack examples or validation rules. LLMs cannot infer constraints from names alone.
Duplicate tool name 'fetchEvents' with two different signatures (one with 'start'/'end', another with 'startISO8601'/'endISO8601'). This violates single-responsibility principle and forces LLMs to reason about which variant to call. Merge into one canonical tool or rename clearly (e.g., fetchEventsWithDates vs. fetchEventsISO).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
No output schemas documented. LLMs cannot predict what fields are returned (e.g., does listDatabasesUnderPage return database IDs, names, URLs?). Without documented response structures, agents cannot chain tools or extract required data for downstream calls.
No error handling guidance. If a Notion page ID is invalid or Gmail auth fails, what does the tool return? How should the LLM recover? No recovery hints, error categorization, or actionable messages documented.