Reassign: a circular 24-hour calendar and time-tracking copilot with ADHD-friendly scheduling.
Scored across 11 tools
Each tool targets a distinct resource or action (events, inbox, categories, day review, undo, visual display) with explicit cross-references and guidance on when to use reads vs writes. Apparent overlaps like get_schedule, show_day, and find_event are differentiated by purpose: text reasoning, visual rendering, and name-based lookup.
All tool names follow a consistent snake_case verb_noun pattern (delete_events, write_events, manage_inbox, get_schedule, show_day, undo_changes, etc.) with no mixed conventions or vague verbs.
11 tools is well-scoped for a calendar, inbox, and category management server. Each tool covers a necessary lifecycle area, and the three meta-tools (undo_changes, send_feedback, get_more_tools) do not bloat the set.
The surface covers event CRUD via write_events/delete_events and reads via get_schedule/find_event, inbox write/read via manage_inbox and get_schedule, category/project CRUD via manage_categories, day review via review_day, undo via undo_changes, visual display via show_day, and feedback via send_feedback. No obvious gaps for the stated domain.
Delete events or clear whole days — 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. A bare series id addresses the whole series; seriesId@YYYY-MM-DD addresses one occurrence by its ORIGINAL date, also after a move (the read's id and originalDate give it); add scope:"future" to an occurrence id for that occurrence and every later one. clear removes everything from from to to (inclusive, equal for one day). By default the whole batch is atomic: if ANY op fails, nothing is removed; pass partial: true for best-effort. A recorded undo receipt includes undoToken (call undo_changes before expiresAt, a UTC instant). Deleting a calendar-linked event also removes it from that calendar; an event marked readOnly can't be deleted this way. A delete result lists deletedIds; a scope:"future" delete also returns the truncated series as updated. Results read stored state after the whole batch commits. 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. | |
| 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 only declare destructiveHint=true; the description goes far beyond by disclosing the default all-or-nothing atomicity, the opt-in best-effort mode, an undo receipt with undoToken/expiresAt, the readOnly guard, that calendar-linked events are also removed from that calendar, and what the result object contains. This is rich behavioral context an agent needs before calling a destructive tool.
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?
Front-loaded with purpose and the ops contract, and every sentence carries information that is not in the schema. It is a dense block of text with many parentheticals, so readability suffers slightly, but there is almost 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?
For a destructive, no-output-schema tool, the description covers invocation (ops shape), failure semantics (atomic vs partial), recovery (undoToken/expiresAt), edge cases (readOnly, series truncation returning updated), and return fields (deletedIds). Nothing material to correct invocation 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?
With 67% schema coverage, the description adds real meaning: the id format semantics (bare series id vs seriesId@YYYY-MM-DD by ORIGINAL date, surviving moves), the inclusive from/to range, and the batch semantics of ops. It explains parameter behavior beyond the schema's field-level text.
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?
Opens with a specific verb-and-resource ('Delete events or clear whole days'), and the closing sentence explicitly routes creation/editing to write_events, distinguishing this from the primary sibling. An agent can tell this apart from write_events and undo_changes without opening a schema.
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?
States exactly when to use each op path (delete vs clear), when to add scope:"future", when to choose partial:true over the atomic default, and names undo_changes as the recovery path before expiresAt. It also names write_events as the tool for the opposite operation. Exclusions and alternatives are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for, look up, or locate events and Inbox items by name when you do not have an id: case- and accent-insensitive. Events match fuzzily; Inbox items (un-timed blocks, not events) match when the name holds the query, and come back as inbox (top of tray first, the same shape as the get_schedule backlog items; write them with manage_inbox). Each page has up to 50 Inbox matches; inboxMatchedCount is the total. When nextInboxOffset is not null, pass it as inboxOffset with the same query and filters to read the next page. The offset only pages Inbox items. The date and timeOfDay filters apply to events only. Date ranges include events overlapping any requested day, including events that start earlier; ending exactly at the first midnight does not overlap. timeOfDay filters the event's start time. Events are searched from 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 events (best match first, one per event, each with its name match score from 0 to 1, 1 = exact; a recurring event gives one occurrence with its seriesId: the best match, and on a tie the one nearest to today) in the same event shape as get_schedule, and the timezone of their times. An event with readOnly: true lives on a calendar the user does not own: do not edit or delete it. When two different events tie, ambiguous is true: ask the user which one 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 that start in this part of the day. | |
| inboxOffset | No | Inbox page offset from nextInboxOffset; keep the same query and filters. Defaults to 0. Does not page the events. | |
| activityTypeId | No | Only match events linked to this activity-type id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint. The description adds substantial behavioral context beyond them: fuzzy event matching, case/accent-insensitivity, Inbox result shape, pagination rules, event-only filter behavior, date-overlap semantics, default time window, scoring, seriesId tie-breaking, and readOnly calendar 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?
The description is long but front-loads the core purpose and is mostly dense with necessary edge cases for a 7-parameter search tool. It could be tightened slightly, such as the 'Search for, look up, or locate' synonym stack, but the length is largely justified.
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?
With no output schema, the description fully explains the return shape: events, timezone, score, seriesId, inbox results, inboxMatchedCount, nextInboxOffset, and ambiguity handling. It covers the tool's complexity and edge cases thoroughly enough for an agent to invoke and interpret it 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 baseline is 3. The description adds meaningful semantics beyond the schema, including that from/to widen or shift the event search window, timeOfDay filters event start time, and inboxOffset pages only Inbox items. It is less detailed for areaId and activityTypeId, which the schema already explains adequately.
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?
States specific verbs and resources: search for, look up, or locate events and Inbox items by name when no id is available. It clearly distinguishes Inbox items from events and ties the event shape to get_schedule, letting an agent separate it from siblings without opening schemas.
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 says to use this tool when you do not have an id, describes pagination behavior for Inbox matches, and routes writing to manage_inbox. It also explains default search window, how to widen it, and when to ask the user due to ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for additional tools whenever your task might benefit from specialized capabilities - even if existing tools could work as a fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | A description of your goal and what kind of tool would help accomplish it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context such as what 'check' entails, whether it makes a network call, or what side effects (if any) occur 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 single, front-loaded sentence with no wasted words. It quickly communicates the action and the conditions for use, making it efficient and easy to parse, though it could be slightly more structured with a separate usage note.
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?
The description gives clear usage guidance but does not explain what the tool returns or what happens after 'checking' for tools. With no output schema present, the description carries the burden of explaining the result, which it fails to do. For a simple one-parameter tool, this is a notable gap, though not severe.
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%, and the single parameter 'context' is already documented with a clear description in the schema. The tool description adds no additional semantic meaning beyond what the schema provides, which aligns with the baseline of 3.
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's function: checking for additional tools when a task could benefit from specialized capabilities. It distinguishes itself from the sibling clipform_* tools by being a meta-tool for tool discovery rather than a domain-specific operation, though it does not explicitly name this distinction.
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 provides explicit usage guidance: use this tool whenever specialized capabilities might help, even if existing tools could work as a fallback. This gives the agent a clear decision rule, though it does not mention when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the calendar: the agenda, what is on, how busy the user is, free time, or where the time goes. One call returns the current local time (now, "YYYY-MM-DDTHH:MM"), the user's timezone, the user's areas, activityTypes and projects (the lookup lists for areaId / activityTypeId / projectId; a project has an areaId; an archived project has archived: true, refuses new links, and comes back with a manage_categories update archived: false), userPreferences, and a days array. Each day has its events, its freeSlots, and its blocking load per area, activity type and project (projectId null is no project; non-blocking overlay load comes separately). A read of more than one day also has a top-level loadByProject, the sum of its days (for example, a week). Call it before you schedule, to anchor relative times ('this afternoon'). Pass from and to (ISO YYYY-MM-DD, inclusive; equal for one day). Pass includeSeries: true to also get the recurring series as series (the live ones and the ones in the range, with no notes). Pass includeLookups: false on a later call to leave out areas, activityTypes, projects and integrations.
Time spans: every event and free slot is start + end, two local datetimes "YYYY-MM-DDTHH:MM" in the top-level timezone (e.g. start "2026-09-23T22:00", end "2026-09-24T01:00"). The end is always after the start; a slot to midnight ends at the next day's T00:00. An event from an earlier day that runs into this day is listed first, with its real start, on every day that it touches; only its time inside the day counts for load and free slots. A warning marks a start time that a DST change skips.
Each event carries its source ("reassign", else a provider like "google"), its home calendarId (absent = the default calendar, null = dial only) and any mirrorCalendarIds (with mirrorStyles when a copy is private or busy). An event with readOnly: true is on a calendar the user does not own: do not edit or delete it (tell them to change it there). kind "non_blocking" is an overlay that may overlap others (fasting, an away marker); "reference" is see-only: its hours stay free, so do not move, delete, or schedule work into it unless asked. A confirmed past day carries a review adherence rollup and per-event reflect actuals; use them for how a day or week actually went. When a calendar is connected, integrations describes it (a calendar's timezone is information only; every span uses the top-level timezone; a calendar's copyStyle applies to copies when mirrorStyles omits that calendar). For a single day, a one-line weather headline is included when the user has a city. For one day, pass includeWeather: true for the full forecast (an outdoor plan only) and includeEnergy: true for the energy curve (energy: peak and dip windows from logged sleep), to put focus work in a peak.
Inbox: backlogCount is the number of Inbox blocks (un-timed intentions). Pass includeBacklog: true for the items (top of tray first, up to 50); backlogPlannedOn, backlogProjectId (an id or "none"), backlogMinPriority (0 to 4) and backlogOffset filter or page them and need includeBacklog: true; with a filter, backlogMatchedCount is the number of matches. Each item has a projectId and a priority (0 none, 1 low, 2 medium, 3 high, 4 urgent). To find an item by name, use find_event. When nextBacklogOffset is not null, pass it as backlogOffset with the same filters for the next page. Place or manage items with manage_inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day of the range, inclusive. | |
| from | Yes | First day of the range, inclusive. | |
| minDuration | No | Return only the `freeSlots` of at least this many minutes. | |
| backlogOffset | No | Inbox page offset from nextBacklogOffset; keep the same filters. Needs includeBacklog: true. | |
| includeEnergy | No | Add `energy`: the user's forecast energy curve for the day (peak and dip windows, the current level today, calibration state), built from logged sleep. Use it to put focus work in a peak and admin in a dip. With no logged sleep it is a short nudge to log sleep. Needs one day (`from` equal to `to`). | |
| includeSeries | No | Also return the recurring masters as `series`. | |
| includeBacklog | No | Include the Inbox items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their Inbox. | |
| includeLookups | No | Default true. Pass false to leave out `areas`, `activityTypes`, `projects` and `integrations` when you already have them from an earlier read. | |
| includeWeather | No | Replace the one-line `weather` headline with the full forecast for the day (condition, temperature range, rain window, daylight, and a part-of-day breakdown). Use it only for an outdoor or weather-sensitive plan, or when the user asks about the weather. Needs one day (`from` equal to `to`). | |
| weatherLocation | No | A city or place name to forecast instead of the user's own city, e.g. "London". The forecast date and times are local to that place; the report names its timezone. Needs includeWeather: true. | |
| backlogPlannedOn | No | Filter the Inbox blocks to those planned for this day (a planned day, or a planned window that covers it). Needs includeBacklog: true. | |
| backlogProjectId | No | Filter the Inbox blocks to one project id, or "none" for the blocks with no project. Needs includeBacklog: true; composes with the other filters. | |
| backlogMinPriority | No | Filter the Inbox blocks to a priority of at least this value (0 none, 1 low, 2 medium, 3 high, 4 urgent). Needs includeBacklog: true; composes with the other filters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/openWorldHint, so the description carries the real burden and delivers: readOnly events on non-owned calendars, non_blocking overlays, reference events whose hours stay free, DST `warning` semantics, project archival behavior, and backlog pagination via nextBacklogOffset. This is rich context 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 purpose is front-loaded, but the body is a dense wall of heavily parenthesized clauses that pack multiple rules per sentence, making it hard to scan for a single parameter's behavior. Much of the length is justified by the missing output schema, but it is not tightly edited.
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 13-parameter read tool with no output schema, the description documents the return shape (days, events, freeSlots, load rollups, series, weather, energy, backlog), edge cases, and cross-parameter requirements thoroughly. Nothing an agent needs to call it correctly 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 the baseline is 3, but the description adds real semantics: from/to are inclusive and equal for one day, includeLookups:false is for a later call when lookups are already held, backlog filters all require includeBacklog:true, and nextBacklogOffset is replayed as backlogOffset with the same filters.
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?
Opens with a specific, vivid statement of what the tool reads ('the agenda, what is on, how busy the user is, free time, or where the time goes') and then enumerates the actual payload (now, timezone, areas, days, events, freeSlots, load). An agent can tell it apart from write/manage siblings immediately.
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?
Gives concrete when-to-use ('Call it before you schedule, to anchor relative times') and routes two sibling cases away (find_event for finding an item by name, manage_inbox for placing items). It stops short of full differentiation from show_day and review_day, which also read day data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, or delete areas (categories / groups / colour-coded labels), activity types (tags / fill patterns) and projects (named goals under an area) — one or many in a single call. Pass areas, activityTypes and/or projects, 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). Projects: {op:"create", name, areaId?} / {op:"update", id, name?, areaId?, order?, archived?} / {op:"delete", id} / {op:"split", id, linkId}. A split moves one task list or Linear project (linkId) that feeds the project to a new project of its own, "{name} ({Provider})" in the same area (" 2" on a taken name), with its Inbox items; later syncs keep it there. {op:"relink", id, linkId} points one Linear project (linkId) at the live project id, with its Inbox items. A project is your own (no shared defaults, no fork). areaId links it to an area; when a write moves an Inbox item to the project and sets no area, the item takes that area, also over an area set by hand. archived: true marks it archived in the lookups and refuses new links; its links stay; archived: false restores it. A delete clears the project link on its items and events (one undo restores them). A delete of a project that a synced task list or Linear project feeds fails with conflict: link it to another project first, or archive it. A project name is unique among the live projects of the user, in any area: a duplicate fails with conflict ("A project named Launch exists in Work."). Results come back in a projects array. Colours are lowercase "#rrggbb"; omit color or pattern 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). A delete removes your own entry, or hides a shared default (and your copy of it) for you only. When events, Inbox items, trackers or calendar defaults use it, a delete without reassignTo is refused with validation; the error details give usage (the counts) and reassignTargets (the categories that can take them). Ask the user, then send the delete again with reassignTo (another id, to move them) or reassignTo: null (to clear their link). A project name is unique among all live projects of the user, so a moved project keeps its name. Names are deduplicated case-, accent- and whitespace-insensitively: a create or a rename into the name of an existing area/type fails with conflict (reuse the existing id instead). A create or update result is the created/updated row; a delete result lists deletedIds (plus movedEvents after a reassign). Every call that writes returns one undoToken + expiresAt (a UTC instant); pass it to undo_changes to reverse the whole call. 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 (and a project id in manage_inbox projectId).
| Name | Required | Description | Default |
|---|---|---|---|
| areas | No | ||
| partial | No | Best-effort mode instead of the default all-or-nothing. | |
| projects | No | ||
| activityTypes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only confirm it is a non-read-only, destructive, closed-world mutation; the description adds substantial behavior the annotations cannot convey: atomic-by-default with a `partial: true` best-effort mode, one `undoToken` + `expiresAt` per write, `conflict`/`validation` error codes with `usage`/`reassignTargets` detail, refusal of deletes on in-use categories, shared-default forking with `forkedFrom`, and archiving semantics. This is well beyond annotation coverage.
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?
Purpose is front-loaded and most sentences carry real information, but the body is one very dense paragraph with duplicated content (project-name uniqueness is stated twice). A reader must parse a wall of text to extract the op grammar, so structure is only adequate.
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?
Despite no output schema and a complex multi-op, multi-family schema, the description covers write results (`created`/`updated` rows, `deletedIds`, `movedEvents`, `projects` array), error paths with remedy payloads, and undo. An agent has enough to call it correctly and recover from failures.
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 25%, so the description must compensate, and it largely does: it spells out every op shape (`create`/`update`/`delete`/`split`/`relink`), the per-family field sets, valid `pattern` values, `#rrggbb` colour format, and `reassignTo` semantics. It omits a few schema-documented fields (`order` on area update, `publishCalendarId` on project update), which keeps it short of a 5.
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 opening sentence names precise verbs (create/update/delete) and the exact resource families (areas, activity types, projects) with their aliases, so the agent immediately knows this is the category/taxonomy management tool. It is clearly distinguishable from siblings like write_events or delete_events, which consume the ids this tool returns.
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 explicitly places the tool in a workflow: create areas/types here first, then pass the returned ids to write_events and a project id to manage_inbox `projectId`, and reverse writes via undo_changes. That is clear sequencing guidance, though it never states conditions under which this tool should be avoided in favor of a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write to the Inbox — the tray of time-blocks captured without a time yet: intentions like "wash the car" or "call the dentist". To READ Inbox blocks, use get_schedule (backlogCount, then includeBacklog: true for the items), or find_event 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 an Inbox block (name, optional notes, durationMinutes, kind, checklist, areaId/activityTypeId, projectId, priority, and an optional plannedDate or plannedDate+plannedUntil window — the still-untimed days it is 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); capture_text takes what the user typed, dictated or selected, as text, and AI splits it into 1 to 10 Inbox blocks with a name, notes, a length and a day — prefer it over capture for raw user input, and send only the fields the user chose; update edits one by id (plannedDate: null moves it back to Someday; areaId/activityTypeId: null clears the link; projectId: null clears the project and keeps the area; a task-app-linked block's date is provider-owned and refused); remove deletes one by id; schedule PLACES an Inbox block on the dial at start (local "YYYY-MM-DDTHH:MM"; its duration sizes it; pass an RRULE recurrence to make it repeat) and removes it from the Inbox; park MOVES a dial event (by id) 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. Moving a calendar-linked event to the Inbox removes its calendar copy but remembers the calendar, so re-scheduling it republishes there. Results are created / updated objects and deletedIds. Every call that writes returns one undoToken + expiresAt; pass it to undo_changes to reverse the whole call. The Inbox needs Reassign Pro; the 7-day free trial includes it. schedule and park are inverses, and both keep the block's kind.
| 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?
Far exceeds the annotations: discloses atomic-by-default semantics with a partial:true escape hatch, that every write returns one undoToken + expiresAt reversible via undo_changes, the Reassign Pro requirement (and 7-day trial), and specific refusal rules for park and task-linked date ownership. Annotation destructiveHint=true is reinforced rather than merely restated.
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?
Front-loaded with purpose, then read-vs-write routing, then the op catalog — a sensible order. It is dense and close to a wall of text in a single block, but nearly every sentence carries operational information an agent needs to avoid a failed call.
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?
Covers the full surface needed for a 6-op batch tool: result shapes (created/updated objects, deletedIds, undoToken/expiresAt), batch atomicity, permission gating, and refusal reasons. With no output schema, the description adequately fills that gap.
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 schema already documents fields richly, and the description repeats some of that (enrich, capture_text splitting). Where it adds real value is op-selection semantics and cross-op behavior (a null plannedDate returns to Someday, park only works on unreviewed one-off owned events, re-scheduling republishes to the remembered calendar).
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?
Specific verb+resource: 'Write to the Inbox — the tray of time-blocks captured without a time yet', with concrete examples ('wash the car'). It explicitly carves out the sibling boundary by naming get_schedule and find_event as the read paths and declaring 'THIS tool is the write surface.'
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?
Gives explicit when-to-use routing: read via get_schedule/backlogCount or find_event, write via this tool. It further differentiates capture vs capture_text ('prefer it over capture for raw user input'), and constrains enrich ('RAW captured text only — never for a name the user chose'). schedule/park are described as inverses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm or discard a whole 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), which get_schedule then returns as that day's review block and which the stats use; re-confirming refreshes it. action:"discard" fully resets the day: it removes the review, clears the kept/skipped/changed marks + actual times off the day's planned events (returned as updated), and deletes events ADDED only as part of the reflection (deletedIds) — use it to start a day's reflection over or drop one confirmed by mistake. Only a past day can be confirmed; discard works on any day, also on today's check-offs. A recorded undo receipt includes undoToken + expiresAt (UTC); call undo_changes before it expires. An empty discard returns noop:true, empty result arrays, and no undo receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| action | Yes | "confirm" freezes the day's adherence snapshot; "discard" fully resets the day's reflection (removes the review, clears every mark). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give destructiveHint=true; the description goes far beyond by enumerating exactly what is destroyed (review, kept/skipped/changed marks, actual times, and reflection-added events returned in `deletedIds`), what is created (adherence snapshot with per-area/per-type breakdowns), and the undo lifecycle (`undoToken` + `expiresAt` UTC). It also discloses the no-op edge case (empty discard returns `noop:true`, empty arrays, no receipt).
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?
Front-loaded with purpose, then actions, then side effects and undo — a sensible information hierarchy in a single dense paragraph. It is long for a two-parameter tool, and the action descriptions echo the schema's enum text nearly verbatim, which is minor redundancy, but almost every clause carries operational information.
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?
There is no output schema, and the description fills that gap by naming the returned fields (`updated`, `deletedIds`, `noop`, `undoToken`, `expiresAt`) and where the snapshot surfaces (`get_schedule`'s `review` block). For a destructive two-param mutation, everything an agent needs to call it safely and interpret the result is 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 only 50% — `action` has an enum description but `date` has just a regex pattern with no prose. The description compensates by spelling out the ISO date format and, more importantly, elaborating the downstream consequences of each action value rather than restating the enum. It adds real meaning, though the date semantics are only lightly extended beyond the pattern.
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 names a specific verb pair and resource ('Confirm or discard a whole day's reflection') and immediately scopes it with the required `date` param. It distinguishes itself from siblings by naming write_events' `reflect` op as the precondition and undo_changes as the follow-up, so an agent can separate this from get_schedule or delete_events without opening a schema.
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?
Explicit preconditions ('once you've marked its events with write_events' `reflect` op'), explicit selection rules between the two actions, and explicit constraints ('Only a past day can be confirmed; discard works on any day'). It even names intended use cases — 'start a day's reflection over or drop one confirmed by mistake'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report 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). Each report has a kind ("bug" | "idea" | "other") and a message. In message, describe what you tried, what happened, what you expected, and any event ids or steps to reproduce. Collect every report of the session into ONE call, with one item in reports for each issue. Do not call this tool once for each issue. 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. Returns {} once the report is accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| reports | Yes | All reports of this session. Add one item for each issue. | |
| submissionId | No | A UUID for this submission. Reuse it with identical content on retries within 24 hours; use a new UUID for a new report. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write/open-world profile; the description adds non-obvious behavior: the return value is `{}` on acceptance, the user's account is attached automatically for follow-up, and personal details or private schedule contents must not be pasted into the message. The batching rule (one call per session) is a behavioral constraint found nowhere in the structured fields.
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?
Purpose and scope lead the paragraph, followed by triggering conditions, then the exclusion, then per-field guidance and constraints. Dense and well ordered, though the long enumeration of triggering cases and the restated 'each report has a kind and message' sentence add some 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 two-parameter write tool with no output schema, the description covers purpose, when to use, batching, privacy constraints, message content expectations, and the return value. An agent has everything needed to call it correctly and safely.
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 100%, so the baseline is 3, but the description goes further: it defines the `kind` values semantically and specifies what a good `message` contains (what was tried, what happened, what was expected, event ids or reproduction steps), plus the one-item-per-issue structure of `reports`. It does not cover the `submissionId` retry semantics, which remain schema-only.
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 states a precise verb and resource — report a bug, limitation, friction, or idea about the product itself — and explicitly scopes it to meta-feedback about the MCP integration and its results. It also names the sibling it is not (write_events for changing the schedule), so an agent can distinguish it without opening a schema.
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 enumerates the triggering conditions (errors, confusing or wrong results, retries, workarounds, loops, rough edges, user-requested feedback) and an explicit exclusion with the correct alternative (use write_events to change the schedule). It further prescribes when to batch versus split (one call per session, not one per issue).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render 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 already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the output is an interactive dial embedded in the conversation, the date defaults to today, and read-only textual reasoning belongs in get_schedule. It does not clarify whether the 'move things around' affordance mutates state (which would be worth stating against readOnlyHint), leaving a small gap.
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?
One tightly packed paragraph with zero filler: purpose front-loaded, then usage triggers, then default/format for the single parameter, then the routing alternative. Every clause earns its place and the ordering matches how an agent scans for a decision.
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?
With no output schema, the description does describe what the agent gets back (an interactive dial rendered in the conversation) and covers the only parameter's default and format. What remains thin is the interactive surface itself — what the user can do inside the rendered dial and whether those actions change data — which matters given readOnlyHint=true.
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?
There is only one parameter and schema description coverage is 0%, so the description must carry the meaning — and it does, stating the default ('Defaults to today') and the accepted format ('ISO YYYY-MM-DD'), which the schema only encodes as a regex pattern. It does not describe behavior for invalid or out-of-range dates, so it is not exhaustive.
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?
States a specific verb and resource ('Render the user's day as the interactive 24-hour reassign dial') and immediately scopes it as an in-conversation visual. It distinguishes itself from the closest sibling by explicitly naming get_schedule as the text alternative, so an agent can route without opening either schema.
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?
Gives an explicit trigger set ('whenever they want to SEE their day, their schedule laid out, how full it looks, or to visually move things around') and an explicit counter-condition ('For reading or reasoning about the plan in text, prefer get_schedule'). Both the when and the when-not are present with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Undo — revert, roll back, take back, or cancel the last — a recent write_events / delete_events batch, a review_day action, a manage_inbox call (capture, update, remove, schedule, park), or a manage_categories call (create, update, delete). Pass tokens: the undoToken those calls returned. Each works only while still active and before its expiresAt (a UTC instant, 30 minutes). A token reverses the whole change (delete what it created, restore what it changed or removed). If a row that the write touched changed again after the write (for example the event was moved, parked or deleted later), that token fails with stale and nothing changes. Stamp mismatches include conflictingRows with row ids and reasons (changed, deleted, newly_present), up to 50; conflictingRowsTruncated:true means more were omitted. Several tokens undo newest write first, so their order does not matter. Each result counts reverted, restored, removed and voided. 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 | The `undoToken` from an earlier write’s successfully recorded undo receipt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true and readOnlyHint=false; the description goes far beyond by disclosing token expiry (30 minutes, UTC), that a token reverses the entire change atomically (delete what it created, restore what it changed/removed), the `stale` failure mode when a touched row changed again, `conflictingRows` with reasons and a 50-row truncation flag, and newest-write-first ordering across multiple tokens.
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?
Front-loaded with the verb and the list of undoable operations; every sentence carries distinct information. It is dense and slightly run-on with stacked em-dashes, but nothing is 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?
No output schema exists, yet the description explains the return shape (per-token `results` counting `reverted`, `restored`, `removed`, `voided`) plus error semantics. For a destructive, single-parameter tool this is essentially complete.
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 baseline is 3, but the description adds real meaning: the token is the `undoToken` from a successful undo receipt, it works only before `expiresAt`, and multiple tokens need not be ordered. The maxItems=20 constraint is only in 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?
States a specific verb ('Undo — revert, roll back...') and enumerates exactly which prior operations it reverses: write_events/delete_events batches, review_day actions, manage_inbox calls, and manage_categories calls. An agent can distinguish it from every sibling without opening a schema.
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 states the precondition (pass the `undoToken` returned by those calls, only while active and before `expiresAt`) and names an alternative path: use review_day with action 'discard' to discard a whole day's reflection by date. Covers both when-to-use and when-to-use-something-else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update (edit, move, resize), shift, reflect, or manage a block's checklist — one or many in a single call. Pass ops, an array where each item has an op (create | update | shift | reflect | checklist) plus that op's fields; a single edit is a 1-item array. A span is start + end as local datetimes "YYYY-MM-DDTHH:MM" (no seconds, offset or Z). The end must be after the start; an overnight or multi-day event simply ends on a later day. A bare series id addresses the whole series; seriesId@YYYY-MM-DD addresses one occurrence by its ORIGINAL date, also after a move (the read's id and originalDate give it); add scope:"future" to an occurrence id for that occurrence and every later one. update with start/end moves or resizes an event, also to another day; a lone start keeps the duration and a lone end keeps the start. shift nudges by byMinutes. reflect records how a PAST planned event actually went (kept | skipped | changed | added; actual times only for changed/added) — it never renames or re-times the plan. checklist manages a block's microtasks: items replaces the ordered list (bare id = the series template, occurrence id = that day), and check/uncheck take item ids and tick them off for one occurrence. Recurrence is an RRULE; null on update stops the repeat. Reference areas and activity types by areaId/activityTypeId (null on update clears the link; null on create is the same as omitted); create new ones first with manage_categories. projectId links a live project (null on update clears it and keeps the area); a new project with no areaId gives the event the area of the project. priority is 0 none to 4 urgent. calendarId is the home calendar (omit = the default calendar, null = dial only) and mirrorCalendarIds the one-way copies; mirrorStyles sets a copy to 'private' or 'busy' (a shield that hides the details). A calendar's copyStyle in get_schedule integrations applies when mirrorStyles omits that calendar. Copies of a series need a home calendar. To find a conflict-free time for a create, read the day's freeSlots with get_schedule first. To place an existing Inbox item, use manage_inbox schedule instead of a create. By default the whole batch is atomic: if ANY op fails (e.g. a conflict), nothing is written and the failing ops are returned as errors — fix and resend. Pass partial: true for best-effort. 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. conflictPolicy: "propose" means a write never overlaps a blocking event: it fails with conflict and nearestSlots; resend with one of those slots. Changes to a calendar-linked event also reach that calendar; don't edit an event marked readOnly (the tool refuses the change). To remove events or clear days use delete_events. The response has per-op results (each with its 0-based index), undoToken + expiresAt (UTC) when an undo receipt is recorded, and timezone when a result carries a span. Results read stored state after the batch commits; a later op can affect an earlier op’s returned event. A row with warnings: ["classification_pending"] may still get an eligible area, activity type, kind or energy settings from the AI after this reply. Native creates preserve the caller’s kind, including default blocking; AI does not change it. A client-minted create id must be a UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | ||
| dryRun | No | Check the ops without a write: conflicts come back with `nearestSlots`, and each valid op comes back `skipped`. | |
| 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. | |
| 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 only say readOnlyHint=false / destructiveHint=false; the description supplies the real behavioral contract: all-or-nothing atomicity by default vs `partial: true`, ops applied in order as one transaction and cross-checked, one id per batch, undoToken/expiresAt, results reflecting post-commit state, and refusal to edit `readOnly` events. It also discloses side effects beyond the immediate op (calendar-linked edits reach the calendar, calendarId null deletes mirror copies) and the `classification_pending` warning.
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?
It is long and unstructured prose, but the length is proportionate to a five-op, ~30-field batch tool and the core purpose and `ops` contract are front-loaded. Nearly every sentence carries operational detail; a few (e.g. repeated datetime-format phrasing) could be trimmed or bulleted, which keeps it from a 5.
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 complex mutation tool with no output schema, the description covers the response surface (per-op `results` with `index`, `undoToken`/`expiresAt`, `timezone`), failure modes (atomic failure, `conflict` with `nearestSlots`), and the auxiliary params (`dryRun`, `partial`, `render`). Nothing an agent needs to invoke it correctly 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 high (75%) and the per-field descriptions are already rich, so the baseline is 3. The description nonetheless adds meaning the schema does not: the `ops` array item shape, the `seriesId@YYYY-MM-DD` original-date addressing rule, scope:'future' semantics, and the interaction rules (lone start keeps duration, lone end keeps start, null recurrence stops the repeat).
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?
Opens with a precise verb+resource: 'Create, update (edit, move, resize), shift, reflect, or manage a block's checklist' and clarifies the batch shape via `ops`. It explicitly carves out what it is NOT for, naming delete_events and manage_inbox `schedule` as the alternatives, so an agent can distinguish it from siblings without opening a schema.
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?
States concrete routing rules: read `freeSlots` via get_schedule before a create, use manage_inbox `schedule` to place an Inbox item, use delete_events to remove events or clear days, and read the current checklist before replacing it. It also gives the fallback path for conflictPolicy 'propose' (resend with a `nearestSlots` slot), which is exactly the when-to-do-what guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ADHD system of record for agents: tasks, goals, loops, calendar, focus stats.
The planner you can call: your tasks, calendar, notes, goals and habits, in your AI assistant.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Time tracking, tasks and team chat for humans and AI agents.
Add one secure layer between your agents and this server.
