A Model Context Protocol (MCP) remote server that provides access to Google services (Gmail, Google Calendar, Google Drive, Google Tasks, Google Contacts, YouTube) through OAuth 2.0 authentication
Mixed quality across 19 tools. Strengths: all tools have names following verb_noun conventions (greet, calendar_listEvents, etc.), all have descriptions, and input schemas are present with type definitions. Weaknesses: descriptions are mostly generic and under the recommended 50-200 character LLM-optimized range (avg ~60 chars); parameter descriptions often missing or minimal; no output schemas documented; no error handling guidance; no enum constraints on multi-value fields. Parameter naming inconsistent (calendar_id vs calendarId). The 'greet' tool is a throwaway placeholder. Write operations (createEvent, sendEmail, createFile) lack confirmation/dry-run guidance. Parameter descriptions for arrays (attendees, cc, bcc, labelIds) don't specify format or item constraints. Tool composition is reasonable but some tools are thin wrappers around Google APIs without LLM-friendly abstractions.
Parameter descriptions are minimal or missing. Arrays (attendees, cc, bcc, labelIds) lack item-type specification and format constraints. Example: 'attendees' describes it as 'List of attendee email addresses' but doesn't specify whether duplicates are allowed, case sensitivity, validation rules.
No output schemas documented. LLMs cannot plan downstream tool calls or know what fields to expect. Example: calendar_listEvents returns events but no schema shown for event objects (id, summary, start, end, attendees, etc.). This forces LLMs to guess at response structure.
Write operations (calendar_createEvent, calendar_updateEvent, drive_createFile, drive_updateFileContent, gmail_sendEmail, tasks_createTask) lack dry-run, confirmation, or rollback guidance. No description warns the LLM these are irreversible. Agents can accidentally send emails, create duplicate events, or overwrite files without safeguards.
Recommendations
Expand all tool descriptions to 100-180 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. Example: 'calendar_listEvents: List upcoming calendar events within a date range. Use this to check availability before creating an event. Defaults to 7 days from now if timeMax is omitted. Results are paginated (maxResults defaults to 25).'
Add descriptions to ALL parameters. For arrays, specify item types and constraints: 'attendees: List of attendee email addresses (comma-separated or array; duplicates ignored; max 50 per event)'. For enums, replace prose descriptions with explicit enums in the schema.
Document output schemas. For each list tool, specify the structure of returned items: 'Returns array of {id: string, summary: string, start: ISO8601, end: ISO8601, attendees: [{email: string, responseStatus: string}]}'. For create/update tools, document the created/updated resource structure.
Add 'dry_run' or 'confirm_before_execute' parameter to all write operations (createEvent, sendEmail, createFile, etc.). Let LLMs preview the action before committing. Descriptions should warn: 'This tool sends a real email, use dry_run: true to preview first.'
Add enum constraints to multi-value parameters. Example: 'format' in gmail_getEmail should be enum ['full', 'minimal', 'raw']. 'colorId' in calendar_createEvent should be enum ['1', '2', ..., '11'] with color names ('Peacock', 'Flamingo', etc.).
Score history
Overall score trend
↑ 3 points across a rubric change (v1 → v2)
59/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-21
D
59
2026-07-28+
v2
2026-03-09
D
56
-
v1
Search for contacts by name, email, or phone number.
Parameter naming inconsistent: calendar_id vs calendarId (camelCase). Inconsistent casing confuses LLMs and introduces mapping errors when chaining tools. All parameters should follow snake_case convention.
Multi-value enum parameters lack enum constraints. Example: 'format' in gmail_getEmail, 'colorId' in calendar_createEvent (documented as '1-11' but not an enum), 'showDeleted' in calendar_listEvents. Free-form strings invite hallucinated values.
Tool descriptions average ~60 characters; optimal range is 50-200. Descriptions are too brief and lack context for when to use the tool or dependencies. Example: 'List upcoming calendar events' doesn't explain whether it includes declined events, recurring event handling, or how to filter by attendee.
No error handling guidance. Descriptions don't tell LLMs what to do on failure (retry, ask user, recover). Example: calendar_createEvent might fail due to scheduling conflict, permission denied, or invalid attendee email, but no recovery guidance is provided.
Parameter defaults may cause unintended side effects. Example: tasks_listTasks defaults taskListId to '@default' but doesn't document this behavior, so LLMs may assume it searches all task lists. calendar_listEvents defaults timeMin to 'now' and timeMax to '7 days from now' but doesn't explain pagination or result limits.
No pagination guidance for list tools. calendar_listEvents, contacts_listContacts, drive_listFiles, gmail_listEmails, tasks_listTasks all return lists but descriptions don't explain if results are paginated, what the default/max result count is, or how to fetch the next page.
Include error recovery guidance in descriptions. Example: 'calendar_createEvent: If the event creation fails due to a scheduling conflict, try calling calendar_listEvents to find an available slot. If permission is denied, the calendar may be read-only.'
Add explicit pagination documentation. Example: 'calendar_listEvents: Results are paginated; maxResults defaults to 25 (max 2500). If you need more events, track the nextPageToken or nextSyncToken and call again with pageToken parameter.'
Document expected response field names. Example: 'tasks_listTasks returns [{id: string, title: string, status: string, due: ISO8601, parent: string}]'. This enables LLMs to chain tools: 'create_task returns task_id, which you can pass to update_task's task_id param'.
Add dependency hints in descriptions. Example: 'gmail_sendEmail requires 'to' recipients. If you only have a name, call contacts_searchContacts first to get email addresses.' or 'calendar_createEvent requires 'start' and 'end' in ISO8601 format, use tasks_getTask to extract due dates if needed.'
Replace example values in descriptions with format specifications. Remove 'e.g., 2023-10-26T10:00:00Z' and replace with 'ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ)'. Use JSON Schema format declarations instead of prose examples.
Clarify parameter relationships. Document mutual exclusivity (e.g., 'calendarId vs primary calendar default') and conditional requirements (e.g., 'If recurrence is set, end is calculated from the rule; otherwise end is required').