Skip to main content
Glama

AgentMart

by ai.ciphyr.agentmart
OverviewDiscussionsAdmin

Change, pause or resume a reminder to my human

reminder_update
DestructiveIdempotent

Pause or resume a reminder, or change its text, rule or time zone.

Input Schema

NameRequiredDescriptionDefault
textNoNew text, same rules.
repeatNoNew rule: daily or weekly.
statusNopaused: no emails; active: from the next time after now.
time_zoneNoNew IANA time zone, for example Europe/Istanbul. Left out: the current one stays.
instance_idYesUtility instance id from buy or list_utilities.
reminder_idYesreminder id (rem_...) from reminder_create or reminder_list.
passport_tokenNoYour amp_ token, only if you have no app sign-in and cannot send a header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "instance_id": "orm_exampleexampleexample2",
+    "reminder_id": "rem_exampleexampleexample2",
+    "status": "paused"
+  }
+]
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."New value: +"Your amp_ token, only if you have no app sign-in and cannot send a header."
  2. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."New value: +"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."
    • addedInput schema / properties / passport_token / maxLength
      Added value: +200
    • removedInput schema / properties / passport_token / pattern
      Removed value: -"^amp_(?:s_)?[A-Za-z0-9_-]{43}$"
  3. Added

TDQS

B3.4/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the risk profile is known. The description adds nothing beyond that: it does not say that only the supplied fields change, that resuming recalculates the next send time, or what happens to paused reminders in the interim — all of which is covered by the schema, not the prose. The description is essentially a restatement of the parameter names.

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

Conciseness5/5

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

A single short sentence that front-loads the operations and lists the mutable fields with zero filler. Nothing is padded or repeated.

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?

With 7 parameters fully documented in the schema, rich annotations, and no output schema to explain, little more is strictly required. The remaining gap is minor: the description does not say that all optional fields are applied as a partial update, though the schema hints at this for time_zone.

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%, and the parameters carry their own semantics (e.g. 'paused: no emails; active: from the next time after now', 'Left out: the current one stays'), so the baseline of 3 applies. The description's field list mirrors the schema without adding any detail about formats, defaults, or interactions between fields.

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 names a specific verb set (pause, resume, change) tied to a specific resource (a reminder), and enumerates the mutable facets: text, rule, time zone. That is enough to distinguish it from reminder_create, reminder_delete and reminder_list among the siblings, though it does not name any of them explicitly.

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?

The list of supported operations implies when the tool applies, but there is no explicit guidance on prerequisites (a reminder_id from reminder_create or reminder_list), no statement about when to use reminder_delete instead of pausing, and no mention that at least one of the optional fields should be supplied.

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

All AgentMart toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources