Loading ToolBench
This server has 3 tools with visible schema definitions and descriptions. All tools are read-only Gmail operations (search, get, download). Naming follows verb_noun convention (gmail_search_messages, gmail_get_message, gmail_download_attachment), which is good. However, descriptions contain Japanese text mixed with English, lack clarity on when to use each tool vs. alternatives, and parameter descriptions are minimal. Schemas are present and properly typed via Zod, but output schemas are not documented. Error handling exists but is generic. No parameter enum constraints despite search/download having predictable inputs. The server depends on external Google Apps Script backend, which is unusual architecture for an MCP server.
指定したmessageIdとattachmentIdで添付ファイルを取得します。 ファイルはDownloadsフォルダに保存されます。 attachmentIdはattachmentsの各attachmentのnameでありファイル名となることが多いです(invoice.pdfなど)。 引数: - messageId: メッセージID（必須） - attachmentId: 添付ファイルID（必須） - outputFilename: 保存時のファイル名（オプション）
指定したmessageIdのメール本文と詳細を取得します。 引数: messageId (GmailのメッセージID)
Gmail内で指定したクエリに一致するメールを検索します。 queryパラメータはGmailの検索クエリ形式で指定します。 例: "subject:Meeting newer_than:1d" 結果はJSONで返り、メール一覧(件名、messageIdなど)を含みます。
Descriptions lack English clarity and depth. All three tools have descriptions mixing Japanese and English, providing minimal context on WHEN to use each tool vs alternatives, or HOW the returned data flows to downstream operations. The description for gmail_get_message is only ~80 chars and does not explain what details are returned or when to call it after search.
Output schemas are not documented. The tool descriptions do not specify what fields are returned (e.g., what does gmail_search_messages return? Is it {threads: [{subject, messageId}], ...}?). LLMs cannot plan downstream tool calls without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Parameter descriptions are minimal or absent. The 'query' parameter for gmail_search_messages has a description, but it only says 'Gmail search query string' without explaining the expected format (is it free-form Gmail syntax? Does it support operators like 'from:', 'subject:', 'newer_than:'?). The description contains an example 'subject:Meeting newer_than:1d', but this is buried in the tool description, not in the parameter annotation itself.
No error recovery guidance. Error responses are generic: 'Error: {message}'. When gmail_search_messages fails due to invalid query syntax, the LLM receives no hint on how to fix it or what to try next. Pattern expects errors to guide recovery: 'Invalid query syntax. Gmail search supports operators like from:, subject:, newer_than:, etc.'
No idempotence or confirmation for destructive operations. While gmail_download_attachment is marked as WRITE (downloads and saves to disk), there is no dry-run, confirmation, or explicit note that repeated calls with the same messageId and attachmentId will overwrite the outputFile. The description does not warn about this side effect.
Incomplete input validation messaging. Schema validation uses Zod (good), but error messages just echo the parsed error object without translating it to actionable guidance. E.g., 'Invalid arguments for gmail_search_messages: [error object]' vs. 'query parameter is required and must be a non-empty string'.
No pagination or result limit documented. gmail_search_messages can return many threads, but there is no mention of pagination, result limits, or how to handle large result sets. The pattern expects 'page/offset and limit parameters and return a total count or next_cursor' for discovery tools.