All 12 tools follow a repetitive pattern (list_resources, read, search) across 4 connectors. Naming is verb-first and consistent, but descriptions are minimal (15-20 chars) and lack context for LLM selection. Input schemas are present with basic types and descriptions, but output schemas are completely undocumented. No error handling guidance, no pagination info, no chaining IDs returned. Parameter descriptions are generic ('The user ID', 'The resource ID') without format constraints or examples of valid values. Tools appear to be dynamically registered via a factory pattern, making it difficult to verify actual schema compliance in the source.

• Expand tool descriptions to 80 - 150 characters. Example: 'List all Gmail messages accessible to this user. Call this first to discover available emails before reading or searching. Returns message IDs, subjects, and timestamps.'
• Document output schemas explicitly. For gmail_read, specify: {id: string, subject: string, from: string, date: ISO8601, body: string, attachments: [{filename, size}]}. For list_resources, specify: {total: int, items: [{id, name, created_at}]}.
• Add pagination to list_resources and search. Accept limit (1 - 100, default 20) and offset parameters. Return {items: [...], total: int, has_more: bool, next_offset: int}.
• Enhance parameter descriptions with format and constraints. Example: 'user_id (string, format: email or UUID, required): The Gmail account owner's email or internal user ID. Obtain via search_users() if unknown.'
• Add error handling documentation. Specify: 'Returns 404 if user_id not found (call search_users to verify). Returns 403 if user lacks Gmail access (check OAuth scopes). Returns 500 on service outage (retry after 30s).'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry