reassign
Server Details
Reassign — circular 24-hour calendar & time-tracking copilot with ADHD-friendly scheduling.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.7/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: scheduling, confirming, viewing, searching, editing, deleting, managing categories, sending feedback, rendering the day, and undoing. No overlapping functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., confirm_schedule, find_event, write_events), with 'undo' as a minor but acceptable exception.
With 10 tools, the server is well-scoped for a calendar/scheduling domain, covering all necessary operations without excess or deficiency.
The tool set provides comprehensive lifecycle coverage for events and categories, including creation, reading, updating, deletion, scheduling, and undo. Viewing via text and visual render is also supported.
Available Tools
13 toolsconfirm_scheduleConfirm proposed timesAInspect
Confirm — 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show no special hints. Description adds context: conflict checking, error reporting (slot taken), and prompts to re-run schedule. This enriches beyond 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?
Two sentences, front-loaded with action, no wasted words. Structure is clear and efficient.
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 main use, conflict behavior, error handling, and return format ('per-item results'). Lacks mention of 'render' parameter, but not critical for typical use. Output schema missing but description compensates.
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?
Adds meaning: 'commitToken' and '0-based index' clarify schema fields. Explains default behavior for choice. Does not cover 'render' param, but schema covers it. Overall adds value beyond 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 clearly states it confirms proposed times from 'schedule', using verbs like 'accept', 'pick', 'commit'. It differentiates from sibling tools like 'schedule' which proposes, and others.
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?
Clearly tells to pass items with token and optional choice, explains conflict re-check and error handling. Implies usage after 'schedule', but does not explicitly exclude other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_eventsDelete eventsADestructiveInspect
Delete 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds key behavioral details beyond annotations: atomic by default with partial option, reversible with undoToken (30-minute window), and impact on Google Calendar. No contradictions 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?
Front-loaded with main purpose, followed by details in a logical order. Slightly long but every sentence adds value. Could be slightly more concise, but overall well-structured.
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 edge cases (Google Calendar, readOnly events), response structure (applied, failed, skipped, per-op results), and undo capability. No output schema, but description compensates fully.
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?
Explains the ops array structure, the two operation types (delete/clear) with their parameters (scope, occurrenceDate, date, to), and the meaning of partial and render. Schema coverage is 75%, but description adds significant context.
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 purpose: delete events or clear whole days in bulk/batch. It uses specific verbs ('delete', 'clear') and distinguishes from siblings like write_events and undo.
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 guidance: when to use this tool (for deletions) vs. write_events for creation/editing. Also explains conditions like Google Calendar integration and readOnly events that cannot be deleted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_eventFind eventARead-onlyInspect
Search for, look up, or locate events by name when you don't have an id — fuzzy, case- and accent-insensitive. 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant details beyond annotations: default time window, fuzzy matching, return format with fields, handling of ambiguous results, and warning about read-only events. Annotations already declare readOnlyHint=true, but description enriches understanding of behavior and constraints.
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?
Five sentences, each serving a purpose: main action, defaults, output, ambiguity handling, recurring events. No fluff, but slightly longer than minimal. Front-loaded with key 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?
Despite no output schema, description fully explains return format and fields. Covers defaults, edge cases (ambiguous, recurring), and read-only flag. Complete for a search tool with 6 params.
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?
Input schema covers all 6 parameters with descriptions (100% coverage). Description adds context like 'fuzzy, case- and accent-insensitive' for query and explains how from/to shift the window. This provides valuable 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?
Description clearly states the tool's purpose: searching/looking up events by name when without an ID. It specifies fuzzy, case- and accent-insensitive matching, and mentions default date range and optional filters. This differentiates it from sibling tools like get_schedule or show_day by focusing on name-based search.
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 when to use: when you don't have an ID. Describes default date range and how to customize via from/to parameters. Lacks explicit exclusions or alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_energyGet energy curveARead-onlyInspect
Get 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, no contradiction. Description adds detail: returns compact overview (peak/dip windows, current level, calibration state), not hourly dump, and explains dependency on sleep 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?
Concise single paragraph that front-loads purpose, then usage, then parameter details, then behavior. Every sentence is informative and non-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, but description clearly states what is returned (peak/dip windows, current level, calibration state) and what is not. Covers prerequisites and error handling. Complete for a simple 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?
With 100% schema coverage, description adds meaning beyond schema: explains default is today, ISO format, and semantic difference between future and past days regarding sleep data.
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?
Clearly states it gets the user's forecast energy curve for a day, specifying the resource and verb. Distinguishes from siblings by noting that get_schedule and show_day don't include energy.
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 when energy matters or user asks, and mentions that siblings don't cover energy. Provides prerequisite (at least one logged night of sleep) and fallback behavior (nudge to log sleep).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scheduleGet scheduleARead-onlyInspect
Read the calendar — the day's agenda, what's on, how busy you are, your availability, an overview of your day or week, where your time is going. Returns everything needed to reason about the plan in one call: the current time (now), the user's areas and activityTypes, userPreferences, and a days array (one entry per requested day) with that day's events, free slots within the day, and how its time splits across areas and activity types (loadByArea/loadByActivityType count blocking time only; any non-blocking overlay minutes — fasting, an away marker — are reported separately as nonBlockingLoadByArea/nonBlockingLoadByActivityType when present). Call it before scheduling to anchor relative times. 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, e.g. "2026-06-01"). Pass compact: true to shrink each day's events (no decimal hours/label; area and activity type as ids referencing the top-level areas/activityTypes) — prefer it for wide ranges. Pass includeSeries: true to also get recurring masters (rule, anchor, next occurrence) as series. Each event carries its source ("reassign" for a native event, else the provider like "google") and, when calendar-linked, its calendar name; an event with readOnly: true is from a calendar the user doesn't own — don't edit or delete it. An event's kind is omitted when it's a normal "blocking" event; kind: "non-blocking" is an overlay (e.g. fasting, an away marker) that may overlap others; kind: "reference" is see-only — something the user wants to view but isn't working on (its hours stay free for scheduling; don't move, delete, or schedule work into it unless asked). A past day the user confirmed ("this is how it went") carries a review block: reviewed: true, reviewedAt, and an adherence rollup read from the frozen reflection snapshot — event and layer scores (0–1, how closely the day matched the plan), plannedHours/unplannedHours, and per-area/per-activity-type breakdowns (byArea/byActivityType, keyed by id). Use it to answer how a day or week actually went; an unreviewed day has no review block. Per-event actuals ride each event's reflect block. When the user has connected a calendar, integrations describes the setup: a sources array (one per connected provider) each with its calendars, the account-wide AI classifier (aiClassify, and aiRules — the user's scattered guidance compiled into one conflict-free ruleset the classifier follows) and the defaultSyncCalendarId new events sync to. Per calendar it carries the fallbacks that decide how synced events are classified when the AI is unsure — defaultKind (block type) and defaultArea/defaultType (referencing the top-level taxonomy) — plus writable. Use it to explain why an event came in non-blocking, or where a new event will sync. It's omitted when no calendar is connected. When a single day (or today) is requested and the user has a city, a one-line weather headline for that day is included (temp range, condition, rain window, sunset) — enough to schedule around; call get_weather only when an outdoor plan needs the hourly detail. Times are in the user's timezone; events with no title show as "(untitled)".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| date | No | ||
| from | No | ||
| dates | No | ||
| compact | No | ||
| includeSeries | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation, detailing the exact return structure (current time, areas, days with events, free slots, load breakdowns, review block, integrations, weather). It explains special behaviors like non-blocking events, readOnly events, and the review block. No contradictions 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 comprehensive but lengthy, containing many details about the return object that could be in an output schema. It is front-loaded with the core purpose and well-structured, but some redundancy exists (e.g., listing event kinds twice). Still, every sentence adds value.
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 (6 parameters, no output schema, many edge cases), the description is remarkably complete. It covers return structure, parameter usage, special cases (readOnly, kind, review, integrations, weather), and even advises on when to call other tools. No gaps remain.
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 0% schema coverage, the description compensates by explaining every parameter: date, from, to, dates, compact, includeSeries. It gives format examples, default behavior (today), and practical usage tips. This fully enables correct parameter usage.
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 starts with 'Read the calendar' and lists many specific use cases (day's agenda, availability, overview). It clearly distinguishes this tool from siblings like find_event (which searches events) and schedule (which creates events) by describing the rich return object.
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 'Call it before scheduling to anchor relative times' and advises when to use compact, includeSeries, and get_weather only for hourly detail. However, it lacks direct comparison with siblings like find_event or manage_categories, though the context implies their distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_weatherGet weatherARead-onlyInspect
Get 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds context about defaults (today, user's city) and return format (compact overview + part-of-day breakdown, not hourly dump). No contradiction.
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?
Single paragraph, dense with information; each sentence provides value. Slightly verbose but still efficient.
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, but description explains return structure. Parameters fully covered with defaults and usage. Tool is simple and description is 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%, but description adds defaults (today, user's city), format (ISO YYYY-MM-DD), and usage for location, enhancing understanding beyond 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 clearly states the verb ('Get the weather forecast') and specific resource ('for a day'), and distinguishes from siblings get_schedule and show_day by noting they already include a one-line weather headline.
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 tells when to use (outdoor/weather-sensitive plans or explicit ask) and when not to (indoor plans, prefer siblings for quick glance), naming alternatives get_schedule and show_day.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_categoriesManage categoriesADestructiveInspect
Create, 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses forking behavior, duplicate name rejection, reassignTo requirement for deletes, undoToken return, and atomicity, far exceeding the bare destructive hint annotation.
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 efficient; every sentence adds value. Could benefit from slightly more structure like bullet points for readability, but appropriately sized for 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?
Despite no output schema, the description covers all operation types, error cases, forking, atomicity, partial mode, and cross-reference with write_events, making it fully complete for an agent.
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 only 33% schema coverage, the description compensates thoroughly by explaining operation syntax, valid patterns/colors, deduplication rules, and max items, adding substantial 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 clearly states the tool creates, updates, or deletes areas and activity types in a single call, with specific verbs and resources, distinguishing it from siblings like write_events.
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 advises creating categories first and linking to write_events, and explains atomic vs partial modes, but lacks explicit when-not-to-use statements, though no alternative category tools exist.
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 dayADestructiveInspect
Confirm 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true, and the description elaborates on the destructive effects of 'discard', including deleing rows and markers. It also mentions reversibility via undoToken, adding value beyond 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 detailed but front-loaded with the main purpose. Some phrases are slightly verbose (e.g., explaining what get_schedule surfaces), but overall each sentence adds value.
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 actions, side effects, undo), the description covers prerequisites, constraints, effects, and return value (undoToken). It is sufficient for correct agent 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 has 2 parameters with 50% coverage; the description explains the meaning of each action in detail (confirm freezes snapshot, discard resets) and adds constraints (date must be past, ISO format). This significantly enriches 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 clearly states the tool confirms or discards a past day's reflection using specific verbs and resource (past day). It distinguishes from siblings like confirm_schedule and delete_events by specifying the prerequisite of marking events with write_events' reflect op.
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 when to use (after marking events) and conditions (only past day, not too far back). It explains the two actions but does not explicitly compare to alternative tools like undo, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scheduleSchedule into free timeAInspect
Find conflict-free time and place one or more events — the easiest way to book work without computing slots yourself. 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral details beyond annotations: creates events, returns undoToken/commitToken, orders requests by priority, syncs with Google Calendar, and provides idempotency via request_id. Lacks explicit mention of rate limits or auth requirements, but annotations already indicate it's a write 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?
The description is detailed but somewhat verbose, spanning multiple paragraphs. While it is necessary for the tool's complexity, it could be more structured with bullet points or shorter sentences. However, it is front-loaded with the main 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?
Provides comprehensive coverage of the tool's workflow: input parameters, scheduling logic, response structure (results, options, tokens), retry behavior, and integration with Google Calendar. It fully equips an AI agent to use the tool correctly despite the lack of an output schema.
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?
Adds substantial meaning beyond the input schema, especially for the combination of start/earliest/latest, duration format, autoCommitBest logic, and request_id. Compensates for the 50% schema description coverage by explaining how parameters interact and the scheduling flow.
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?
Clearly states the tool's function: 'Find conflict-free time and place one or more events'. Distinguishes itself from siblings like confirm_schedule and get_schedule by emphasizing it handles the scheduling computation automatically.
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 guidance on when to use this tool ('the easiest way to book work without computing slots yourself'), when to use alternatives (confirm_schedule for option review, autoCommitBest for one-shot), and how to handle relative date resolution in a separate step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend feedbackAInspect
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). 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, and openWorldHint=false, indicating a write operation but not destructive. The description adds context that feedback is sent to the product team who read every message and that the user's account is attached automatically for follow-up, which enriches the behavioral understanding 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 thorough and well-structured, front-loading the purpose and then providing detailed guidance. While it is longer than minimal, every sentence contributes to clarity and usage, with no redundancy. Could be slightly more concise but remains effective.
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 has only 2 parameters, no output schema, and annotations are neutral, the description covers all necessary aspects: purpose, usage, parameter semantics, behavioral context, and exclusions. It is complete and self-contained for an AI agent to select and 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 100%, so baseline is 3. The description adds value by explaining the kind enum values ('bug', 'idea', 'other') with specific descriptions and provides guidance on what to include in the message (e.g., for bugs: what happened, expected, event IDs) and what not to include (personal details). This goes beyond the schema descriptions.
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 is for reporting bugs, limitations, friction, or ideas about the product 'reassign' itself, using the verb 'Report' and specifying the scope. It distinguishes itself from siblings by noting it is not for changing schedules (use write_events), making the purpose unambiguous.
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 tells when to use the tool (for meta-feedback about the product) and when not to (not for schedule changes, use write_events). It provides detailed guidance on formatting: one concise report per issue, describe what happened, expected, and reproduction steps, and warns against including personal details or schedule contents.
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 dialARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description adds context: it defaults to today and renders an interactive dial. It doesn't contradict annotations. The interactive nature is implied but no mention of permissions or side effects, which is fine given readOnlyHint.
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?
Two sentences, front-loaded with purpose, no wasted words. Each sentence adds value.
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 one optional parameter, clear annotations, and no output schema (since it's a visual render), the description covers when, what, and how to use the tool. Complete for an interactive UI 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?
With 0% schema description coverage, the description fully explains the single parameter: 'Defaults to today; pass `date` (ISO YYYY-MM-DD) for another day.' This adds meaning beyond the schema 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 clearly states it renders the user's day as an interactive 24-hour reassign dial, using a specific verb and resource. It distinguishes itself from sibling tool get_schedule by noting that get_schedule is for text-based reading/reasoning.
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 when to use: 'whenever they want to SEE their day... or to visually move things around.' And provides a clear alternative: 'For reading or reasoning about the plan in text, prefer get_schedule.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
undoUndo recent changesADestructiveInspect
Undo — revert, roll back, take back, or cancel the last — a recent schedule/confirm_schedule create, a write_events / delete_events batch, or a review_day action, 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 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, or review_day (incl. a `batchUndoToken`). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the destructiveHint annotation by detailing token-specific effects (deletes, restores, voids proposals), the 30-minute window, and per-token results, giving the agent a thorough understanding of behaviors.
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 front-loaded with the main purpose and well-organized, but slightly verbose due to multiple clauses explaining token types; each sentence earns its place, but minor trimming could improve conciseness.
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 essential context (tokens, time window, effects of different actions) but lacks detailed output specification for the `results` object; given no output schema, a brief description of the return format would enhance completeness.
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 100% schema coverage, the description enriches the parameter meaning by explaining token types (e.g., batchUndoToken) and their behavioral context, adding significant value beyond the plain 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 clearly identifies the tool as reverting recent actions (schedule, confirm_schedule, write_events, etc.) using undo tokens, and distinguishes it from alternatives like review_day for discarding a day.
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 when to use (with tokens from specific actions) and when not ('to discard a whole day's reflection... use review_day'), providing clear guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_eventsWrite eventsAInspect
Create, update (edit), move/reschedule, shift, or reflect events — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (create | update | move | shift | reflect) 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. For a recurring event choose a scope: 'all' (default), 'future', or 'this' (the last two need occurrenceDate). move changes start/date keeping duration; shift nudges by byMinutes. 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses comprehensive behavioral traits: atomicity by default, partial mode, Google Calendar sync effects, recurring event scope handling, cross-op validation, and interaction with read-only events. No contradictions with annotations (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?
The description is long but well-structured and front-loaded with a summary. Every sentence adds value given the tool's complexity. Slightly verbose but justified; could trim minor redundancies.
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 (5 ops, batch, atomicity, recurrence, calendar sync), the description covers almost every edge case. It describes response structure despite no output schema, making it fully self-contained.
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 adds significant meaning beyond the schema: explaining the purpose of each op, time format, endNextDay, recurrence, scope, and reflect status values. Even with 75% schema coverage, it compensates and provides context for parameters not fully described 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?
The description explicitly states the tool's purpose: 'Create, update (edit), move/reschedule, shift, or reflect events — bulk/batch, one or many in a single call.' It clearly differentiates from siblings like delete_events (for removal) and manage_categories (for categories).
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 detailed guidance on when to use each operation (op) and their specific contexts. It explicitly states when not to use this tool (e.g., for deletion, use delete_events; for read-only events from external calendars, do not edit). It also explains atomic vs. partial modes and cross-op interactions.
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.
Discussions
No comments yet. Be the first to start the discussion!