Skip to main content
Glama
deciduus
by deciduus

Detect calendar conflicts

detect_conflicts
Read-onlyIdempotent

Identify double-booked events and tight scheduling transitions across all connected accounts in a specified time window, flagging genuine overlaps and buffer violations to prevent impossible days.

Instructions

Find double-booked events in a window, across every signed-in account.

Reports two things. conflicts are genuine overlaps -- the user cannot be in both places. tight transitions do not overlap but leave less than the buffer from get_preferences, which is what makes a day feel impossible.

Events the user declined, events marked free, cancelled events and (unless include_all_day is set) all-day events are ignored, because none of them actually occupy the user.

Args: time_min: Start of the window to check, ISO 8601. time_max: End of the window to check, ISO 8601. accounts: Account names to check. Omit for every signed-in account, which is the point of the tool -- a work meeting clashing with a personal one is invisible from either calendar alone. calendar_ids: Restrict to these calendars (in every account checked). Omit for each account's selected calendars. include_all_day: True to let all-day events clash with timed ones. max_events_per_calendar: Safety limit per calendar. Default 250.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountsNo
time_maxYes
time_minYes
calendar_idsNo
include_all_dayNo
max_events_per_calendarNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tightNoBack-to-back pairs that violate the buffer, earliest first.
messageNoOne-line human-readable summary.
skippedNoCalendars or accounts that could not be read in full, with the reason.
accountsNoAccounts that were read.
time_maxYesEnd of the checked window, ISO 8601.
time_minYesStart of the checked window, ISO 8601.
timezoneYesTimezone the times are expressed in.
conflictsNoOverlapping pairs, earliest first.
event_countNoEvents considered after filtering.
tight_countNoNumber of too-tight transitions.
calendar_idsNoCalendars that were read, as 'account:calendar_id'.
buffer_minutesNoBuffer the tight transitions were judged against.
conflict_countNoNumber of overlapping pairs.
include_all_dayNoWhether all-day events were considered.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. Description adds further behavioral detail by explaining which event types are excluded and the cross-account nature. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, but slightly repetitive (the 'which is the point of the tool' phrase appears twice) and some redundancy in parameter explanations. Overall clear and not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input parameters and behavior thoroughly, but does not describe the output format beyond 'reports two things'. Since no output schema is provided, an agent may need more details on how conflicts and tight events are returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has zero parameter descriptions, but the Args section in the description provides meaningful explanations for every parameter, including defaults and the purpose of accounts/calendar_ids filtering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('find') and resource ('double-booked events') with scope ('across every signed-in account'). Clearly differentiates from generic search tools like find_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the tool's role and what it reports (conflicts vs. tight), and what events are ignored. Does not explicitly state when to prefer it over alternatives like query_free_busy, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.