This server has critical definition quality gaps across all three tools. Tool descriptions are vague or generic (10-25 chars), parameter descriptions are minimal or absent, and schemas are incomplete. The server relies on a backend API (http://localhost:5000/api) whose contracts are not documented. Error handling exists but provides minimal actionable guidance. No output schemas are documented. The server also disables console logging (console.log = () => {}), which is a red flag for debugging. Overall, the tools are poorly specified for LLM-driven usage and would cause frequent misuse and confusion.
Tools (3)
get_emailsread onlyauthsource verified
Fetch unread emails from Gmail inbox
get_threadread onlyauthsource verified
Retrieve all emails in a specific thread by thread_id
send_replywriteauthsource verified
Send a reply to an email with optional custom text or predefined options
get_emails has EMPTY input schema ({}), violating schema registration. No parameter documentation exists. Description is only 19 chars ('Fetch unread emails'), too generic and fails to explain output structure or when to call it vs get_thread.
Output schemas are completely undocumented across all three tools. Code returns JSON via API, but LLMs have no visibility into field names, types, or whether results are paginated. This violates the core pattern:tool requirement for documented return types.
Parameter 'reply_text' in send_reply is marked optional with no default behavior documented. What happens if LLM omits it? Does the tool send an empty reply? The description says '(optional)' but provides no fallback logic or guidance.
send_reply
HIGH
Recommendations
Expand get_emails description to 50-150 chars: 'Fetch unread emails from Gmail inbox. Returns a list of email summaries with sender, subject, snippet, and thread ID. Call this first to discover threads, then use get_thread to read full content.'
Document get_emails output schema: Array of {email_id: string, sender: string, subject: string, content: string, timestamp: string (ISO 8601), thread_id: string}. Specify max result count (e.g. 20).
Add pagination parameters to get_emails: limit (default 20, range 1-100), offset (default 0). Return total_count and has_more in response.
Expand get_thread description: 'Retrieve a complete email thread by thread_id. Returns all messages in the thread with timestamps, senders, and full content. Use this after identifying a thread ID from get_emails to read the full conversation.'
Rewrite send_reply description: 'Send a reply to an email thread. First call without reply_text to receive suggested reply options (positive, neutral, negative). Then call again with the chosen reply_text to send the reply. Returns {success: boolean, message_id: string (on success), error: string (on failure)}.'
Document reply_text parameter: 'The reply message text to send. Required on second invocation after receiving reply_options. If omitted on first call, the tool returns available reply suggestions for the LLM to choose from.'
send_reply description (30 chars) is too vague. It does not explain the two-phase interaction: first call returns reply_options, second call with chosen reply_text sends. LLM cannot infer this branching behavior from the description.
No pagination support documented. get_emails and get_thread may return large result sets, but no limit, offset, or page_size parameters exist. Unbounded results risk exhausting context windows. Patterns recommend pagination with total count or next_cursor.
Error responses are caught but provide minimal recovery guidance. Code returns JSON with 'error' field, but does not categorize errors (retryable, user-fixable, fatal) or suggest next steps. LLM receives raw error message with no action.
Backend API contract is opaque. Code calls /emails, /thread, /reply endpoints with no schema validation or documentation of expected response structure. If API changes, tools silently break. LLM cannot reason about field mappings.
Console logging is disabled (console.log = () => {}) at startup. This prevents debugging and violates observability patterns. Production servers require logging for audit trails and incident investigation.
Parameter thread_id and email_id have minimal descriptions. They state 'The unique identifier for the email thread' and 'The unique identifier of the email to reply to' but do not explain format (e.g. are they Gmail thread IDs? How are they obtained?). LLM cannot fill these parameters without prior discovery.
No idempotence guarantees. send_reply is a write operation but offers no dry-run, confirmation, or idempotency token support. An agent retry could send duplicate replies. Violates confirmation-request pattern.
send_reply
Add output schema documentation for send_reply: On first call (no reply_text): {success: false, reply_options: [string], message: string}. On second call (with reply_text): {success: true, message_id: string, sent_at: string (ISO 8601)}. On error: {success: false, error: string, retryable: boolean}.
Implement error categorization in catch blocks. Return {error: string, retryable: true/false, nextStep: string}. E.g., 'Timeout connecting to Gmail API. retryable: true. Try again in 30s.' or 'Invalid thread_id format. retryable: false. Check thread ID from get_emails output.'
Remove console.log and console.error suppression. Replace with proper structured logging (use pino, winston, or MCP's built-in logging) so errors are recorded for debugging.
Add pagination to get_thread: If a thread has >50 messages, return limit and offset parameters, with total_message_count in response.
Implement dry-run for send_reply: Add optional dry_run: boolean parameter. When true, show what reply would be sent without actually sending it. Helps agents verify before taking irreversible action.
Document required Gmail API permissions for each tool. E.g. get_emails requires gmail.readonly scope; send_reply requires gmail.compose scope.
Add timeout enforcement: Wrap axios calls in a 30-second timeout. Return clear timeout error: {error: 'Gmail API timeout after 30s. Service may be slow. Try again in 1 minute.', retryable: true}.
Validate input parameters before API calls. E.g. thread_id must match Gmail's thread ID format. Return validation error with constraint details: {error: 'Invalid thread_id: must be a 16-digit number. Got: abc123'}.