Skip to main content
Glama

Find a time

free_times_find
Read-only

Find when the person is free or available - an open slot for a meeting, a call or an appointment - in every connected calendar: each stretch of a window that no busy time touches and that is at least as long as the meeting. An event holds its time as its provider's own free/busy shows it: on Google unless shown as available or declined - an invitation not yet answered or answered maybe included - on iCloud or a calendar server unless shown free or declined, and on Outlook only when shown busy or away, so an Outlook tentative answer leaves its time free; a cancelled event holds none. An all-day event holding time holds its whole day in the person's own time zone. The search never starts before now, keeps to every preference preferences_get names and to the window's first 365 days and, where the call names them, to hours on each day and to weekdays on top of those preferences; limit keeps the earliest stretches. Once any day has working hours, a day without them is off. The buffers pad the meeting being booked: a stretch starts buffer_before_minutes after busy time ends and ends buffer_after_minutes before the next begins. Each stretch answers once, in time order, with its parts inside the preferred times under preferred. Times, hours and weekdays are in the zone the call names, else the person's own; the stored working hours and preferred times are in the person's own. searched names the window searched and narrowedBy what narrowed it: notice, the least notice from now, rounded up to the quarter hour; horizon, to the end of its last day; yearCap, the 365 days; readLimit, a calendar holding more events than a search reads, read as far as it could be and searched to two days before the last it read; daysOff, days without working hours; fullDays, days already holding the most meetings in a day, a meeting being an event of some length that holds time inside that day's working hours. A calendar or account named under unread was not counted, nor were the calendars past the first 100 of an account under cutShort, so their busy time may fall inside a stretch. An account named under unread as needs_reconnection carries its own row under reconnectAt, where the person, signed in as the same account, presses "Reconnect"; calls to it answer again only once they have.

Input Schema

NameRequiredDescriptionDefault
toYesEnd of the window, excluded, with its offset.
fromYesStart of the window, included, with its offset, e.g. 2026-10-12T09:00:00+01:00.
hoursNoOnly these hours of each day, e.g. 10:00-16:00 or 09:00-12:00, 14:00-17:00.
limitNoAt most this many stretches, the earliest.
minutesNoMeeting length in minutes; the stored one where omitted.
timeZoneNoAn IANA zone such as Europe/London the answer is given in; the stored one where omitted.
weekdaysNoOnly these days of the week.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Annotations cover only safety (readOnly, non-destructive, closed-world), yet the description discloses substantial behavior beyond that: provider-specific free/busy semantics on Google/iCloud/Outlook, tentative/cancelled event handling, all-day event handling, the 365-day cap, buffer padding, and precedence between hours/weekdays/preferences. This is exactly the kind of context annotations cannot carry.

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

Conciseness2/5

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

The opening clause is front-loaded and useful, but the remainder is several hundred words of chained clauses in a single dense block, mixing provider semantics, return-field explanations, and reconnection flows. It is under-structured rather than concise; an agent must parse run-ons to extract callable facts.

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

Completeness4/5

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

With no output schema, the description usefully explains return concepts (searched, narrowedBy, preferred, unread, cutShort, reconnectAt) and the edge cases that make results possibly incomplete. It is substantively complete for a complex calendar tool, though its packaging makes the information harder to use than it should be.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description still adds meaning: limit keeps the earliest stretches, timeZone governs times/hours/weekdays while stored working hours and preferred times stay in the person's zone, and hours and weekdays narrow on top of stored preferences. It loses a point for discussing buffers and other stored settings that are not parameters of this call, which could confuse parameter mapping.

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

Purpose4/5

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

States a specific verb and resource: find free/available stretches across every connected calendar, long enough for the meeting. It is clear what the tool returns, but it never names or contrasts with the obvious sibling circles_free_times_find (or busy_everywhere_set), so sibling differentiation is left to inference.

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

Usage Guidelines3/5

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

Usage is implied ('an open slot for a meeting, a call or an appointment') and several constraints on the search are given (never starts before now, honors preferences_get, 365-day cap). But there is no explicit when-to-use-this-vs-alternative guidance and no exclusions, so an agent still has to infer when to pick this over circles_free_times_find.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.