Loading ToolBench
Strong foundation with consistent naming (verb_noun pattern), comprehensive parameter schemas using Zod, and tool annotations. All 16 tools have descriptions and input schemas. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is basic (generic messages). Parameter descriptions are adequate but lack format/constraint details (e.g., Unix timestamp ranges, pagination limits). No batch operations or natural-identifier support (e.g., user email lookup requires exact match). Descriptions average ~100 chars, within baseline (p10=34, p90=392). All tools are READ_ONLY, reducing composition complexity.
Get full metadata for one Aircall call.
Get basic information about the authenticated Aircall company.
Get one contact by ID using the v2 Contacts API.
Get one phone number by ID using the v2 Numbers API.
Get one tag by ID using the v2 Tags API.
Get one team by ID using the v2 Teams API.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects). Downstream tool chaining requires guessing field names.
Parameter descriptions lack format/constraint details. 'from' and 'to' are Unix timestamps but no range guidance (e.g., 'Unix timestamp in seconds, 0 - present'). 'per_page' allows 1 - 50 but description does not explain Aircall's enforcement.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Get an AI-generated call transcription. Utterances are paginated locally to keep responses bounded.
Get one Aircall user by numeric ID or email address using the v2 Users API.
List calls from Aircall's available six-month history. Results default to compact newest-first metadata; retrieve a call by ID for complete details.
List contacts using the v2 Contacts API.
List phone numbers using the v2 Numbers API.
List tags using the v2 Tags API.
List teams using the v2 Teams API.
List Aircall users/agents using the current v2 Users API.
Verify that Aircall is reachable and the configured API credentials are valid.
Search calls by date, direction, user, phone number, and tag IDs. Aircall applies multiple tags as an AND condition.
Error handling is generic. All errors return 'Unexpected error while reading Aircall' or AircallApiError.message. No recovery guidance (e.g., 'User not found. Try search_users() with a partial name'). LLMs cannot self-correct.
aircall_get_user accepts 'identifier' as union[int, email] but description does not clarify precedence or error cases. If both are valid, which takes priority? What if email lookup fails?
No batch operations. aircall_search_calls filters by single user_id; agents cannot search multiple users in one call. Composition requires N sequential calls, wasting tokens and latency.