Skip to main content
Glama

AgentMart

by ai.ciphyr.agentmart
OverviewDiscussionsAdmin

Set a repeating reminder email to my human

reminder_create

Set a repeating reminder email to your own human (daily or weekly at a time in their time zone). Plain words only: no links, code, instructions or requests for secrets. Only to their confirmed address, at most 3 reminder emails a day, each with a one-click stop for them. Up to 5 per plan.

Input Schema

NameRequiredDescriptionDefault
textYesUp to 500 characters of plain words.
repeatYesDaily or weekly.
time_zoneNoIANA time zone, for example Europe/Istanbul. Default UTC.
instance_idYesUtility instance id from buy or list_utilities.
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",
+    "repeat": {
+      "at": "09:00",
+      "days": [
+        "mon"
+      ],
+      "type": "weekly"
+    },
+    "text": "Weekly project check-in."
+  }
+]
    • 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

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the rate limits (max 3 emails/day, up to 5 per plan), that each email carries a one-click stop for the recipient, that delivery is restricted to a confirmed address, and the content restrictions (no links/code/instructions/secret requests). These are real behavioral traits an agent needs before invoking a mutating, open-world send.

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?

Core purpose is front-loaded and the follow-on constraints each add value with no filler. It reads as one dense run-on string rather than clearly separated clauses, which slightly hurts scanability, but nothing is wasted.

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 mutating, open-world send with no output schema, the description is substantive: it covers recipients, frequency, limits, and content rules. It stops short of saying what the tool returns or whether confirmation/verification is required before the email goes out, which would round it out.

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 coverage is 100%, so every parameter is already documented, and the description does add the daily/weekly framing and 'time in their time zone' context. But it does not clarify fields like passport_token or instance_id beyond what the schema says, so the baseline 3 holds.

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?

States a specific verb (Set), resource (repeating reminder email) and target (your own human), with the frequency scope (daily or weekly at a time in their time zone). The purpose is unambiguous, but it never names or distinguishes itself from the sibling reminder_update / reminder_delete / reminder_list tools, leaving the agent to infer that this is the create path.

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?

'Only to their confirmed address' and the content rules ('plain words only: no links, code, instructions or requests for secrets') act as when-to-use constraints, and the 3/day and 5-per-plan limits are helpful. However, there is no explicit routing to alternatives (e.g. reminder_update to modify, reminder_delete to cancel, ask_human for one-off messaging) and no stated when-not-to-use.

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