This server has moderate definition quality with significant gaps. Tool descriptions are present but vary in quality (avg ~120 chars, below the 194-char baseline for A+ tools). Parameter schemas are mostly complete with types and descriptions, meeting minimum requirements. However, output schemas are not documented, critical for LLM planning. Error handling exists but lacks actionable recovery guidance. The 'smart_' tools demonstrate good intent (contact resolution, confirmation patterns) but lack explicit documentation of how resolution works, what happens on ambiguity, and what the LLM should expect. The safe_tools trio (prepare_email, prepare_file_share, prepare_calendar_event) show promise with confirmation-request patterns, but lack complete response schema documentation. Overall, the server is functional but below production-grade quality for agent tool patterns.
Output schemas not documented. Tools return dictionaries with success/error/preview/message fields, but the LLM has no formal schema to understand structure, field types, or downstream chaining requirements. This violates the documented output schema pattern and forces LLMs to infer response structure.
Contact resolution behavior undocumented. smart_send_email, smart_share_file, and smart_create_event resolve contact names to emails internally via smart_email_resolve(), but the tool descriptions do not explain what happens if resolution is ambiguous, fails, or returns multiple matches. LLMs cannot plan error recovery.
smart_send_emailsmart_share_file
Recommendations
Add formal output schemas to every tool. For each tool, document the response structure as a JSON schema: fields (e.g., success, error, data, preview), types (string, boolean, object, array), and descriptions. E.g., drive_list_files should return {success: bool, files: [{id: string, name: string, mimeType: string, ...}], total: int, next_cursor?: string}.
Document contact resolution behavior for smart_* tools. Add to descriptions: 'If recipient is ambiguous (e.g., multiple contacts named Jack), returns error with available matches. Requires exact email or unambiguous name. Supports first.last@domain, nickname@domain, and full display name formats.' Include example error response.
Implement and document the confirmation workflow for safe_tools. Either: (1) add a second tool confirm_email() / confirm_share() / confirm_event() that accepts confirmation_params from prepare_*, OR (2) merge prepare_* and smart_* into single tools with a 'dry_run' parameter. Document which approach in tool descriptions with examples.
Add parameter constraints. For enum fields, declare valid values: role in smart_share_file should enumerate ['reader', 'writer', 'commenter']. For numeric fields, set bounds: max_results in drive_list_files should document min=1, max=100, default=20. For timestamps, specify format: start_time should be 'RFC 3339 with timezone (e.g., 2024-01-15T14:30:00Z)'.
Document pagination for list operations. drive_list_files should specify: 'Returns up to max_results items. If more exist, response includes next_cursor. Call again with cursor parameter to fetch next page.' Add cursor parameter to schema.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 8 points across a rubric change (v1 → v2)
58/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-21
D
58
<=2025-11-25
v2
2026-03-09
D
50
-
v1
77/100
Prepare calendar event creation - shows what will be created and requires confirmation
prepare_emailwriteauthsource verified75/100
Prepare email for sending - shows what will be sent and requires confirmation
prepare_file_sharewriteauthsource verified73/100
Prepare file sharing - shows what will be shared and requires confirmation
Error handling lacks actionable recovery. Tool descriptions mention errors but do not guide LLMs on next steps. E.g., drive_get_file could fail due to 'file not found', 'permission denied', or 'size limit exceeded', each requires different recovery (search_files, request_access, use_chunked_read). Bare error codes provide no guidance.
Confirmation pattern unclear for safe_tools. prepare_email, prepare_file_share, and prepare_calendar_event return 'requires_confirmation: true' and include a 'confirmation_params' dict, but there is no documented second tool to execute confirmation. The return message suggests calling confirm_send_email(), but no such tool is registered. This breaks the confirmation-request pattern.
Parameter descriptions lack format constraints. E.g., start_time and end_time in smart_create_event accept 'ISO format' but do not specify timezone handling, whether 'Z' suffix is required, or whether naive timestamps are accepted. max_results in drive_list_files has no min/max bounds documented. Processing_mode in process_large_json lacks enum constraint despite accepting only 'smart', 'streaming', or 'sampling'.
Pagination not fully documented. drive_list_files accepts max_results but does not clarify whether results are paginated, whether there is a next_cursor or next_page_token, or what happens when more results exist than the limit. Without pagination guidance, LLMs cannot retrieve large file lists.
Tool names mix verb_noun (get_file, list_files) with adjective_verb_noun (smart_send_email, prepare_email), reducing naming consistency. Additionally, 'smart_' tools and 'prepare_' tools serve overlapping purposes, send_email vs smart_send_email vs prepare_email creates ambiguity about which LLMs should choose. The distinction (smart = automatic resolution, prepare = confirmation) is not apparent from names alone.
Destructive/irreversible operations lack explicit marking. google_auth_revoke, smart_send_email, smart_share_file, and smart_create_event all have side effects, but tool metadata does not include destructiveHint or irreversible flags to warn the LLM. Agents cannot distinguish read-only from write operations without inferring from names.
Standardize tool naming. Rename smart_* tools to match verb_noun pattern: smart_send_email → send_email_smart (or drop 'smart' and rely on description to explain auto-resolution). OR explicitly document naming convention: 'smart_ = auto-contact-resolution, prepare_ = confirmation-required'. Update LLM instructions to clarify selection logic.
Add tool annotations for destructive operations. Include in tool metadata: {"destructiveHint": true} for google_auth_revoke, smart_send_email, smart_share_file, smart_create_event, smart_forward_email. Add {"idempotentHint": true} for read-only tools like drive_list_files, drive_get_file.
Enhance error messages with recovery paths. Example: drive_get_file error response should be '{"success": false, "error": "Permission denied on file abc123", "recovery": "Try smart_request_access() first, or search for a shared copy using drive_list_files(query=...)"}'. Every error should suggest a next action.
Add mutual exclusivity documentation. For smart_create_event, clarify that calendar_id and attendees are required, but description and location are optional. Document what happens if attendees list is empty or contains only the creator.
Document file size limits and chunking strategy. drive_get_file should state max_content_size default (1MB) and guidance: 'For files > 1MB, use drive_get_file_chunked(). Call analyze_file_structure() first to determine optimal chunk size.' Add examples for JSON, CSV, and plaintext.
Add success/failure examples to every tool description. E.g., smart_send_email: 'Success returns {success: true, message_id: string}. Failure returns {success: false, error: string, suggestion?: string}' with 1-2 concrete examples.
Clarify processing modes for process_large_json. Document what smart/streaming/sampling modes do: 'smart = intelligent chunking based on structure, streaming = fixed-size chunks, sampling = random sample of records.' Include when to use each.