Loading ToolBench
Local AI assistant with 80+ tools for Gmail, Calendar, Drive, GitHub, Slack, browser, code execution, file management, and task automation. Supports 38 agents, visual workflows, and multi-agent deliberation. Free tier with Liara (Qwen3 32B), or bring your own API key (Anthropic, OpenAI, Gemini, DeepSeek, etc.). OAuth tokens stored locally—no cloud data.
This is a large, feature-rich personal assistant toolkit (32 tools across Gmail, Calendar, Tasks, Web tools). Tool definitions are present with descriptions and parameter schemas, but quality is uneven. Many tool descriptions are good (50 - 150 chars, action-oriented), but parameter documentation is inconsistent. Some tools lack enum constraints on categorical parameters (e.g., gmail_mark_read accepts 'all', 'count', or 'messageId' as alternatives but doesn't express mutual exclusivity clearly). Error handling guidance is minimal, most tools lack recovery hints. The schema quality is moderate: types are present, but many parameters miss constraints (ranges for numbers, patterns for dates, enum values for categorical inputs). Security considerations are implicit (tool descriptions warn to confirm destructive actions) but not formally declared (no scope annotations like 'read:email', 'write:calendar'). Output schemas are documented only in high-level prose within the TOOL_DEFINITIONS template, not in machine-readable JSON Schema. Composition is reasonable, tools are single-responsibility and reference chaining appears sound (e.g., calendar_find returns eventId for use with calendar_update). Overall, this is solidly competent but lacks the polish of production A-grade toolkits.
Create a NEW calendar event. start/end are ISO 8601 datetime strings. Use this when the user says: "inserisci", "aggiungi", "crea", "metti", "fissa", "prenota", "add", "create", "schedule", "book". summary = the TITLE of the event (what you'd write on a calendar grid). description = optional NOTES/details. NEVER put the title in description. NEVER leave summary empty. Always derive summary, date and time from the actual user message — never use literal values from this documentation.
List all events for a specific date (YYYY-MM-DD). Use this when the user asks about a specific day (e.g. "May 13", "next Tuesday"). ALWAYS prefer this over calendar_week when a specific date is mentioned.
Delete (permanently remove) a calendar event by its eventId. You MUST call calendar_find first to get the eventId. ALWAYS confirm with the user before deleting.
Search for a calendar event by name/keyword in the next N days (default 30). Returns matching events with their IDs. ALWAYS use this FIRST when the user wants to modify an event — you need the eventId.
List ALL events for a full calendar month. month is YYYY-MM (e.g. "2026-05"). Defaults to current month. USE THIS when the user asks for events in a month: "appuntamenti di maggio", "eventi di giugno", "show me April", "cosa ho in marzo". NEVER use calendar_find with month names — use calendar_month instead.
Mutually exclusive parameters not formally documented. gmail_mark_read accepts 'all', 'count', or 'messageId' but the schema does not express that exactly one must be provided, or what happens if multiple are passed. LLMs may pass multiple and be confused by partial execution.
Output schemas not in machine-readable JSON Schema format. Descriptions provide prose explanations of return types (e.g., 'Returns matching events with their IDs'), but no formal schema object is visible in the tool registration. LLMs cannot programmatically validate or rely on the structure.
No enum constraints on categorical parameters. 'priority' in task_add could be 'low|medium|high' but is documented as free-form string. 'opts' in fetchUrl is 'object' with no schema for valid keys. LLMs will guess at valid values and fail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Reschedule an event. ALWAYS confirm before moving.
List all events for today.
List all events for tomorrow.
List upcoming events in the next N hours (default 2).
Update ANY field of an existing calendar event: title, location, description, start time, end time. Only include fields that need to change. HOW TO GET eventId: From your OWN previous tool response in this conversation (real eventId from calendar_create/calendar_find/calendar_date), or call calendar_find first, or never fabricate eventId.
List all events for a full week starting from startDate (YYYY-MM-DD). Defaults to current week.
Parse and extract structured metadata from HTML: title, description, OpenGraph, Twitter cards, canonical, lang, robots, h1..h3 headings, JSON-LD blocks.
Fetch and retrieve content from a URL with SSRF protection, realistic browser headers, timeout handling, and decompression support.
Fetch URL with structured metadata extraction (OpenGraph, Twitter cards, JSON-LD, headings).
Archive a specific email (removes from inbox).
Delete an email. Query can be a messageId OR a search term like "pranzo from:me in:sent". Finds the matching email and moves it to Trash. ALWAYS confirm before deleting.
Create a draft email (safe — does not send).
Search emails. query uses Gmail search syntax (e.g. "from:boss@co.com", "is:unread subject:invoice"). Default maxResults = 10.
Mark emails as read. Options: all=true marks ALL unread. count=5 marks the last 5 unread. messageId marks one specific email.
Mark emails as unread. count=5 marks the last 5 read emails as unread. messageId marks one specific email.
Read the full body of an email by its ID (returned by gmail_list).
Reply to an existing email thread. ALWAYS confirm before sending.
Send an email. ALWAYS confirm with the user before sending.
Fast HEAD reachability check (smoke test) for a URL.
Send a desktop notification reminder.
Find optimal meeting slots considering existing calendar events, locations, and estimated travel time between appointments. Returns ranked slots with travel info.
Add a new task to the local task list.
Clear all completed tasks.
Delete a task.
Mark a task as complete.
DuckDuckGo HTML scraping web search.
Search via DuckDuckGo and fetch the top N results with content extraction.
No scope/permission annotations. Tools do not declare what OAuth scopes or permissions they require (e.g., 'read:email', 'write:calendar'). Users and agent planners cannot assess least-privilege configuration or audit trails.
Limited error recovery guidance. Descriptions warn to confirm destructive actions but provide no guidance on what to do if execution fails. E.g., 'gmail_send fails with network error', should the agent retry? Ask user? Escalate? No hints.
Parameter type descriptions missing for 'opts' objects. fetchUrl, fetchUrlRich, and headProbe accept 'opts' objects but do not document what keys, types, or structure are valid. LLMs cannot construct valid options without trial-and-error.
No idempotency guidance. Tools like gmail_send and calendar_create are write operations, but no documentation indicates whether repeated calls with identical params are safe (idempotent) or will duplicate data. Agents need this to handle retries safely.
Date/time format constraints vague. Parameters like 'startDate', 'date', 'month' in calendar tools are documented as 'YYYY-MM-DD' or 'YYYY-MM' in prose, but no JSON Schema pattern property enforces this. LLMs frequently format dates incorrectly (ISO 8601 vs locale-specific).
No pagination guidance for list tools. gmail_list and webSearch accept maxResults but do not explain offset/cursor pagination, total count returned, or how to iterate through large result sets. Agents may miss results or retry incorrectly.
Tool composition risk: calendar_move vs calendar_update. Both modify event properties; the distinction is not obvious from names alone. calendar_move implies rescheduling (start/end), but calendar_update also accepts start/end. LLMs may pick the wrong tool.