Loading ToolBench
MCP server that orchestrates Gmail, Calendar, and Drive into an interactive daily planner UI
Two tools with clear names and good descriptions, but schemas lack critical details. load_day_planner has well-formed input schema with proper types, defaults, and constraints (date pattern, min/max for numeric params). handle_day_planner_action has enum-constrained actionType but payload is underspecified (additionalProperties with generic string type, no structure guidance). Both descriptions are substantive (150+ chars) and explain WHEN to use them. However, output schemas are completely undocumented, LLMs cannot plan downstream calls or extract structured data. No error handling guidance. Tool composition is reasonable (separate load vs action), but missing idempotency hints and recovery paths.
Processes an interactive action triggered by the user in the Day Planner UI. Action types: - mark_email_handled: User marked an email thread as done - start_meeting_prep: User wants prep help for a meeting - snooze_email: Snooze an email for N hours - open_doc: User opened a Drive document
Opens an interactive day planning dashboard showing your calendar, emails, and docs. The dashboard shows: - Today's calendar events (expandable to reveal related emails and docs) - Inbox emails prioritized by importance - Recent Drive documents surfaced by meeting context - Interactive buttons: expand events, mark emails handled, start meeting prep Use this to give the user a holistic view of their day.
Output schemas completely undocumented. LLMs cannot infer what load_day_planner returns (DayPlannerData structure) or what handle_day_planner_action returns. Forces agents to guess field names and types.
handle_day_planner_action payload parameter is dangerously underspecified. Type is 'object' with additionalProperties: {type: string}, but no documentation of which keys are valid for each actionType. E.g., mark_email_handled expects threadId, start_meeting_prep expects eventId, this dependency is invisible to LLMs.
No error handling guidance. If load_day_planner fails to fetch Gmail/Calendar/Drive data, what should the LLM do? Retry? Ask user? No recovery hints provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
No idempotency or confirmation hints. handle_day_planner_action modifies state (marks emails handled, snoozes, opens docs) but does not declare whether calls are idempotent or if they should be confirmed before execution.
load_day_planner maxEmails and maxDocs parameters have min/max constraints but no guidance on what happens if results exceed the limit. Are they paginated? Truncated? Ranked by importance?