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.6/5 across 10 of 10 tools scored. Lowest: 4/5.
Each tool has a clearly distinct purpose: schedule proposes times, confirm_schedule accepts, get_schedule reads, find_event searches, write_events creates/edits, delete_events removes, undo reverses, show_day renders, manage_categories manages taxonomy, send_feedback is meta. No overlap.
All tool names follow a consistent verb_noun pattern with underscores (e.g., get_schedule, write_events, manage_categories). Even single-word names like schedule and undo fit the verb style. No mixing of conventions.
10 tools is well-scoped for a scheduling assistant: covers reading, searching, creating, editing, deleting, undoing, managing categories, visual day, and feedback. Each tool earns its place without bloat.
The tool set provides full CRUD lifecycle for events (create via schedule and write_events, read via get_schedule and find_event, update via write_events, delete via delete_events), plus undo, category management, and feedback. No obvious gaps for the domain.
Available Tools
10 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?
Beyond annotations (destructiveHint=true), description adds important behaviors: the atomic vs partial execution, undo capability with 30-minute window, and Google Calendar deletion behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Somewhat lengthy but each sentence is informative and front-loaded with main purpose. Could be slightly more concise, but every piece of information is 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?
For a complex tool (4 params, nested objects, destructive, no output schema), the description covers all aspects: purpose, operation types, atomic vs partial, undo, Google Calendar integration, readOnly limitation, and response structure (applied, failed, skipped, results). It 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 high, but description adds depth to 'ops' by explaining the structure of delete (with scope and occurrenceDate) and clear (with date and optional 'to' range). It clarifies the role of 'partial' parameter. The remaining params (render, concise) are well-described in 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 'Delete events or clear whole days — bulk/batch, one or many in a single call.' It specifies the verb (delete/clear) and resource (events/days), and distinguishes from siblings like write_events for creation/editing.
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 this tool (delete/clear) vs alternatives ('To create or edit events use write_events'). Also explains when not to use (readOnly events from calendars not owned) and provides context for Google Calendar integration and partial mode.
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_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 — sleep, fasting — 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 (sleep, fasting) 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). 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/aiContext) 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), defaultArea/defaultType (referencing the top-level taxonomy), and the free-text instructions hint — plus writable, showOnDial, and enabled. 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. 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?
Exhaustively explains return structure (now, areas, types, days with events/free slots/load breakdowns), event properties (source, calendar, readOnly, kind), and integrations. Discloses that readOnly events should not be edited/deleted, and explains kind meanings (blocking, non-blocking, reference). No contradiction with readOnlyHint 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?
Well-structured: starts with high-level purpose, then details return structure, parameter options, and special fields. Somewhat verbose but every sentence adds valuable context. Not overly concise, but given complexity, it's appropriately front-loaded.
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 thoroughly documents the response and its interpretation. Covers all six parameters, edge cases (untitled events, timezone), and integrations. Complete for a complex read tool with rich return data.
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 0% coverage (no parameter descriptions), but the description fully compensates: explains date, from, to, dates, compact, includeSeries with examples and use cases. Adds meaning like default behavior and formatting (ISO YYYY-MM-DD).
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 reads the calendar and returns agenda, availability, and overall plan. It distinguishes itself from siblings by noting it returns everything needed in one call, and positions itself before scheduling tasks. The verb 'read' and resource 'calendar/schedule' are specific.
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 clear context: call before scheduling, defaults to today, parameter options for single day, range, or set. Suggests `compact: true` for wide ranges and `includeSeries` for recurring events. Does not explicitly mention when not to use or compare to siblings like 'show_day', but still strong guidance.
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.
scheduleSchedule from natural languageAInspect
Schedule one or more events from natural-language times — the easiest way to place work without computing slots yourself. Pass requests, each with a name, duration ("90m", "1h30", "2h"), and when ("tomorrow morning", "next monday at 3pm", "2026-06-04T15:30", "2026-06-01"). 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. 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?
The description discloses key behaviors beyond the annotations: conflict resolution, ordering of requests, idempotency, Google Calendar sync, and the return of undoToken/commitToken. It does not mention rate limits or authorization, but annotations provide minimal cues, so the description carries the burden well.
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 well-structured and front-loads the purpose. It conveys a lot of information efficiently, but it is somewhat lengthy (multiple sentences) and could be tightened slightly without losing meaning.
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 and absence of an output schema, the description explains the response structure (undoToken, options, commitToken, per-request results with index) and references confirm_schedule. However, it lacks details on exact response format, error handling, and partial failure scenarios, leaving some ambiguity.
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 input schema has 50% description coverage, and the description adds context for some parameters like duration and when (examples of format) and request_id for idempotency. However, it does not explain parameters like render, areaId, areaName, activityTypeId, activityTypeName, recurrence, or notes, so it only partially compensates for the schema's lack of 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's purpose: scheduling one or more events from natural-language times. It distinguishes from sibling tools by explaining the conflict resolution flow and mentioning confirm_schedule as a follow-up, making it clear when to use this tool versus others like delete_events or 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?
The description provides clear context on when to use the tool, including the natural-language input and idempotency via request_id. It also explains the conflict scenario and the need for confirm_schedule. However, it lacks explicit guidance on when to use alternatives like get_schedule or find_event instead.
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 — recent schedule/confirm_schedule creates or a write_events / delete_events batch, 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 token reverses the whole batch (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). Returns per-token results.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | Yes | The undoTokens from schedule/confirm_schedule. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details destructive behavior (deleting events, restoring changes) and adds context beyond annotations (time window, per-token results, batch undo specifics). Aligns with destructiveHint=true.
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?
Efficiently uses a single paragraph with front-loaded purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly covers token types, effects, time constraints, and output. No output schema, but description mentions 'per-token results', providing necessary 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?
Adds substantial meaning beyond the schema: explains token types, their sources, and behaviors per type. Schema coverage is 100% but description enriches understanding.
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 reverts recent changes using undo tokens, specifying the actions it can undo (schedule, confirm_schedule, write_events, delete_events). It distinguishes itself from sibling tools by referencing them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (after relevant actions) and constraints (token lifetime, 30-minute window). It lacks explicit 'when not to use' but the guidance is strong otherwise.
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, or shift events — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (create | update | move | shift) 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. 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 important behavioral traits beyond annotations: atomic transaction behavior, conflict checking, Google Calendar sync for linked events, the readOnly warning, and the response structure (applied, failed, skipped). Annotations only indicate non-readOnly, non-destructive, non-open-world; description adds rich context.
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-organized, starting with the primary purpose then detailing operations, scoping, atomicity, and special cases. Every sentence adds value, though a few extra details could be streamlined. Overall efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations, recurring events, Google sync, atomicity), the description is comprehensive. It covers all operation types, scope handling, conflict rules, partial mode, response format, and interactions with external systems (Google Calendar). No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%; the description adds meaning for parameters like time format (24-hour HH:MM), endNextDay for midnight crossing, scope options for recurring events, and the distinction between move and shift. It enhances understanding beyond schema definitions.
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 what the tool does: 'Create, update (edit), move/reschedule, or shift events — bulk/batch, one or many in a single call.' It uses specific verbs and resources, and is well-distinguished from sibling tools like delete_events (for removal) and schedule (assumed different).
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 guidance on when to use alternatives ('To remove events or clear a day use delete_events'), explains atomic vs. partial mode, and mentions pre-requisites like creating areas/activity types with manage_categories. It could be more explicit about when to use schedule vs. write_events, but overall clear.
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!