Loading ToolBench
APIs and MCP Server for Enterprise Apps like Google, Notion, Hubspot with OAuth credential management and integrations
SuperAuth exposes 11 tools across Google Calendar, Gmail, Apollo CRM, and Celesto CRM APIs. Tool names follow verb_noun conventions (search, list, get, create), which is good. However, descriptions are generic and lack LLM-specific guidance. Parameter schemas are present and mostly well-typed, but output schemas are entirely undocumented. Error handling is absent, tools return raw API responses without recovery guidance. The server mixes read-only and write operations without explicit risk annotations (toolAnnotations feature missing). Overall: functional but lacks production-grade polish.
Create a new contact.
Create a Google Calendar event.
Get all contacts.
Get a single Google Calendar event.
Fetch a single message (metadata only).
Fetch message content and return body plus key headers.
List all contact stages.
No output/return schemas documented. LLMs cannot plan downstream calls or extract the right data from responses.
Tool descriptions lack WHEN to use them and are too generic. E.g. 'List Google Calendar events' does not explain when to call this vs get_event, what pagination returns, or what fields are included.
No error handling or recovery guidance. Tools return raw API responses without telling the LLM what to do if a call fails (e.g. 'User not found. Try search_users() with a partial name').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
List Google Calendar events.
Lightweight list of message IDs using Gmail's list API.
Search for contacts by keywords.
Search Gmail messages with metadata.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Write operations like create_event and create_contact are not marked as destructive, so the LLM does not know they have irreversible side effects.
Parameter descriptions lack constraints and format guidance. E.g. 'time_min' and 'time_max' do not specify ISO8601 requirement; 'max_results' does not explain the 1-250 range in the description (only in the schema).
search_messages and list_messages both search/list Gmail, names do not make the distinction obvious enough. search_messages with metadata vs lightweight list_messages is unclear without deep reading.
create_event accepts a raw 'event' object matching Google Calendar API schema, but no schema for that object is provided or documented. LLM must reverse-engineer valid structure.
No pagination guidance. list_events and search_messages return results but descriptions do not explain max record counts, whether results are truncated, or how to fetch the next page.