Skip to main content
Glama

reminder_set

Schedule a reminder. One-time reminders fire at a specific datetime. Recurring reminders fire on a schedule (daily, weekly, every N days, or every N minutes). Optionally scope to a thread or target another agent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeNoTime of day HH:MM for daily/weekly/every_n_days (e.g. '09:00'). Required for daily/weekly/every_n_days.
reasonYesWhat this reminder is for (you'll see this when it fires)
agent_idNoAgent ID (required when calling from MCP; ignored in agentic mode).
datetimeNoISO datetime for one_time. Required for one_time. Either with an offset ('2026-04-01T09:00:00+03:00') or without one plus `timezone` ('2026-04-01T09:00:00' + timezone 'Europe/Moscow'): a datetime with no offset is read in `timezone`, and in UTC only when that is omitted.
timezoneNoIANA timezone (e.g. 'Europe/Moscow'). Defaults to UTC.
thread_idNoOptional thread ID to scope the reminder to. Omit for workspace-level reminders.
days_of_weekNoDays for weekly: 0=Mon, 1=Tue, 2=Wed, 3=Thu, 4=Fri, 5=Sat, 6=Sun. Required for weekly.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
interval_daysNoFor every_n_days: fire every N days (min 2).
schedule_typeYesone_time = fires once at datetime. daily = fires daily at time. weekly = fires on specific days_of_week at time. every_n_days = fires every N days at time. interval = fires every N minutes.
interval_minutesNoFor interval: fire every N minutes (5-1440).
target_agent_slugNoOptional: activate a different staff member instead of yourself when the reminder fires.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
      +  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
      +  "type": "integer"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO datetime for one_time (e.g. '2026-04-01T09:00:00+03:00'). Required for one_time."New value: +"ISO datetime for one_time. Required for one_time. Either with an offset ('2026-04-01T09:00:00+03:00') or without one plus `timezone` ('2026-04-01T09:00:00' + timezone 'Europe/Moscow'): a datetime with no offset is read in `timezone`, and in UTC only when that is omitted."
  3. Added
  4. Removed
  5. First observed

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description only needs to add context. It usefully discloses that reminders fire on a schedule and can be scoped to a thread or another agent, but says nothing about duplicate-creation behavior (idempotentHint=false), permissions, or limits on how many reminders can be scheduled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the action front-loaded and no padding; the schedule taxonomy in sentence two is the only part that partially duplicates the schema's schedule_type enum. Efficient overall, with a minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation tool with no output schema and safety covered by annotations, the description covers the conceptual model (one-time vs recurring, scoping) adequately, and the schema fills in every parameter's format. It omits only what happens at fire time and delivery semantics, a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 12 parameters in detail. The description restates the schedule families and the optional thread/agent scoping at a high level but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ("Schedule a reminder") and immediately enumerates the scheduling models it supports, so an agent knows exactly what the tool produces. It does not explicitly contrast itself with reminder_cancel or reminder_list, which keeps it at a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful mode-selection guidance (one-time vs daily/weekly/every N days/every N minutes), which implies when each variant applies. However, it never states when not to use the tool, nor points to sibling tools like reminder_cancel or reminder_list, so usage guidance remains implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.