NudgeBell

Create an escalating reminder

create_reminder

Schedule a reminder that escalates the way the user set it and stops when they acknowledge. It fires from NudgeBell's own servers, so it still happens if this agent, this machine, or this conversation is long gone.

A reminder is one step or up to five. Each step is a channel, a message, and how many minutes after the trigger it fires. A single email, a single call, or a chain across any channels in any order with any gaps are all fine: build exactly what the user asked for, and do not add steps or channels they did not ask for. If the user acknowledges at any step (presses 1 on the call, taps the link in a text, clicks the button in the email), every remaining step is cancelled automatically.

You do not choose who is contacted. NudgeBell only ever contacts the account owner's own verified phone and email; there is no recipient parameter and requests that try to add one are rejected. You also do not need to send a timezone — the account's timezone is used.

Input Schema

TableJSON Schema

Name	Required	Description
`steps`	Yes	The escalation chain, in order. 1 to 5 steps.
`title`	Yes	Short label for the reminder, e.g. 'Call the dentist'. Max 100 characters.
`timezone`	No	Optional IANA timezone. Normally omit this — the account's own timezone always wins and a conflicting value is ignored.
`recurrence`	No	Repeat the whole escalation chain on this cadence, starting at trigger_at and always at the same local time in the account's timezone. Use 'yearly' for birthdays and anniversaries, 'monthly' for renewals. Default 'none'. Monthly/yearly dates on the 29th-31st fall to the last day of a shorter month.
`trigger_at`	Yes	When the first step fires. Prefer plain local time in the user's own words converted to 'YYYY-MM-DDTHH:mm' (e.g. '2026-09-05T08:00' for tomorrow at 8am) — it is interpreted in the account's timezone. A full ISO-8601 instant with an offset or 'Z' also works. Must be in the future and at most 5 years ahead.
`description`	No	Optional notes. Max 500 characters.
`idempotency_key`	No	Optional. Pass a stable value if you might retry this call — retries with the same key return the original reminder instead of creating a second one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=false), the description discloses that reminders fire from NudgeBell's own servers and survive agent/machine/conversation loss, that acknowledging any step cancels all remaining steps, and that recipient-selection attempts are rejected. These are high-value behavioral traits an agent cannot infer from annotations or schema alone.

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?

The description is dense but every sentence contributes: opening behavior, escalation-chain rules, acknowledgment semantics, and the no-recipient/timezone guardrails. The most important behavioral contract is front-loaded before lower-level constraints.

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 seven-parameter creation tool with rich schema descriptions, the text covers scheduling semantics, constraints, and edge cases (acknowledgment cancels remaining steps, no recipient, timezone fallback). It does not state the return shape, which matters slightly more because there is no output schema, but the omission is minor for an intuitive create operation.

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 schema already documents every property, its constraints, defaults, and channel-specific behavior. The description adds useful global guardrails (no recipient, don't add steps) but no new parameter-level meaning, so the high-coverage baseline applies.

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?

The description opens with a specific verb and object: 'Schedule a reminder that escalates the way the user set it and stops when they acknowledge.' It also clarifies the resource as a multi-step escalation chain, which naturally distinguishes it from sibling tools that cancel, list, pause, or retrieve reminders.

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

Usage Guidelines4/5

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

There is no explicit comparison such as 'to view reminders use get_reminder', but the creation intent is unmistakable and the description gives strong usage guardrails: build only requested steps, don't add a recipient because NudgeBell only contacts the account owner, and normally omit timezone. This gives clear context without formal exclusions.

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

All NudgeBell 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.

Resources

Need Help?