Loading ToolBench
An MCP server that provides tools to interact with Google Calendar, enabling retrieval of future and past events, and creation of new calendar events.
This server has significant quality gaps. All 4 tools are directly visible in server.py with registered @mcp.tool decorators and input schemas. However, descriptions are in Japanese and lack the clarity and completeness expected for LLM tool selection. Most critically, parameter descriptions are minimal or absent, schemas are incomplete (missing constraints, ranges, enums), and error handling provides no recovery guidance. The tool composition is reasonable (each does one thing), but the definition quality falls well below production baseline. This is a D-tier server, typical of community implementations that work but lack polish for reliable agent use.
現在の日時を提供し、Google Calendar に新しい予定を追加します
Google Calendar の今後の予定を取得します
現在の日時をISO8601形式で取得します
Google Calendar の過去の予定を取得します
Descriptions are in Japanese and severely under-specified. English equivalents: 'Get upcoming Calendar events' (29 chars), 'Get past Calendar events' (24 chars), 'Add Calendar event' (18 chars), 'Get current datetime' (19 chars). This violates pattern:tool-description baseline of 10-1024 chars with meaningful context. LLMs cannot reliably infer when to select these tools.
No output schemas documented. The code returns structured dicts (e.g., {summary, start, end} for get_calendar_events), but the @mcp.tool decorators do NOT include return_type or output schema metadata. LLMs must infer return structure from behavior or documentation, neither of which exists.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Input parameters lack constraints. The maxResults parameter on get_calendar_events and get_past_calendar_events has type integer and a description, but no minimum, maximum, or explanation of the Google Calendar API limit (typically 250). An LLM could pass maxResults=1000000, causing an API error. Unbounded numbers let LLMs pass absurd values that break APIs or cause timeouts.'
No pagination support documented or implemented. Both get_calendar_events and get_past_calendar_events return limited results (maxResults=10 default). Without pagination, large results blow the context window.' Neither tool mentions how to fetch beyond the first 10 results, forcing multi-call loops.
Example values embedded in parameter descriptions. The add_calendar_event tool includes example ISO8601 timestamps like '2025-05-01T10:00:00+09:00' directly in parameter descriptions. LLMs latch onto example values like 'user_123' or '[email protected]' and pass them literally in real calls, causing failures.' This invites LLMs to reuse the exact example timestamp rather than adapting to current context.
No error handling or recovery guidance in tool definitions. The code has try/except blocks that log and re-raise exceptions (e.g., 'logger.exception("未来のカレンダーイベント取得中に例外発生")' then 'raise'), but the tool decorators do NOT document error conditions, recovery steps, or retry strategies.
Timezone handling is hardcoded and undocumented in tool interface. The add_calendar_event tool hardcodes 'Asia/Tokyo' timezone in both the description ('Asia/Tokyo') and the API call. The get_current_datetime_jst function hardcodes JST (UTC+9). However, tool descriptions do NOT state that timezone is fixed to Asia/Tokyo or warn that events created in other timezones will be misaligned. An LLM attempting to create an event at '2025-05-01T10:00:00+00:00' (UTC) will silently have it converted to JST.
add_calendar_event lacks idempotency and confirmation. This is a destructive (WRITE) operation that modifies state (creates calendar events). Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.' There is no dry-run, no confirmation, and no idempotency guarantee. An agent retrying a failed add due to transient error could create duplicate events.
No tool annotations for destructive operations. The MCP spec supports toolAnnotations like destructiveHint, idempotentHint, readOnlyHint. The code declares 'Risk: WRITE' for add_calendar_event and 'Risk: READ_ONLY' for others in the server metadata, but the @mcp.tool decorators do NOT include these as formal annotations.
Credentials exposed to OAuth2 flow without rate limiting or timeout. The get_credentials() function enters a loop that deletes and recreates token files on refresh failures, potentially triggering Google's rate limits or causing hung browser windows during local server auth. No explicit timeout documented, and no recovery path for hung auth flows.