Workspace369

Create a reminder

reminders_create

Destructive

Create a reminder: a notification that fires at a single point in time (not a calendar event, which has a start and an end; use calendar_create_event for that). A standalone reminder needs a title and an ISO-8601 remind_at. To tie one to a calendar event, pass its event_id and minutes_before (1440 = 24 hours); event_id with remind_at sets an absolute time instead. For all-day events time_zone applies: 24 hours before means 24 elapsed hours before midnight at the start of that date in that zone, not 9 AM. reminder_type is personal (default, notifies only the caller) or workspace (notifies the team members in recipients via channels, default push). Recipients are team-member names or emails; a non-member email must be saved on the client named in client_id or be a workspace address, otherwise the reminder is refused, and unmatched recipients are listed in unresolved_recipients. recurrence repeats it daily, weekly, monthly or yearly. A repeat idempotency_key is safe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "reminders_create"
  }
}

Input Schema

Name	Required	Description
`title`	Yes	What to be reminded of.
`channels`	No	Delivery channels for workspace reminders. Default push.
`event_id`	No	A calendar event's id (from calendar_create_event or calendar_list_events) to link the reminder to.
`priority`	No	Reminder priority.
`client_id`	No	A client whose saved emails may be named in `recipients`. Use the `id` that clients_search returns.
`remind_at`	No	When to fire, an ISO-8601 datetime. Natural language is refused.
`time_zone`	No	IANA time zone used to place a reminder for an all-day event.
`recipients`	No	Team-member names or emails to notify. A non-member email must be saved on `client_id` or be a workspace address.
`recurrence`	No	Repeat the reminder: none, daily, weekly, monthly or yearly.
`description`	No	Longer text shown with the reminder.
`reminder_type`	No	`personal` (default) notifies only the caller; `workspace` notifies the team members in `recipients`.
`minutes_before`	No	With `event_id`: how long before the event to fire, in minutes (1440 = 24 hours).
`idempotency_key`	No	Optional. Repeat a call with the same key to avoid doing it twice.

Output Schema

Name	Required	Description	Default
`deduped`	Yes
`reminder`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / client_id / description

Previous value: -"A client whose saved emails may be named in `recipients`."New value: +"A client whose saved emails may be named in `recipients`. Use the `id` that clients_search returns."

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations: it discloses that invalid recipients cause the reminder to be refused, that unmatched recipients surface in `unresolved_recipients`, default channel behavior, the midnight-relative semantics of `time_zone` for all-day events, and that a repeat `idempotency_key` is safe despite idempotentHint=false. That is exactly the kind of behavioral context annotations cannot carry.

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?

Front-loaded with the core distinction before the parameter detail, and every sentence carries information. It is a dense single paragraph for a 13-parameter tool; a light structural break per usage pattern would improve scannability, but nothing is filler.

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

Completeness5/5

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

For a 13-param, mutation-flagged tool with an output schema, the description covers creation modes, recipient validation, recurrence, idempotency and time-zone edge cases. It even names a return field (`unresolved_recipients`), so an agent knows how to detect partial success.

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

Parameters4/5

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 still adds real meaning beyond the schema for the interaction between `event_id`, `minutes_before`, `remind_at` and `time_zone`, and for recipient resolution rules. It leaves `priority`, `description` and `channels` defaults to the schema, which is acceptable given full coverage.

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

Purpose5/5

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

Opens with a specific verb+resource ('Create a reminder') and immediately defines the resource by contrast: 'a notification that fires at a single point in time (not a calendar event...)'. It names the sibling calendar_create_event and states which job belongs to which tool, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use branches: standalone reminder needs `title` + `remind_at`; event-linked uses `event_id` + `minutes_before`; `event_id` + `remind_at` for absolute time; calendar_create_event for start/end events. Also covers the personal vs workspace choice and the recipient validation precondition. Nothing is left to inference.

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

All Workspace369 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.