Reassign: a circular 24-hour calendar and time-tracking copilot with ADHD-friendly scheduling.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 14 of 14 tools scored.
Each tool targets a distinct operation: reading (get_schedule, find_event, get_energy, get_weather, show_day), scheduling (schedule, confirm_schedule), event editing (write_events, delete_events), backlog management (manage_backlog), category management (manage_categories), reflection (review_day), undo, and feedback. The boundary between schedule and write_events is explicitly clear (exact times vs. conflict-free search), and get_schedule vs. show_day are differentiated by text vs. visual presentation. The only minor ambiguity is that manage_backlog includes a 'schedule' op, but that's internal to the tool.
All but two tools follow verb_noun snake_case: confirm_schedule, delete_events, find_event, get_energy, get_schedule, get_weather, manage_backlog, manage_categories, review_day, send_feedback, show_day, write_events. The exceptions are 'schedule' and 'undo', which are bare verbs and thus slightly break the consistent pattern.
14 tools is well-scoped for a comprehensive scheduling assistant: read surfaces, write surfaces, assisted scheduling, backlog/category management, reflection, undo, weather/energy, and feedback. Each tool covers a distinct capability, and none feels redundant. Only the extra weather and energy getters could arguably be merged with get_schedule, but they serve specific use cases.
The tool surface covers the full lifecycle: create (schedule, write_events), read (get_schedule, find_event), update (write_events, manage_backlog, manage_categories), delete (delete_events, review_day discard), plus undo and confirmation flows. There are no obvious dead ends or missing CRUD operations for the scheduling domain. Weather and energy are bonuses that support informed scheduling decisions.
confirm_scheduleConfirm proposed timesAInspectConfirm — accept a proposal, pick an option, commit — one or more times that schedule proposed. Pass items, each a token (the commitToken) and optional choice (0-based index into that proposal's options; defaults to the first/best). Each is re-checked for conflicts before writing — a slot taken meanwhile is reported as an error with a prompt to re-run schedule. Returns per-item results.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| render | No | When the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which show this is not read-only, not destructive), the description discloses important behavioral traits: each item is 're-checked for conflicts before writing', a slot taken meanwhile is 'reported as an error with a prompt to re-run schedule'. This adds genuine value beyond the annotations by explaining the write-time validation behavior and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then parameter mechanics, then conflict-check behavior. Every sentence adds value — no filler, no repetition of what annotations already say. Well structured from purpose to mechanics to edge-case handling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and moderate annotation coverage, the description explains the input mechanics, the write-time validation behavior, and the error handling scenario. It also covers the meaning of token and choice. It could add what exactly appears in `results`, but overall it's fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — the item-level properties are documented, but `render` is the undocumented half. The description explains the token and choice semantics well (token is commitToken, choice is 0-based index, defaults to first/best). However, the `render` parameter's purpose is only in the schema and not reinforced in the description, and the description doesn't fully clarify that the conflict check behavior is what distinguishes this from just writing events.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Confirm' with the specific resource ('proposed times from schedule') and explains the mechanics (pass items with token and choice). It distinguishes itself from the sibling 'schedule' tool by explicitly referencing what schedule proposed and how confirmation works.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the when-to-use context implicitly by referencing that these are times 'schedule proposed' and how choosing among options works. It doesn't explicitly name alternatives or state when NOT to use it, but the sibling context (schedule, undo) makes the usage scenario reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_eventsDelete eventsADelete events or clear whole days — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (delete | clear): delete removes one event by id (for a recurring event set scope 'all' (default) / 'future' / 'this' with occurrenceDate); clear removes everything on a day (or a date..to range). By default the whole batch is atomic: if ANY op fails, nothing is removed; pass partial: true for best-effort. Every removal is reversible — the response returns an undoToken (call undo within 30 minutes). If the user has a Google Calendar connected, deleting a calendar-linked event also removes it from Google — the same as deleting on the dial; an event get_schedule/find_event marks readOnly is from a calendar the user doesn't own and can't be deleted this way. It reports applied, failed, skipped, and per-op results (each with its 0-based index). To create or edit events use write_events.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | ||
| render | No | When the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. Otherwise the change reaches an open dial only if the host forwards this result. | |
| concise | No | Drop the human-readable `suggestedFollowup` prose from the response (the structured `undoToken` is still returned). Saves tokens. | |
| partial | No | Best-effort mode: apply the ops that succeed and report the rest as errors, instead of the default all-or-nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and readOnlyHint=false, and the description adds substantial behavior beyond this: atomic batch semantics by default, partial:true for best-effort, reversibility via undoToken within 30 min, Google Calendar propagation side-effects, and the readOnly detection mechanism. It also discloses return structure (applied/failed/skipped/results). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-organized single paragraph covering operations, variants, atomicity, reversibility, calendar caveats, and return format. Every sentence conveys meaningful guidance, but the paragraph is long; front-loading purpose and op structure is good, with behavioral caveats at the end. Could benefit from slight structural splitting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a destructive mutation tool with good annotations and detailed schema (75% coverage). Covers atomic behavior, undo, Google Calendar integration, recurring scope, readOnly limitation, and return format. No output schema, so it accurately describes what results to expect. The 4-param schema with 1 required makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description compensates for the uncovered quarter by explaining the ops array structure, op variants (delete/clear), recurring scope values ('all'/'future'/'this') with occurrenceDate, and date ranges. It clarifies partial, render, and the batch semantics of ops. Some param details (concise) are left to schema descriptions, which is acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource ('Delete events or clear whole days') and clearly distinguishes delete vs clear operations. It differentiates from sibling write_events (create/edit), undo (reversal), and find_event/get_schedule (read/localization). Scope handling for recurring events and Google Calendar caveats make purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not guidance: readOnly events from non-owned calendars 'can't be deleted this way', and directs creation/editing to write_events. Explains partial vs atomic modes, recurring-event scope options, and undo availability window with a clear 30-minute window. Also names sibling tools get_schedule/find_event for context on readOnly detection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_eventFind eventASearch for, look up, or locate SCHEDULED events by name when you don't have an id — fuzzy, case- and accent-insensitive. (For an un-timed parked/backlog item, search get_schedule's backlogQuery instead — those aren't events.) Searches the past week through the next 30 days by default; pass from/to (ISO "YYYY-MM-DD", e.g. "2026-06-01") to widen or shift the window, and optionally filter by areaId, activityTypeId, or timeOfDay. Returns the best matches as { id, date, start, end, name, area, activityType } rows (one per event), each also carrying its source and, when calendar-linked, its calendar name and readOnly flag (a read-only event lives on a calendar the user doesn't own — don't edit or delete it). When two different events tie, ambiguous is true — ask the user which they meant. Two days of the same recurring event are not ambiguous.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Range end, ISO date, e.g. "2026-07-01". Defaults to +30 days. | |
| from | No | Range start, ISO date, e.g. "2026-06-01". Defaults to 7 days ago. | |
| query | Yes | Text to match against event names, e.g. "standup", "gym". | |
| areaId | No | Only match events linked to this area id. | |
| timeOfDay | No | Only match events starting in this part of the day. | |
| activityTypeId | No | Only match events linked to this activity-type id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint=true annotation: it explains the readOnly flag returned on calendar-linked events and explicitly warns the agent not to edit or delete read-only events. It also discloses the ambiguous-match behavior and how recurring events are handled. The annotation confirms read-only nature; the description enriches with the not-all-events-ambiguous detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the core purpose and search semantics, then flows to window control, filters, return format, and edge cases. Some sentences are long (especially the return-format one), but every sentence earns its place, covering purpose, usage, exclusions, parameters, output shape, and caveats without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 6 parameters and no output schema, the description is thorough: it explains the search behavior (fuzzy, case/accent-insensitive), the default and shifted time windows, all filter options, the exact return row shape, the readOnly/calendar semantics, and ambiguity handling. It fully compensates for the absence of an output schema by spelling out the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented in the schema. The description adds value by explaining the 'ambiguous' return behavior tied to multi-event matches and clarifies the from/to defaults (7 days ago / 30 days out) with concrete ISO examples, which supplements the schema's default descriptions. The filters (areaId, activityTypeId, timeOfDay) are listed but not deeply elaborated since the schema covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs (search, look up, locate) tied to a clear resource (SCHEDULED events by name) and explicitly distinguishes this from siblings by stating it's for when you don't have an id, contrasting with get_schedule for backlog items. It clearly differentiates from sibling tools like manage_backlog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (searching events without an id) and when NOT to use it (parked/backlog items should use get_schedule's backlogQuery instead). It also details the default search window (past week through next 30 days) and how to widen it, plus available filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_energyGet energy curveAGet the user's forecast energy curve for a day, to schedule by their alertness: focus/deep work in a peak, admin/errands in the afternoon dip. Built from their logged sleep (+ tracked caffeine), personalized from energy levels they log. get_schedule and show_day don't include energy, so use this when energy matters or the user asks about it. Defaults to today; pass date (ISO YYYY-MM-DD) for another day. Returns a compact overview (peak + dip windows, today's current level, calibration state), not an hourly dump. Needs at least one logged night of sleep; with none it returns a short nudge to log sleep first.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The day to read, ISO "YYYY-MM-DD". Defaults to today. A future day forecasts from the user's habitual sleep; a past day reflects their actual logged sleep where recorded, but energy itself is modeled, not measured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is covered. The description adds valuable context beyond that: the return format ('compact overview of peak + dip windows, today's current level, calibration state, not an hourly dump'), the personalization basis (sleep + caffeine + logged energy levels), the empty-state behavior (nudge to log sleep), and the distinction between future (habitual forecast) vs past (actual logged sleep via schema). This is rich 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all substantive, front-loaded with the core purpose. The description is efficient but packs in purpose, differentiation, return format, defaults, and edge-case behavior. Slightly dense but earns each word; minor point off for the length relative to what could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, single-parameter tool with no output schema, this description is complete: covers when to use, what it returns, default behavior, prerequisite failure mode, and personalization source. No output schema increases the burden to describe the return shape, which it does (compact overview, peak/dip windows, current level, calibration state). Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds meaning: 'Defaults to today' and 'pass date (ISO YYYY-MM-DD) for another day.' The schema itself also carries strong semantics about future vs past day behavior. Combined, parameter meaning is well-covered with description reinforcing the key default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Get the user's forecast energy curve') and its purpose (scheduling by alertness). It explicitly distinguishes from siblings: 'get_schedule and show_day don't include energy, so use this when energy matters or the user asks about it.' This is specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'use this when energy matters or the user asks about it', names alternatives (get_schedule, show_day) and why they fall short. Also covers the default (today) and prerequisite condition ('Needs at least one logged night of sleep; with none it returns a short nudge to log sleep first').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scheduleGet scheduleARead the calendar — the day's agenda, what's on, how busy you are, your availability, an overview of a day or week, where your time goes. Returns, in one call, everything needed to reason about the plan: the current time (now), the user's areas and activityTypes, userPreferences, and a days array (each day's events, free slots, and how its time splits across areas/types — blocking load and any non-blocking overlay load reported separately). Call it before scheduling to anchor relative times ('this afternoon'). Defaults to today; pass date for another single day, from+to for an inclusive range, or dates for a specific set (ISO YYYY-MM-DD). Pass compact: true to shrink events for wide ranges, or includeSeries: true to also get recurring masters as series. Each event carries its source ("reassign", else a provider like "google") and, when calendar-linked, its calendar name; an event with readOnly: true is on a calendar the user doesn't own — don't edit or delete it (tell them to change it there). kind is omitted for a normal blocking event; "non-blocking" is an overlay that may overlap others (fasting, an away marker); "reference" is see-only — its hours stay free, don't move/delete/schedule work into it unless asked. A confirmed past day carries a review adherence rollup plus per-event reflect actuals (an unreviewed day has neither) — use it for how a day or week actually went. When a calendar is connected, integrations describes it (connected sources + their calendars, classification fallbacks, and the default sync target); omitted otherwise. For a single day, a one-line weather headline is included when the user has a city — call get_weather only for hourly detail. backlogCount reports how many parked blocks (the inbox of un-timed intentions) the user has; pass includeBacklog: true for the items (top of tray first, up to 50) or backlogQuery to find one by name — place/manage them with manage_backlog. Times are in the user's timezone; an untitled event shows as "(untitled)".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| date | No | ||
| from | No | ||
| dates | No | ||
| compact | No | ||
| backlogQuery | No | Filter the parked blocks by name (fuzzy, case/accent-insensitive) — e.g. "dentist". Implies includeBacklog; use it to FIND a specific parked block by name instead of paging the whole inbox. | |
| includeSeries | No | ||
| includeBacklog | No | Include the parked-block items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their inbox. | |
| backlogPlannedOn | No | Filter the parked blocks to those PLANNED for this day (a block's planned day, or a planned window covering it) — e.g. today's date to answer "what did I plan to get to today?". Implies includeBacklog; composes with backlogQuery. Overdue blocks carry `overdue: true` on the unfiltered read instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces a non-mutating read posture. Beyond that, it discloses rich behavioral detail: events carry source/calendar, readOnly events shouldn't be edited, kind semantics (blocking vs non-blocking vs reference) with specific 'don't move/delete/schedule work into it unless asked' instructions, past-day review/reflect actuals, and integrations behavior. It thoroughly explains the return envelope, though it stops short of describing output types/schemas (no output schema exists, so this is a strong disclosure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative, front-loading the core purpose and enumerating the return fields before parameter guidance. It earns each sentence by adding behavioral or usage context rather than restating the schema. It borders on the verbose side for agents scanning quickly, which is why it doesn't reach 5, but there is essentially no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only calendar accessor with 9 parameters and no output schema, this description is unusually complete. It covers the date-selection modes, payload-enrichment flags, event semantics (kind/source/readOnly), review/reflect behavior, integrations, weather, timezone, and backlog availability. Every meaningful behavior an agent needs to invoke and interpret the result is addressed, leaving no material gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate for undocumented parameters, and it does well. It explains date-selection modes (date/from+to/dates as ISO YYYY-MM-DD), compact, includeSeries, includeBacklog, and backlogQuery semantics. However, backlogPlannedOn is only explained in the schema, not in the description, and the description is slightly weaker on the exact inter-relations of the filter parameters beyond what the schema notes — still, it adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read the calendar' — a specific verb+resource — and enumerates exactly what it returns: now, areas, activityTypes, userPreferences, and a days array with events, free slots, and time splits. It clearly distinguishes from siblings like get_weather and manage_backlog by stating what is NOT covered ('call get_weather only for hourly detail', 'place/manage them with manage_backlog').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use it: 'Call it before scheduling to anchor relative times'. It gives clear guidance on when NOT to use it ('call get_weather only for hourly detail') and names the alternative tool for hourly weather. It also states usage for review ('use it for how a day or week actually went') and when backlog management belongs to manage_backlog instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_weatherGet weatherAGet the weather forecast for a day, for scheduling around it. Use ONLY for outdoor or weather-sensitive plans (exercise, commute, travel, anything outside) or when the user explicitly asks about the weather — indoor plans don't need it. get_schedule and show_day already include a one-line weather headline for the day, so prefer that for a quick glance and reach for this only when an outdoor plan needs the hourly detail (e.g. the exact dry/daylight window). Defaults to today and the user's city; pass date (ISO YYYY-MM-DD) for another day, or location (a city/place name) to ask about somewhere else. Returns a compact day overview (condition, temp range, rain window, daylight) plus a part-of-day breakdown — not an hourly dump.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The day to forecast, ISO "YYYY-MM-DD". Defaults to today. Open-Meteo covers ~16 days ahead; far-future/far-past days have no hourly data. | |
| location | No | A city/place name to forecast instead of the user's own city, e.g. "London" or "Tahoe". Omit to use their saved (or timezone-guessed) city. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context: the ~16 day forecast horizon, the return shape (compact day overview plus part-of-day breakdown, explicitly NOT an hourly dump), and the default behavior (today, user's city). These add real value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably sized for the functionality covered and front-loads the core purpose. It packs substantial guidance (usage, alternatives, defaults, return shape) into a compact form. Slightly dense in the middle section but every sentence earns its place—nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with two optional parameters, full schema coverage, and clear annotations, this description is complete. It covers what the tool does, when to use it, what it returns, defaults, parameter specifics, and limitations (16-day horizon). No material gaps for an agent to make wrong decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by explaining defaults (today, user's city), the date pattern with the 16-day forecast limitation, and the location semantics (overrides saved city). It clarifies parameter behavior beyond the raw schema, though much is already documented well in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a weather forecast tool for a specific day, with a strong verb+resource structure ('Get the weather forecast for a day'). It distinguishes itself from siblings by explicitly noting that get_schedule and show_day already include a one-line weather headline, making the specific purpose (hourly/part-of-day detail for outdoor planning) clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('outdoor or weather-sensitive plans', 'when user explicitly asks about weather') and when-not-to-use guidance ('indoor plans don't need it'). Names specific alternatives (get_schedule, show_day) and explains when to prefer those instead, plus guidance on the date/location parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_backlogManage backlogAWrite to the backlog — the inbox of PARKED time-blocks: intentions captured without a time yet ("wash the car", "call the dentist"). To READ parked blocks, use get_schedule (backlogCount, then includeBacklog: true for the items or backlogQuery to find one by name); THIS tool is the write surface. Pass ops, an array where each item has an op plus its fields — one or many in a single call, atomic by default (if any op fails nothing is written; pass partial: true for best-effort). Ops: capture creates a parked block (name, optional notes/durationHours, area/activityType by id or name, and an optional plannedDate or plannedDate+plannedUntil window — the still-untimed day(s) it's meant for; pass enrich: true for RAW captured text, e.g. a web-page selection, to have AI propose a readable name and a duration first — never for a name the user chose); update edits one by id (plannedDate: null moves it back to Someday; a task-app-linked block's date is provider-owned and refused); remove deletes one by id (reversible — the response returns an undoToken); schedule PLACES a parked block on the dial at date+start (its duration sizes it; pass recurrence to make it repeat) and removes it from the inbox; park MOVES a dial event (by eventId) back into the inbox. Park only works on a native or owned-calendar one-off that hasn't been reviewed — a recurring, sleep, reviewed, or not-owned event is refused with a reason (edit it on the dial instead). Parking a calendar-linked event removes its calendar copy but remembers the calendar, so re-scheduling it republishes there. Backlog is a Pro feature. schedule and park are inverses: to undo a schedule, park it again, and vice-versa.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | ||
| partial | No | Best-effort mode instead of the default all-or-nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already provide destructiveHint=true, the description adds substantial behavioral detail: atomicity by default, partial mode, undoToken for remove, calendar-copy preservation for park, refusals for provider-owned/recurring/sleep/reviewed events, and Pro-feature gating. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense, front-loading the purpose and covering all ops with valuable caveats. Each clause adds operational information, though the single-paragraph format could be more scannable with bullet points; still, it is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers prerequisites (Pro feature, native/owned one-off), side effects (removes from inbox, clears calendar copy, undoToken), error/refusal conditions, and atomicity/partial behavior. With no output schema, the description still provides enough return-value hints (undoToken, refusal reasons) for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, but the description compensates by explaining each op's fields and behavior—plannedDate: null moves to Someday, enrich is for raw captures only, recurrence options, and area/activityType by id or name. It also clarifies the partial flag's meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by identifying the tool as the write surface for the backlog ('Write to the backlog') and lists all five operations (capture, update, remove, schedule, park). It explicitly contrasts itself with get_schedule ('To READ parked blocks, use get_schedule... THIS tool is the write surface'), making its purpose and scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear when-to-use guidance: read via get_schedule, write via this tool, and states that schedule and park are inverses. It also gives exclusions—e.g., park only works on native/owned one-offs that haven't been reviewed, with 'edit it on the dial instead' as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_categoriesManage categoriesACreate, update, or delete areas (categories / groups / colour-coded labels) and activity types (tags / fill patterns) — one or many in a single call. Pass areas and/or activityTypes, each an array of ops: {op:"create", name, color?} / {op:"update", id, name?, color?} / {op:"delete", id, reassignTo?} for areas; pattern instead of color for activity types (valid patterns: solid, hatch-r, hatch-l, cross, horizontal, vertical, grid, dots, waves, chevron). Colours are 6-digit hex; omit to auto-pick. Editing a shared global default forks it into your own copy, so the returned id may differ — each result reports the effective id (and forkedFrom). Delete only your own (non-global) entries; if events still use one, pass reassignTo (another id) to move them first. Names are deduplicated case- and whitespace-insensitively: creating one that matches an existing area/type is rejected (reuse the existing id instead). A delete returns an undoToken. Atomic by default: if any op is invalid nothing is written; pass partial: true for best-effort. Create areas/types here first, then reference the returned ids in write_events.
| Name | Required | Description | Default |
|---|---|---|---|
| areas | No | ||
| partial | No | Best-effort mode instead of the default all-or-nothing. | |
| activityTypes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true already in annotations, the description adds substantial value: atomicity by default with partial:true option, deduplication behavior on names, forking behavior for shared globals (returned id may differ, forkedFrom field), undoToken on delete, and restriction to deleting only non-global entries. This meaningfully extends beyond the annotation's bare safety flag. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but organized: it opens with the core action, then systematically covers operations, validation (patterns, colors, dedup), delete constraints, atomicity, and workflow linkage. It's longer than ideal but every sentence carries meaningful information with no filler — appropriate for a complex multi-mode tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two object types, three operations each, maxItems constraints from schema, no output schema), the description covers nearly all operational behavior: dedup rules, forking, atomicity, delete safeguards, and downstream usage in write_events. Minor gaps like exact response shape and what undoToken does aren't specified, but the agent has enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must carry significant weight — and it does. It explains the op enum pattern ({op:'create'|'update'|'delete'}), the color vs pattern difference between areas and activity types, valid pattern values, 6-digit hex color format, auto-pick on omission, reassignTo semantics, and the partial flag. This substantially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool creates, updates, or deletes areas and activity types, with specific verbs and resources. It distinguishes itself from write_events (referenced explicitly: 'Create areas/types here first, then reference the returned ids in write_events') and sibling tools like manage_backlog and delete_events, making its scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong usage context: create first then reference ids in write_events, delete only own non-global entries, use reassignTo when events still use an entry. It doesn't explicitly contrast against sibling tools that might overlap, but the contained guidance is thorough for setup-before-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_dayReview a past dayAConfirm or discard a whole PAST day's reflection (by date, ISO YYYY-MM-DD), once you've marked its events with write_events' reflect op. action:"confirm" marks the day reviewed — "this is how it went" — freezing a per-day adherence snapshot (how closely actuals matched the plan, with per-area/per-type breakdowns) onto a dayReviews row, which is what get_schedule then surfaces as that day's review block and what the stats use; re-confirming refreshes it. action:"discard" fully resets the day: it deletes that row, clears the kept/skipped/changed marks + actual times off the day's planned events, and removes events ADDED only as part of the reflection — use it to start a day's reflection over or drop one confirmed by mistake. Only a past day can be reviewed; a day too far back for the user's plan is rejected. Reversible: the response returns an undoToken (call undo within 30 minutes).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| action | Yes | "confirm" freezes the day's adherence snapshot; "discard" fully resets the day's reflection (deletes the marker, clears every mark). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite destructiveHint=true annotation being present, the description adds substantial behavioral detail: it explicitly lists what discard deletes (the row, marks, actual times, reflection-added events), what confirm freezes (adherence snapshot, dayReviews row), that re-confirming refreshes, and that it's reversible via undoToken within 30 minutes. This far exceeds what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, well-organized with comma-separated clarifications. Every sentence adds functional information (what confirm does, what discard does, constraints, reversibility). It's appropriately sized for a tool with two distinct actions each having complex effects, though the long first sentence could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with destructive annotatons and no output schema, the description is very complete: it covers both actions' full effects, prerequisites (write_events reflect op), constraints (past day, must be within plan range), side effects on get_schedule and stats, and reversibility via undoToken. Nothing critical is missing for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the action param has a description in the schema, but date has none. The description explains date is ISO YYYY-MM-DD and only past days, and explains the action enum values in depth ('confirm freezes adherence snapshot', 'discard resets'). This adds value beyond schema for action but only mildly for date. Baseline 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Confirm or discard a whole PAST day's reflection (by `date`...)'. It distinguishes from siblings by noting it works on a whole day's reflection, uses the date param, and is different from write_events which marks individual events. The two actions (confirm/discard) are clearly explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use it: after marking events with write_events' reflect op. It states constraints (only past days, days too far back rejected). However it doesn't explicitly name alternatives or say when NOT to use it, though it references write_events as the prerequisite marking step, implying differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scheduleSchedule into free timeAInspectFind conflict-free time and place one or more events — the easiest way to book work without computing slots yourself. (If you already know both an exact start AND end, use write_events create instead.) YOU resolve any relative phrasing ("tomorrow", "next monday", "this afternoon") into the structured fields; this tool does no date parsing. Pass requests, each with a name, duration ("90m", "1h30", "2h"), a date (ISO "YYYY-MM-DD"), and EITHER an exact start ("HH:MM", 24-hour) to place there, OR an earliest/latest ("HH:MM") window to search within (map "afternoon" → earliest "13:00", latest "18:00"), OR neither to search the whole working day. For each request: if exactly one conflict-free time fits it is created immediately with an undoToken; otherwise you get ranked options and a commitToken — call confirm_schedule to pick one (or set autoCommitBest: true on a flexible request to book the top pick in one shot and skip that round-trip). Requests are placed in order and kept off each other's committed slots. Each request may carry a request_id so retries don't double-book. If the user has a Google Calendar connected with a default sync calendar, a scheduled event is also pushed to Google, the same as a dial create. The response reports per-request results (each with its 0-based index).
| Name | Required | Description | Default |
|---|---|---|---|
| render | No | When the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. | |
| requests | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining key behaviors: it does no date parsing (agent must resolve relative phrases), places requests in order, prevents overlaps, pushes to Google Calendar under certain conditions, and returns `undoToken`/`commitToken`/`options` per request. This adds substantial context beyond the minimal `readOnlyHint:false`/`destructiveHint:false`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, it is dense and front-loaded with the purpose, then alternates usage rules, parameter semantics, and response notes. Every sentence contributes a distinct piece of operational guidance, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description responsibly mentions the response shape (`results`, `undoToken`, `commitToken`, `options`) and the 0-based indices. It covers the main flows (immediate vs options, autoCommit, idempotency) and side-effects (Google sync), so an agent can invoke and interpret results confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the crucial parameter interactions: `start` vs `earliest`/`latest` vs none, gives concrete duration examples ('90m', '1h30'), maps relative phrases to times, and covers `request_id` idempotency and `autoCommitBest` behavior. However, it omits some parameters like `kind`, `recurrence`, and `render`, leaving that to schema descriptions, so it doesn't fully compensate for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb+resource is explicit: 'Find conflict-free time and place one or more events', clearly indicating a scheduling/book-writing action. It also distinguishes itself from the sibling `write_events` for exact start/end, so the agent knows what makes this tool special.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions itself as the alternative to hand-computing slots ('easiest way to book work without computing slots yourself') and points to `write_events create` when exact start and end are known. It also gives conditional guidance on `autoCommitBest` (one-shot routine bookings vs review-before-commit), providing clear when-to/when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend feedbackAInspectReport a bug, limitation, friction, or idea about reassign itself — its tools, their results, or this MCP integration — to the product team, who read every message. Covers errors, confusing or wrong results, retries or workarounds, loops, and rough edges that could be smoother, plus feedback the user asks to send. This is meta-feedback ABOUT the product, not a way to change the schedule (use write_events for events). kind is "bug" | "idea" | "other". In message, describe what you tried, what happened, what you expected, and any event ids or steps to reproduce; send one concise report per issue rather than repeating it. Describe the problem in your own words — don't paste the user's personal details or private schedule contents; their account is attached automatically for follow-up.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Type of feedback: "bug" for something broken or wrong, "idea" for a suggestion or feature request, "other" for anything else. | |
| message | Yes | The feedback itself. For a bug, say what happened, what you expected, and any event ids or steps that reproduce it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint:false, destructiveHint:false, which don't clarify much for a feedback tool. The description compensates by disclosing key behaviors: the user's account is attached automatically for follow-up, every message is read by the team, and privacy guidance about not pasting personal details or private schedule contents. This is valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a solid paragraph that front-loads the purpose and packs in usage guidelines, privacy, and content requirements efficiently. It's somewhat long but every sentence adds meaning—purpose, exclusions, content guidance, and privacy. No wasted words, though it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with no output schema and full schema coverage, the description is thorough: it covers purpose, usage boundaries, content quality, privacy, and expected outcomes (account attached, read by team). It fully equips an agent to decide when and how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters fully (kind enum values and message requirements). The description adds marginal value by reinforcing the content guidance for message (what to include, one issue per report), but the schema already carries most of the parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends meta-feedback about the reassign product itself (bugs, ideas, limitations, friction) to the product team. It explicitly distinguishes from schedule-changing tools with 'not a way to change the schedule (use write_events for events)', providing excellent sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance (reporting bugs, limitations, friction, ideas about the product) and explicit when-not-to-use (not for scheduling changes, pointing to write_events). It also gives clear content guidance: describe what tried, what happened, what expected, event ids, steps to reproduce, and send one report per issue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_dayShow day on the dialARender the user's day as the interactive 24-hour reassign dial, right in the conversation — use it whenever they want to SEE their day, their schedule laid out, how full it looks, or to visually move things around. Defaults to today; pass date (ISO YYYY-MM-DD) for another day. For reading or reasoning about the plan in text, prefer get_schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, so the agent already knows this is a read-only, closed-world operation. The description adds that it 'Defaults to today' and renders 'right in the conversation,' adding context about behavior beyond the annotations. The description adds value without contradicting the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Every sentence earns its place: the first states purpose, the second covers parameter usage, the third directs to an alternative. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a display/visualization tool with readOnlyHint=true, no output schema needed, and a single optional parameter, the description covers the essential ground. It could note that this renders an interactive element versus a static output, but the description's explicit mention of 'interactive' and 'right in the conversation' adequately sets expectations for a read-only visualization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, there is only one optional parameter (date) with a self-evident regex pattern. The description compensates well by stating 'Defaults to today; pass date (ISO YYYY-MM-DD) for another day,' directly documenting the parameter's meaning, format, and default behavior. With a single simple param at 0% coverage, the description carries the full explanatory load effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Render the user's day as the interactive 24-hour reassign dial, right in the conversation.' It specifies the exact visual artifact (24-hour reassign dial) and distinguishes it from siblings by noting it's for SEEING the day visually. It's specific enough to differentiate from get_schedule, which is mentioned explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'use it whenever they want to SEE their day, their schedule laid out, how full it looks, or to visually move things around.' It also provides an explicit exclusion: 'For reading or reasoning about the plan in text, prefer get_schedule,' naming the alternative tool directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
undoUndo recent changesAUndo — revert, roll back, take back, or cancel the last — a recent schedule/confirm_schedule create, a write_events / delete_events batch, a review_day action, or a manage_backlog remove, using the undoTokens they returned. Pass tokens. Each works only while still active and within its 30-minute window; a schedule/confirm_schedule token deletes the event it created, a write_events / delete_events / review_day / manage_backlog token reverses the whole change (deletes what it created, restores what it changed/removed), and a batchUndoToken from a multi-event schedule call removes the events that batch auto-created and voids its open proposals (times you confirm from proposals keep their own undo tokens). This needs a token from a recent call — to discard a whole day's reflection by date instead, use review_day with action 'discard'. Returns per-token results.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | Yes | undoToken(s) returned by schedule, confirm_schedule, write_events, delete_events, review_day, or manage_backlog (incl. a `batchUndoToken`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: that tokens are single-use within a 30-minute window, that different token types have different effects (some delete the created event, some reverse the whole change), and that batchUndoToken removes auto-created events and voids proposals. The destructiveHint=true annotation aligns with the described dedructive effects rather than contradicting them. For a mutation tool with no output schema, the description carries substantive behavioral detail about what each token type does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the purpose. It uses parentheticals effectively to enumerate token effects. It's somewhat lengthy (a single long paragraph) but every sentence adds meaningful information about token semantics and edge cases. The final clause about alternatives is a useful closing note rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter at 100% schema coverage, no nested objects, and no output schema, the description is thorough. It explains the full token-type matrix, the time window constraint, the batchUndoToken special case, and clearly documents the return as per-token `results`. It even gives an alternative approach for a related need. This is essentially complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single `tokens` parameter is documented, including the batchUndoToken variant). The description adds valuable semantics beyond the schema by explaining that tokens are time-limited (30-minute window), single-use, and that different token types have distinct effects. It also clarifies the maxItems=20 and minItems=1 constraints implicitly through the 'recent' framing. The description genuinely supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs (revert, roll back, take back, cancel) tied to a clear resource (recent schedule/confirm_schedule/write_events/delete_events/review_day/manage_backlog operations) via their undo tokens. It explicitly enumerates the source tools and the token requirement, making the scope unambiguous. This distinguishes the tool from siblings like review_day and write_events by focusing on the undo mechanism specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool (with a token from a recent call) and gives an explicit 'when-not' with an alternative: 'to discard a whole day's reflection by date instead, use review_day with action 'discard''. It also explains the constraints under which the tool works (within 30 minutes, while tokens remain active), which is essential usage context for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_eventsWrite eventsAInspectCreate, update (edit), move/reschedule, shift, reflect, or manage a block's checklist — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (create | update | move | shift | reflect | checklist) plus that op's fields; a single edit is just a 1-item array. Times are 24-hour HH:MM; for an event crossing midnight set endNextDay=true. reflect records how a PAST planned event actually went (kept | skipped | changed | added, with an optional actual time) — it never renames or re-times the plan; target one occurrence of a recurring event by its seriesId@YYYY-MM-DD id. checklist manages a block's microtasks: pass items to set/replace the ordered list (a template edit — whole series, or one occurrence with scope 'this'), or check/uncheck (by item id or exact text) to tick them off for a single occurrence; the current microtasks + each one's done state come back on a get_schedule read as the event's checklist. For a recurring event choose a scope: 'all' (default), 'future', or 'this' (the last two need occurrenceDate). To re-time an existing event use move (new start/date, duration kept) or shift (relative nudge by byMinutes); use update only to also rename, re-kind, re-area, or resize (change end). If you know the duration but not a conflict-free time (or only a rough window), use schedule instead of a create. By default the whole batch is atomic: if ANY op fails validation (e.g. a conflict), nothing is written and the failing ops are returned as errors — fix and resend. Pass partial: true for best-effort (apply what's valid). Ops apply in order as one transaction and are checked against each other: two creates can't double-book a slot, and an earlier move frees a slot a later op can reuse. Target each event id at most once per batch. Reference an area/activity type by id or by areaName/activityTypeName; create new ones first with manage_categories. If the user has a Google Calendar connected, creating or editing a calendar-linked event (or one created under their default sync calendar) also pushes the change to Google — the same as editing on the dial; don't edit an event get_schedule/find_event marked readOnly (it's from a calendar the user doesn't own and the change would silently revert). To remove events or clear a day use delete_events. The response reports applied, failed, skipped (validated but not written because the atomic batch was rejected), and per-op results (each with its 0-based index).
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | ||
| render | No | When the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. Otherwise the change reaches an open dial only if the host forwards this result. | |
| concise | No | Drop the human-readable `suggestedFollowup` prose from the response (the structured `undoToken` is still returned). Saves tokens. | |
| partial | No | Best-effort mode: apply the ops that succeed and report the rest as errors, instead of the default all-or-nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the description carries most of the behavioral burden, and it does substantial work: discloses atomic batch semantics, partial-mode fallback, in-order transactional application with cross-op conflict checking, Google Calendar push behavior, readOnly event reverting, timezone/time-format conventions, and the response shape (applied/failed/skipped/results). The only gap is no explicit statement about whether an errored call leaves the calendar unchanged beyond the atomic-batch note, which is implied but stated. Rich disclosure well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose and then organizes by op type. It's dense but not bloated — nearly every sentence carries a distinct fact (atomicity, Google sync, readOnly caveat, scope rules, response fields). A few areas could tighten (e.g., the path/notes on reflect could be condensed), but the structure is logical and each section earns its place. Slightly long but appropriately so for a six-op orchestration tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity (six operation sub-types, recurring-event scope handling, atomic batch semantics, Google Calendar integration, checklist management), the description is remarkably complete. It covers what each op does, when to use which, constraints (target each id once, validation behavior), external integration behavior, edge cases (midnight crossing, readOnly events), and the full response contract. No output schema exists, so the response-shape disclosure in the description ('applied, failed, skipped, per-op results with 0-based index') is essential and present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaning well beyond the schema: it explains the `ops` array structure (1-item array for single edit), op-specific field requirements, cross-midnight via endNextDay, scope semantics ('all'/'future'/'this' with occurrenceDate), reflect's never-renames contract, checklist replace-vs-tick distinction, and the composite seriesId@YYYY-MM-DD id format for recurring occurrences. The description compensates for the uncovered schema parameters and clarifies the complex ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and resource ('Create, update, move/reschedule, shift, reflect, or manage a block's checklist — bulk/batch') that clearly enumerates the six operation types. It explicitly distinguishes from siblings like schedule ('use schedule instead of a create'), delete_events ('To remove events or clear a day use delete_events'), and get_schedule/find_event (referenced for reads). Comprehensive and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive when-to-use guidance: explicit recommendation to use `schedule` when duration known but not a conflict-free time, explicit naming of delete_events as the alternative for removal, guidance on when to use move vs shift vs update ('use update only to also rename...'). Clearly differentiates the six ops from each other and from sibling tools. Also includes Google Calendar ownership caveats about readOnly events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!