Skip to main content
Glama
Sign In

ThreadPage

by page.thread
OverviewDiscussionsAdmin

Remove a reminder

remove_reminder
DestructiveIdempotent

Remove the person's reminder on a Thread (omit note_id) or on one Note in it, only when they asked for that; to change its time, use set_reminder with replace. They can still bring it back in ThreadPage for a day (Undo). Can add notes removes only the reminders it set. Answers removed: true with the reminder, or false when there was none.

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": {
      "thread_id": "<thread_id>"
    },
    "name": "remove_reminder"
  }
}

Input Schema

NameRequiredDescriptionDefault
note_idNoA Note's id for its own reminder; omit for the Thread's general reminder. A live Note out of Trash, wherever it moved, in such a Thread.
thread_idYesA Thread you may add notes to (list_threads, search or a read).
operation_idNoOptional: a new UUID for this write, to read its receipt with get_operation and to repeat it safely after a lost answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already carry destructive=true, idempotent=true and readOnly=false, so the safety profile is covered; the description adds genuinely new context: a one-day Undo window in ThreadPage and the fact that ownership limits which reminders can be removed. It also discloses the response shape (removed: true with the reminder, false when none), which reconciles with idempotentHint. The permissions sentence ("Can add notes removes only the reminders it set") is tersely worded and takes a re-read.

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?

The scoping rule is front-loaded and there is little waste; almost every clause carries information (alternative tool, undo window, ownership limit, return value). It loses a point for the compressed, awkward clause about ownership and for the mid-sentence UI reference to ThreadPage, which is not obviously relevant to an API caller.

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 three-parameter destructive write with no output schema, it covers scope selection, the alternative for the neighboring intent, reversibility, permission limits, and the return value. The only gap is that the ownership/undo details are phrased in end-user product terms rather than API terms, leaving a little ambiguity about what an agent should do when the removal fails.

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 note_id's scope, thread_id's access constraint, and operation_id's idempotency-replay purpose. The description restates the omit-note_id-versus-supply-it distinction but adds no format or edge-case detail beyond the schema. Baseline 3 applies since the schema does the heavy lifting.

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?

States a specific verb (remove) and resource (reminder) plus its two scoping variants: Thread-level when note_id is omitted, Note-level when supplied. The sibling set_reminder is named as the contrasting operation, so an agent can route between them 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 an explicit precondition ("only when they asked for that") and an explicit alternative for the adjacent intent ("to change its time, use set_reminder with replace"). It also states the actor restriction ("Can add notes removes only the reminders it set"), which tells the agent when the call is not permitted.

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

All ThreadPage 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