Skip to main content
Glama
Sign In

Workspace369

by com.workspace369
OverviewDiscussionsAdmin

Update a reminder

reminders_update
Destructive

Change an existing reminder by id (from reminders_list): title, description, remind_at (ISO-8601), priority or channels. Only the fields passed change. There is no separate snooze action: moving remind_at postpones a reminder and re-arms delivery, so one that already fired fires again at the new time. Editing keeps the reminder's id and its link to the invoice or task it came from, whereas closing and re-creating gives a new id and files the original under Canceled. A completed or canceled reminder cannot be edited. Times are ISO-8601 only.

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": {
      "id": "<id>"
    },
    "name": "reminders_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe reminder's id (from reminders_list).
titleNoNew title.
channelsNoNew delivery channels.
priorityNoNew priority.
remind_atNoNew time, an ISO-8601 datetime. Moving it postpones the reminder and re-arms delivery.
descriptionNoNew description.

Output Schema

NameRequiredDescriptionDefault
changesYes
reminderYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: annotations only flag destructive/not-idempotent/open-world, while the description explains partial-update semantics ('only the fields passed change'), the re-arming side effect of moving remind_at, preservation of id and invoice/task linkage, and the ineligibility of completed/canceled reminders.

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 action and affected fields, then qualification. It is dense but every sentence carries useful decision content; the ISO-8601 note is stated twice (mid-sentence and again at the end), a minor redundancy.

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 mutation tool with rich annotations and a dedicated output schema, the description covers everything an agent needs: identification of the record, mutable fields, partial-update behavior, side effects, and blocked states. Return values are correctly left to the output schema.

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 the baseline is 3, but the description adds genuine meaning: the partial-update contract ('only the fields passed change'), the relationship between remind_at edits and delivery re-arming, and the source of `id` (reminders_list). It only lightly restates enum values already in the schema.

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?

Names a specific verb (update/change) and resource (an existing reminder by `id`) and enumerates exactly which fields are mutable. It clearly distinguishes itself from siblings reminders_create, reminders_close, and reminders_list.

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 (partial edits by id from reminders_list), when-not-to-use (completed or canceled reminders cannot be edited), and an alternative path (closing and re-creating yields a new id). It also resolves a likely ambiguity by stating there is no separate snooze action.

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

All Workspace369 toolsInspect
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.

Resources