Google Calendar

Latency varies significantly by operation type. Read operations like list-colors and get-current-time complete in 195-261ms. Event retrieval operations (get-event, delete-event) run 343-421ms. More complex operations take longer: list-events at 550ms, get-freebusy at 602ms, and search-events at 823ms. Write operations are slowest, with create-event at 1212ms, create-events at 1295ms, and update-event taking 1365ms.

Our testing used calendar and calendar.events scopes, which provided access to all 12 executed operations. These scopes enabled reading calendar lists, managing events, checking availability, and performing searches. The calendar scope covers calendar metadata and color information, while calendar.events handles event creation, modification, deletion, and querying operations including free/busy status checks.

create-event for individual events completed in 1212ms during our tests. The create-events tool for batch operations took 1295ms, showing only an 83ms overhead for handling multiple events simultaneously. This minimal performance difference makes batch creation efficient when adding multiple events, though we did not test the specific number of events processed in the batch operation.

search-events took 823ms to complete while list-events required 550ms, showing a 273ms performance penalty for search functionality. Both operations executed without errors in our sandbox environment. The search operation provides more targeted results but requires additional processing time compared to straightforward event listing from calendar sources.

One tool was skipped due to write-dangerous classification during our testing. All other discovered tools (12 total) executed successfully without policy restrictions, paid feature limitations, or sandbox environment constraints. The skipped tool was not executed due to test-environment limitations rather than server capability issues.

update-event was the slowest operation we measured at 1365ms, taking 153ms longer than create-event at 1212ms. Event updates require additional processing to modify existing calendar entries compared to creating new ones. Both operations completed successfully without errors, but updates consistently require more processing time than initial event creation.

list-colors provided the fastest response at 195ms, followed closely by get-current-time at 233ms and manage-accounts at 235ms. These metadata and configuration operations complete much faster than event-related operations. For quick calendar setup or configuration checks, these tools offer the most responsive performance in the tested environment.