Loading ToolBench
AI-powered email ghostwriter and approval gate for managing inbox triage, draft generation, human approval, and email sending via Gmail. Streamlit-based UI with LLM backends (OpenRouter/Gemini) and calendar integration.
This is a Streamlit application, not an MCP server. No MCP protocol implementation detected. Descriptions exist but are narrative/docstring-style, not LLM-optimized. No error handling guidance, no permission gates, no audit trail integration despite log_action existing. Transport is unknown (Streamlit is a web framework, not an MCP transport). This scores as a proof-of-concept application, not a production MCP server.
Build LLM context from a thread for draft generation. Takes a thread and returns formatted context string.
Check if a time slot is available on the primary Google Calendar. Takes ISO 8601 start and end times, returns boolean.
Create a calendar event on the primary Google Calendar. Takes summary, start time, duration, attendee list, and optional description. Returns the full Google Calendar API response dict with id, htmlLink, summary, start, end, attendees, and status.
Generate an AI email draft reply for a given thread. Takes a thread with subject and messages, returns a draft reply text.
Generate an AI email draft reply with metadata. Returns a dict containing 'draft' (text), 'model' (LLM model used), 'subject', and 'reply_to'.
Pull email threads from Gmail inbox via the Gmail MCP server. Returns threads in engine format: [{'thread_id', 'sender', 'subject', 'snippet', 'date'}]
Not an MCP server. This is a Streamlit web application with Python functions, not an MCP-compliant tool server. No MCP protocol implementation, no tool registration via MCP, no transport layer for remote access.
11 of 13 tools have no visible input schema. fetch_threads, assemble_context, last_availability_error, and get_action_log lack JSON Schema definitions entirely.
Descriptions are narrative/docstring-style (40 - 55 chars average), not LLM-optimized. 'Pull email threads from Gmail inbox via the Gmail MCP server' lacks WHEN to use, prerequisites, or output structure. Descriptions should be 50 - 200 chars and answer: what, when, what returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Find the first free time slot from a list of proposed times. Takes list of ISO 8601 times and duration in minutes, returns the first available slot or None.
Retrieve the complete audit trail from action_log.json. Returns list of logged actions.
Retrieve the last error message from calendar availability checks. Returns empty string if no error, or error text if a check failed.
Log an action to the audit trail (action_log.json). Records action type, timestamp, thread subject, detail, and optional message ID.
Parse a meeting request email thread using Gemini LLM. Extracts proposed times, duration, and attendees. Returns dict with 'proposed_times' (list of ISO strings), 'duration_minutes', and optional 'parsing_error'.
Send an email reply through the Gmail API. Takes thread_id, recipient address, subject, and body; returns Gmail API response with message_id and status.
Classify email threads by priority using an LLM. Takes threads with 'sender', 'subject', 'snippet' and returns the same threads with added priority labels: 'urgent', 'needs-reply', 'important', 'fyi', 'low-priority', or 'spam'.
No error handling guidance. Tools like send_reply and create_event are irreversible (WRITE/IRREVERSIBLE risk) but lack recovery hints, retry classification, or confirmation patterns. Agents cannot distinguish retryable from fatal failures.
No permission gates or scope declarations. Destructive tools (send_reply, create_event, log_action) lack permission checks or audit trail integration. log_action exists but is not called by other tools, breaking the audit chain.