reassign
Server Details
Reassign: a circular 24-hour calendar and time-tracking copilot with ADHD-friendly scheduling.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- reassignai/plugins
- GitHub Stars
- 1
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
14 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 SCHEDULED events by name when you don't have an id — fuzzy, case- and accent-insensitive. (For an un-timed parked/backlog item, search get_schedule's backlogQuery instead — those aren't events.) Searches the past week through the next 30 days by default; pass from/to (ISO "YYYY-MM-DD", e.g. "2026-06-01") to widen or shift the window, and optionally filter by areaId, activityTypeId, or timeOfDay. Returns the best matches as { id, date, start, end, name, area, activityType } rows (one per event), each also carrying its source and, when calendar-linked, its calendar name and readOnly flag (a read-only event lives on a calendar the user doesn't own — don't edit or delete it). When two different events tie, ambiguous is true — ask the user which they meant. Two days of the same recurring event are not ambiguous.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Range end, ISO date, e.g. "2026-07-01". Defaults to +30 days. | |
| from | No | Range start, ISO date, e.g. "2026-06-01". Defaults to 7 days ago. | |
| query | Yes | Text to match against event names, e.g. "standup", "gym". | |
| areaId | No | Only match events linked to this area id. | |
| timeOfDay | No | Only match events starting in this part of the day. | |
| activityTypeId | No | Only match events linked to this activity-type id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. Description adds that events from calendars user doesn't own are read-only and should not be edited/deleted, plus mentions return behavior for ambiguous matches.
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 yet thorough: 4 sentences covering purpose, usage, parameters, and return value. Front-loaded with key verb and resource. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully documents return fields (id, date, start, end, name, area, activityType) and special flags like source, calendar, readOnly, ambiguous. Adequate for a search tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: default date range (past week to +30 days), explains ISO date format for from/to, clarifies query matching is fuzzy and case/accent-insensitive, and describes filter parameters.
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?
Uses specific verb 'search for' and states resource 'SCHEDULED events', fuzzy matching, and clearly distinguishes from sibling get_schedule's backlogQuery.
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 (search scheduled events by name without id) and when not (use get_schedule's backlogQuery for un-timed items). Also explains default date range and filter options.
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 a day or week, where your time goes. Returns, in one call, everything needed to reason about the plan: the current time (now), the user's areas and activityTypes, userPreferences, and a days array (each day's events, free slots, and how its time splits across areas/types — blocking load and any non-blocking overlay load reported separately). Call it before scheduling to anchor relative times ('this afternoon'). Defaults to today; pass date for another single day, from+to for an inclusive range, or dates for a specific set (ISO YYYY-MM-DD). Pass compact: true to shrink events for wide ranges, or includeSeries: true to also get recurring masters as series. Each event carries its source ("reassign", else a provider like "google") and, when calendar-linked, its calendar name; an event with readOnly: true is on a calendar the user doesn't own — don't edit or delete it (tell them to change it there). kind is omitted for a normal blocking event; "non-blocking" is an overlay that may overlap others (fasting, an away marker); "reference" is see-only — its hours stay free, don't move/delete/schedule work into it unless asked. A confirmed past day carries a review adherence rollup plus per-event reflect actuals (an unreviewed day has neither) — use it for how a day or week actually went. When a calendar is connected, integrations describes it (connected sources + their calendars, classification fallbacks, and the default sync target); omitted otherwise. For a single day, a one-line weather headline is included when the user has a city — call get_weather only for hourly detail. backlogCount reports how many parked blocks (the inbox of un-timed intentions) the user has; pass includeBacklog: true for the items (top of tray first, up to 50) or backlogQuery to find one by name — place/manage them with manage_backlog. Times are in the user's timezone; an untitled event shows as "(untitled)".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| date | No | ||
| from | No | ||
| dates | No | ||
| compact | No | ||
| backlogQuery | No | Filter the parked blocks by name (fuzzy, case/accent-insensitive) — e.g. "dentist". Implies includeBacklog; use it to FIND a specific parked block by name instead of paging the whole inbox. | |
| includeSeries | No | ||
| includeBacklog | No | Include the parked-block items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their inbox. | |
| backlogPlannedOn | No | Filter the parked blocks to those PLANNED for this day (a block's planned day, or a planned window covering it) — e.g. today's date to answer "what did I plan to get to today?". Implies includeBacklog; composes with backlogQuery. Overdue blocks carry `overdue: true` on the unfiltered read instead. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and openWorldHint=false, and the description aligns perfectly. It goes far beyond annotations by detailing the return structure (now, areas, days, etc.), event properties (source, readOnly, kind), behavior for non-blocking/reference events, review data for past days, and integrations. 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?
The description is thorough but slightly verbose; however, it is well-structured with clear front-loading of the main purpose and logical progression to details. Every sentence adds value, covering behavioral nuances and parameter usage. It earns its length given 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 9 parameters, no output schema, and 13 sibling tools, the description is exceptionally complete. It explains the return object comprehensively, covers all parameter behaviors, integrates with sibling tools, and addresses edge cases (e.g., readOnly events, reference events, review data, weather, backlog).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (3/9 parameters have descriptions). The description compensates fully by explaining all 9 parameters: date, from, to, dates (ISO format), compact, includeSeries, includeBacklog, backlogQuery, backlogPlannedOn. It adds meaningful context beyond the schema, such as defaults and implicit behaviors (e.g., backlogQuery implies includeBacklog).
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 planning data. It distinguishes itself from sibling tools by specifying when to use it (e.g., before scheduling) and explicitly mentioning alternatives like get_weather for hourly detail and manage_backlog for inbox management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: call it before scheduling to anchor relative times, defaults to today, explains parameter combinations for different date ranges, and advises when to use compact, includeSeries, includeBacklog, etc. It also warns against editing readOnly events and tells users to change them in the source calendar.
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_backlogManage backlogADestructiveInspect
Write to the backlog — the inbox of PARKED time-blocks: intentions captured without a time yet ("wash the car", "call the dentist"). To READ parked blocks, use get_schedule (backlogCount, then includeBacklog: true for the items or backlogQuery to find one by name); THIS tool is the write surface. Pass ops, an array where each item has an op plus its fields — one or many in a single call, atomic by default (if any op fails nothing is written; pass partial: true for best-effort). Ops: capture creates a parked block (name, optional notes/durationHours, area/activityType by id or name, and an optional plannedDate or plannedDate+plannedUntil window — the still-untimed day(s) it's meant for); update edits one by id (plannedDate: null moves it back to Someday; a task-app-linked block's date is provider-owned and refused); remove deletes one by id (reversible — the response returns an undoToken); schedule PLACES a parked block on the dial at date+start (its duration sizes it; pass recurrence to make it repeat) and removes it from the inbox; park MOVES a dial event (by eventId) back into the inbox. Park only works on a native or owned-calendar one-off that hasn't been reviewed — a recurring, sleep, reviewed, or not-owned event is refused with a reason (edit it on the dial instead). Parking a calendar-linked event removes its calendar copy but remembers the calendar, so re-scheduling it republishes there. Backlog is a Pro feature. schedule and park are inverses: to undo a schedule, park it again, and vice-versa.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | ||
| partial | No | Best-effort mode instead of the default all-or-nothing. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint: true, but description adds atomicity, partial mode, undo token, parking restrictions (recurring/sleep/reviewed/not-owned events refused), and calendar-linked behavior. Adds significant behavioral 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?
Description is lengthy but every sentence serves a purpose. Front-loaded with purpose and usage. Could be slightly more concise, but given complexity, it's 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?
Complex tool with multiple ops and no output schema. Covers each op's behavior, constraints, reversibility, error cases, feature flag (Pro), and edge cases (e.g., task-app-linked blocks). Fully 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 50% due to opaque ops array, but description thoroughly explains each op's required and optional fields (e.g., plannedDate: null clears, durationHours sizes the block). Adds meaning 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 explicitly states it's for writing to the backlog (parked blocks), contrasts with reading tools (get_schedule), and lists all ops. It distinguishes itself from siblings like schedule and confirm_schedule.
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?
Directly tells when to use this tool vs get_schedule for reading. Explains atomic vs partial mode, and when to use schedule vs park (inverses). Provides clear context for each op.
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. (If you already know both an exact start AND end, use write_events create instead.) YOU resolve any relative phrasing ("tomorrow", "next monday", "this afternoon") into the structured fields; this tool does no date parsing. Pass requests, each with a name, duration ("90m", "1h30", "2h"), a date (ISO "YYYY-MM-DD"), and EITHER an exact start ("HH:MM", 24-hour) to place there, OR an earliest/latest ("HH:MM") window to search within (map "afternoon" → earliest "13:00", latest "18:00"), OR neither to search the whole working day. For each request: if exactly one conflict-free time fits it is created immediately with an undoToken; otherwise you get ranked options and a commitToken — call confirm_schedule to pick one (or set autoCommitBest: true on a flexible request to book the top pick in one shot and skip that round-trip). Requests are placed in order and kept off each other's committed slots. Each request may carry a request_id so retries don't double-book. If the user has a Google Calendar connected with a default sync calendar, a scheduled event is also pushed to Google, the same as a dial create. The response reports per-request results (each with its 0-based index).
| Name | Required | Description | Default |
|---|---|---|---|
| render | No | When the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. | |
| requests | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits beyond annotations: it creates events, handles conflicts with tokens, supports idempotency via request_id, and explains autoCommitBest. Annotations already show non-read-only and non-destructive, but the description adds rich detail on the scheduling workflow and side effects like Google Calendar sync.
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 somewhat long but structured with a clear first sentence stating the purpose, followed by usage guidance and parameter semantics. It is front-loaded and each sentence adds value, though some details could be more concise.
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 requests, flexible vs exact scheduling, commit tokens, idempotency, external calendar sync), the description covers all necessary aspects for an agent to use it correctly, despite lacking an output schema. It explains the workflow and key behaviors comprehensively.
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 meaning beyond the schema by explaining the logic of requests, the meaning of earliest/latest windows, autoCommitBest flag, and the fact that the tool does no date parsing. With 50% schema coverage, the description compensates well, though some parameter details are already 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 clearly states it finds conflict-free time and places events, and distinguishes from sibling write_events by specifying when to use that alternative. This provides a specific verb+resource and explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'If you already know both an exact start AND end, use write_events create instead', and explains when to use autoCommitBest vs. confirm_schedule. Provides clear context for when to use this tool versus alternatives.
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, a review_day action, or a manage_backlog remove, using the undoTokens they returned. Pass tokens. Each works only while still active and within its 30-minute window; a schedule/confirm_schedule token deletes the event it created, a write_events / delete_events / review_day / manage_backlog token reverses the whole change (deletes what it created, restores what it changed/removed), and a batchUndoToken from a multi-event schedule call removes the events that batch auto-created and voids its open proposals (times you confirm from proposals keep their own undo tokens). This needs a token from a recent call — to discard a whole day's reflection by date instead, use review_day with action 'discard'. Returns per-token results.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | Yes | undoToken(s) returned by schedule, confirm_schedule, write_events, delete_events, review_day, or manage_backlog (incl. a `batchUndoToken`). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds crucial context: token expiration, specific reversal behaviors per token type (e.g., schedule token deletes created event, batchUndoToken remove events and voids proposals). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but dense with precise information. Every sentence adds value, though it could be slightly tightened. It front-loads the core purpose and then details specifics.
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 single parameter and no output schema, the description adequately covers token types, behaviors, and return value (per-token results). It is sufficiently complete for an agent to understand the tool's capabilities and edge cases.
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 covers 100% of parameters with description on tokens field. The tool description adds important nuance, such as acceptable token types (including batchUndoToken) and per-token behavior, beyond the schema's generic description.
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 from specific actions (schedule, confirm_schedule, etc.) using tokens, and distinguishes from sibling tools like review_day. The verb 'undo' is specific and the resource scope is well-defined.
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 describes when to use the tool (after obtaining tokens from recent calls) and provides an alternative for discarding a day's reflection via review_day with 'discard'. Gives clear conditions on token validity (30-minute window).
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, reflect, or manage a block's checklist — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (create | update | move | shift | reflect | checklist) plus that op's fields; a single edit is just a 1-item array. Times are 24-hour HH:MM; for an event crossing midnight set endNextDay=true. reflect records how a PAST planned event actually went (kept | skipped | changed | added, with an optional actual time) — it never renames or re-times the plan; target one occurrence of a recurring event by its seriesId@YYYY-MM-DD id. checklist manages a block's microtasks: pass items to set/replace the ordered list (a template edit — whole series, or one occurrence with scope 'this'), or check/uncheck (by item id or exact text) to tick them off for a single occurrence; the current microtasks + each one's done state come back on a get_schedule read as the event's checklist. For a recurring event choose a scope: 'all' (default), 'future', or 'this' (the last two need occurrenceDate). To re-time an existing event use move (new start/date, duration kept) or shift (relative nudge by byMinutes); use update only to also rename, re-kind, re-area, or resize (change end). If you know the duration but not a conflict-free time (or only a rough window), use schedule instead of a create. By default the whole batch is atomic: if ANY op fails validation (e.g. a conflict), nothing is written and the failing ops are returned as errors — fix and resend. Pass partial: true for best-effort (apply what's valid). Ops apply in order as one transaction and are checked against each other: two creates can't double-book a slot, and an earlier move frees a slot a later op can reuse. Target each event id at most once per batch. Reference an area/activity type by id or by areaName/activityTypeName; create new ones first with manage_categories. If the user has a Google Calendar connected, creating or editing a calendar-linked event (or one created under their default sync calendar) also pushes the change to Google — the same as editing on the dial; don't edit an event get_schedule/find_event marked readOnly (it's from a calendar the user doesn't own and the change would silently revert). To remove events or clear a day use delete_events. The response reports applied, failed, skipped (validated but not written because the atomic batch was rejected), and per-op results (each with its 0-based index).
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | ||
| render | No | When the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. Otherwise the change reaches an open dial only if the host forwards this result. | |
| concise | No | Drop the human-readable `suggestedFollowup` prose from the response (the structured `undoToken` is still returned). Saves tokens. | |
| partial | No | Best-effort mode: apply the ops that succeed and report the rest as errors, instead of the default all-or-nothing. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already indicating non-readOnly and non-destructive, the description adds critical behavioral details: atomic vs partial mode, Google Calendar sync, conflict checking across ops, response structure, and that reflect never renames/re-times the plan.
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 very long and contains some redundancy (e.g., multiple mentions of scope). While it is well-structured and front-loaded with the main purpose, it could be more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple ops, atomicity, recurring events, Google sync), the description is thorough. It covers response structure, parameter explanations, and edge cases. Missing only an explicit mention of error handling details, but overall very 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 75%, but the description goes beyond by explaining the ops array structure, time format, scope/occurrenceDate for recurring events, and the distinction between move/shift/update. Some schema descriptions are also present, but the 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: 'Create, update (edit), move/reschedule, shift, or reflect events — bulk/batch, one or many in a single call.' It differentiates from sibling tools by explicitly referencing delete_events for removal and schedule for when time is uncertain.
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 this tool versus alternatives, e.g., 'If you know the duration but not a conflict-free time... use schedule instead of a create.' It also advises against editing readOnly events and recommends creating categories first with manage_categories.
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!