An MCP server providing tools for Google Calendar and Gmail integration, with an agentic interface for task automation
This server demonstrates mediocre tool definition quality typical of early-stage MCP implementations. While all 7 tools have basic descriptions and visible schemas, the quality is inconsistent. Tool names follow action-verb conventions, but several critical deficiencies exist: descriptions lack specificity about when to use tools versus alternatives, parameters are underspecified (missing constraints, format details, examples of valid input), output schemas are completely undocumented, error handling is minimal, and there is a concerning copy-paste error in the update_upcoming_appointment description (duplicates create description). The schema definitions are present but generic; parameters like 'appointment_ids' accept Union[str, List[str]] which is problematic for LLMs, they cannot reliably choose between single vs. array formats without explicit guidance. No pagination support despite tools returning lists. No guidance on field dependencies or idempotency. This server would require substantial rework before confidently recommending to a production team.
Creates a new appointment in the user's Google Calendar.
Deletes one or multiple upcoming Google Calendar appointments by their appointment ID(s).
Displays the subject lines and thread IDs of recent emails in the Gmail account based on the number of days provided.
Fetches and formats upcoming Google Calendar appointments within a specified time range.
Retrieves and decodes the plain text content of an email from Gmail using its thread ID.
Sends an email using the Gmail API.
Output schemas completely undocumented. No description of return structure, field types, or expected content for any tool. LLMs cannot plan downstream tool calls or extract data without knowing what fields are returned.
update_upcoming_appointment has a copy-paste error in its description: it says 'Creates a new appointment in the user's Google Calendar' instead of describing the update functionality. This misleads LLMs about what the tool does.
Parameter 'appointment_ids' in delete_upcoming_appointments accepts Union[str, List[str]] with no guidance on which format to use. LLMs frequently fail to choose correctly between single and array inputs. Should split into two parameters (appointment_id for single, appointment_ids for batch) or require explicit type hints in description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Creates a new appointment in the user's Google Calendar.
No pagination or result limiting for list-returning tools (get_upcoming_appointments, display_recent_emails). Tools return unspecified number of results, risking context window exhaustion. Should add 'limit' and 'offset' or 'next_cursor' parameters and cap results to 20-50 items.
Optional parameters use empty string defaults ('', location='') instead of None or omission. This forces LLMs to reason about empty string semantics and creates ambiguity: does empty string mean 'omit field' or 'set to empty'? Use None with Optional[str] typing, or required parameters with clear defaults.
No error handling guidance. All tools catch HttpError and return generic 'An error occurred' strings. No indication of which errors are retryable, which require user action, or what the LLM should do next. Agents cannot self-correct without actionable error messages.
No documentation of input format constraints. DateTime parameters (appointment_start_date, appointment_end_date) state 'ISO 8601 format (e.g., 2025-04-24T14:00:00+02:00)' in descriptions, but no validation is visible. LLMs need explicit format strings and examples of valid timezone handling (e.g., UTC vs. local). Should specify: timezone required? seconds precision? daylight savings?
No indication of which tools are idempotent vs. irreversible. delete_upcoming_appointments and send_mail are destructive and non-idempotent, agents should know this before retrying. Descriptions must state: 'WARNING: This operation is irreversible and will permanently delete the appointment.' Agents should not blindly retry these calls.
Tools return unstructured strings ('A formatted string listing all appointments'). LLMs must parse free-form text rather than working with structured objects. Should return JSON objects with typed fields (e.g., [{id: string, summary: string, start: string, end: string}]) so agents can reliably extract data.
No parameter bounds or validation rules. days_into_the_future and days_into_the_past accept any integer with no min/max. LLMs could pass 999999 or negative numbers. Should specify: 'Integer between 1 and 365 (maximum 1 year)' or similar constraint.
Gmail API calls in display_recent_emails and read_mail are not visible in the provided source code. Tool definitions reference utility functions (get_emails, scrape_news) but actual implementation is truncated. Cannot verify whether these tools properly handle Gmail API pagination, thread formatting, or error cases.