Skip to main content
Glama

Capable

by run.capable
OverviewDiscussionsAdmin

Find meeting times

find_times
Read-only

Find three meeting times on the host's calendar. Returns 3 slots labeled "1"/"2"/"3" chronologically, each with a pre-formatted rationale; nothing is held yet — propose_meeting places the holds. co_host_emails is for WORKSPACE MEMBERS only, never the invitee (use invitee_timezone); a non-member matching a known contact is dropped (dropped_co_hosts) — relay it. starts_at/ends_at are OPAQUE identifiers: never convert them or do timezone math; quote the rationale verbatim and refer to slots by label. Confirmed times are final: never call find_times again to validate, swap, commit or re-render them (propose_meeting rechecks availability before placing holds); search again only if the user asks for different times or a real conflict is returned. Once times are chosen, confirm topic and agenda once, then call propose_meeting. Modes: FRESH (duration + window); SWAP (current_slots + propose_label) re-picks ONE slot — wait for a yes; COMMIT (current_slots only) finalizes labels. On hosts that render cards reply in one or two sentences, don't list the slots; without a card, list them as bullets from each rationale. Busy overrides, shortfalls, card wording, signed_in_as: capable://guide/scheduling.

When to use: First step of booking a meeting: three labeled candidate slots with pre-formatted local times, nothing held yet. Narrow per call ("mornings only"); swap or commit slots with the same tool.

Example: Find three times for a 30-minute call with Sara next week — mornings only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
window_endYesISO 8601 end of the search window.
duration_minYesMeeting duration in minutes (30, 45, 60, or 90).
window_startYesISO 8601 start of the search window.
current_slotsNoThe 3 currently-committed slots with their labels. Pass with propose_label to swap one, or ALONE to commit a previously-accepted swap. Use the exact starts_at/ends_at values the previous call returned — never reformat them.
propose_labelNoWhich committed slot to re-pick (requires current_slots). Narrow window_start/window_end to the user's hint ("Friday morning" → that day 9–12). Do NOT use this to commit — committing is a separate call with current_slots only.
co_host_emailsNoEmails of WORKSPACE MEMBERS who should also attend — everyone's calendars are intersected so the returned slots work for all hosts. WORKSPACE MEMBERS ONLY — never the external invitee: the invitee's availability is unknown by design (that's why you propose three times). If you know the invitee's timezone, pass invitee_timezone instead.
invitee_timezoneNoIANA timezone of the invitee (e.g. "Europe/Berlin"). When set, every candidate must also fall inside 9–17 Mon–Fri in the invitee's local time. Translate from whatever the user says — a city ("Berlin" → "Europe/Berlin"), a country, an offset — and never infer it from an email domain. Omit when it doesn't matter.
target_starts_atNoExact ISO start for the swap's new candidate (requires current_slots + propose_label). Validated against every constraint; on failure proposed_slot.new is null and target_failure_reason names why — it is never silently substituted.
workday_end_hourNoLatest acceptable hour of day, interpreted in each host's own timezone. When omitted, every host's saved availability end hour applies (default 17). Same rule as workday_start_hour: only for momentary narrowing ("mornings only" → 12).
workday_start_hourNoEarliest acceptable hour of day, interpreted in each host's own timezone. When omitted, every host's saved availability start hour applies (default 9). Pass explicitly ONLY when the user narrows the moment ("book mornings only", "after 2pm" → 14) — it overrides the saved hours for THIS search only and is never persisted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
noteNo
hostsNo
slotsNo
eventsNo
shortfallNo
timed_outNo
duration_minNo
signed_in_asNo
host_timezoneNo
proposed_slotNo
co_host_noticeNo
dropped_co_hostsNo
invitee_timezoneNo
workday_end_hourNo
workday_start_hourNo
visualization_weeksNo
cohost_busy_intervalsNo
availability_blackoutsNo
display_offset_minutesNo
cohost_blackout_intervalsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnlyHint, idempotentHint=false, destructiveHint=false), and the description adds substantial context beyond that: nothing is held yet, co_host_emails is workspace-members-only with silent drops surfaced via dropped_co_hosts, starts_at/ends_at are opaque identifiers that must not be reformatted, and confirmed times are final. Card-vs-no-card reply behavior and the signed_in_as guide pointer further enrich behavioral disclosure.

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?

Purpose and the holds/alternatives constraint are front-loaded, and the block is well-organized into modes, rendering rules, and a guide pointer. It is dense and long for a tool, with some overlap against the already-rich schema descriptions, but the length is largely justified by the three-mode workflow.

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?

For a 10-parameter, three-mode scheduling tool with an output schema, the description covers the full lifecycle: search, swap, commit, the finality of confirmed times, and the hand-off to propose_meeting. With the output schema handling return-shape details, nothing an agent needs to invoke this correctly 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% and the schema itself already documents the mode mechanics, the never-reformat rule, workday hour overrides, and target failure behavior. The description largely reinforces these constraints rather than adding new syntax or semantics, so the baseline 3 for full schema coverage is appropriate.

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+resource (find three meeting times on the host's calendar) and precisely describes the output: three slots labeled "1"/"2"/"3", chronological, each with a rationale. It cleanly separates itself from propose_meeting ('places the holds') and from search/reschedule siblings, so an agent can route without opening another schema.

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

Usage Guidelines5/5

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

Explicitly defines when to call it (first step of booking), when NOT to call it ('never call find_times again to validate, swap, commit or re-render'), and names the alternative (propose_meeting). It also enumerates the three modes (FRESH/SWAP/COMMIT) with their triggering conditions and a worked example, leaving nothing to inference.

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

All Capable toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources