Skip to main content
Glama

Find a time

free_times_find
Read-only

Find when the person is free 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 - 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 needing reconnection is reconnected at https://lumman.co/mcp/account/multi-calendar.

Input Schema

TableJSON 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

A4.1/5.0
Behavior5/5

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

Annotations only declare this as a safe read (readOnlyHint=true, destructiveHint=false), and the description goes far beyond them: provider-specific free/busy interpretation (Google vs Outlook tense answers, cancelled events, all-day events), buffer padding semantics, the narrowedBy reasons (notice, horizon, yearCap, readLimit, daysOff, fullDays), and warnings that unread/cutShort calendars may still hold busy time. It even supplies a reconnection URL for accounts needing reauth.

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

Conciseness3/5

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

The first sentence is well front-loaded and most content is substantive rather than filler, which earns credit. But the body is an extremely dense, run-on block of semicolon-chained clauses and nested qualifiers that is hard to parse, and it is very large for an agent to consume before acting.

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

Completeness5/5

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

There is no output schema, so the description carries the return-value burden and does: 'Each stretch answers once, in time order, with its parts inside the preferred times under preferred,' plus a full inventory of narrowedBy reasons and the searched window. Nothing needed to interpret the result is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description mostly restates schema content (limit = earliest stretches, hours = only these hours) but does add the zone-resolution rule (times/hours/weekdays use the named zone, stored working hours and preferred times use the person's own). Net value over the structured fields is marginal.

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 with scope: 'Find when the person is free 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 agent can tell this computes free slots rather than listing events. However, it never differentiates itself from the obvious sibling circles_free_times_find, so the 'every connected calendar' framing is the only (implicit) distinguishing signal.

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?

Gives concrete usage constraints: the search never starts before now, honors preferences_get, is capped at the window's first 365 days, and narrows by hours/weekdays. It does not, however, explicitly state when to prefer it over circles_free_times_find, so routing between the two free-times tools is left to inference.

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.

Resources