Reminders your agent creates: email, WhatsApp, SMS or call, in steps you set. Stops on acknowledge.
Scored across 7 tools
Most tools have clearly distinct purposes, and the pause/cancel distinction is extremely well handled. The only possible confusion is between get_reminder and get_reminder_status, since both can report on the current occurrence's progress, though the status tool is clearly targeted at live delivery/acknowledgment.
All tools follow a consistent verb_noun snake_case pattern: create_reminder, list_reminders, get_reminder, get_reminder_status, pause_reminder, cancel_reminder, and get_account. This makes the tool surface predictable and easy to navigate.
Seven tools is well-scoped for a reminder/escalation service. Each tool covers a meaningful part of the workflow—account context, listing, reading, live status, pausing, cancelling, and creating—without unnecessary redundancy or bloat.
The core reminder lifecycle is covered: create, read, list, status, pause, and cancel. The main gap is the lack of an update/resume tool; pause is explicitly reversible only from the dashboard, so agents cannot modify a reminder or resume one directly.
DESTRUCTIVE AND IRREVERSIBLE. Cancelling permanently DELETES the reminder, its escalation steps and its entire delivery history from NudgeBell. Nothing is archived and there is no undo — not from this API and not from the dashboard.
Only use this when the user explicitly says delete, cancel for good, or stop permanently. For anything else — 'not right now', 'skip today', 'hold off', 'I'm on holiday', or any doubt at all — use pause_reminder, which stops the chain, keeps the history, and can be resumed from the dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes | The reminder's id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the destructive and irreversible nature, including deletion of escalation steps and delivery history, no archiving, and no undo from API or dashboard. This exceeds the burden typically placed on descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the critical warning, then provides clear usage criteria and alternative. Every sentence earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema, the description covers the action, consequences, usage boundaries, and alternative. Nothing an agent needs to decide correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter (reminder_id) is described in the schema. The description doesn't add extra parameter-level detail, but with full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a reminder permanently, with a specific verb ('delete') and resource ('reminder'). It distinguishes itself from pause_reminder by emphasizing irreversibility and permanent deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user says delete, cancel for good, stop permanently) and when not to use (not right now, skip today, hold off, holiday, any doubt), and names the alternative (pause_reminder). This is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden — and it delivers thoroughly. It discloses server-side execution ('fires from NudgeBell's own servers, so it still happens if this agent... is long gone'), automatic cancellation of remaining steps on acknowledgement, the account-owner-only contact restriction, and rejection of recipient requests. It even surfaces that 'the create response reports the estimate,' which matters for a cost-incurring mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense paragraphs, front-loaded with the core behavior, then step structure, then constraints. Nearly every sentence earns its place; the only minor waste is that the acknowledge-and-cancel behavior is stated in the opening sentence and re-explained in detail in the second paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with a nested steps array, no annotations, and no output schema, the description covers the behavioral essentials: escalation semantics, step limits, cancellation, server persistence, and recipient/timezone constraints. The main gap is the response shape — the response estimate is only mentioned inside the channel enum description rather than in the main description — but an agent still has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 invocation-level meaning the schema cannot express: don't pad the steps array with unrequested channels, there is no recipient field to fill, and the timezone parameter should normally be omitted. These notes actively steer agent behavior rather than restating property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Schedule a reminder' — and characterizes the behavior precisely: 'escalates the way the user set it and stops when they acknowledge.' The creation intent is unambiguous and clearly distinct from the sibling set (cancel_reminder, get_reminder, pause_reminder, list_reminders), so an agent can route to this tool without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context with exclusionary rules: 'build exactly what the user asked for, and do not add steps or channels they did not ask for,' 'there is no recipient parameter and requests that try to add one are rejected,' and 'you do not need to send a timezone.' These tell the agent when NOT to do something, which strongly shapes invocation. It stops short of explicitly naming alternative tools for when-to-use decisions, but the create-vs-manage split across siblings is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's verified contacts (the only places a reminder can ever be delivered), timezone, plan, credit balance and active-reminder limit. Read this first if you are unsure whether a phone call is possible or whether there are enough credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses a meaningful constraint — verified contacts are 'the only places a reminder can ever be delivered' — and implies a read-only current-state snapshot through the credit/limit feasibility framing. It does not address auth requirements, data freshness, or failure modes, which are notable gaps given annotations are absent, though the 0-parameter read operation is inherently low-risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first specifies the returned fields, and the second states the decision trigger for calling the tool. There is no redundancy with the title or schema, and the most decision-relevant information (delivery constraint) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema and no annotations, the description is nearly complete: it states exactly what data comes back and when to call it, which covers everything an agent needs to invoke it correctly. The only shortfall is the absence of detail on data format, freshness, or error behavior, which the missing output schema would otherwise have supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema (100% coverage trivially), there are no parameter semantics to clarify, so the baseline of 4 applies. The description's field enumeration additionally serves as a de facto output contract that partially compensates for the missing output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title states a specific verb+resource pair ('Read the account's contacts, credits and limits'), and the description enumerates the exact payload returned: verified contacts, timezone, plan, credit balance, and active-reminder limit. This cleanly distinguishes get_account from the reminder-lifecycle siblings (create_reminder, cancel_reminder, pause_reminder, etc.), which operate on individual reminders rather than account-level state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives explicit when-to-use guidance: 'Read this first if you are unsure whether a phone call is possible or whether there are enough credits.' This states a concrete decision condition for invoking the tool. It does not name explicit exclusions or alternatives, but given the sibling set contains no account-level read competitor, the scoping is clear and adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail of a single reminder: every step, its message, its timing, and what happened to it on the current occurrence.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes | The reminder's id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It conveys a read-only retrieval and adds an important nuance about 'current occurrence' state, but it does not address not-found behavior, error handling, or explicit no-side-effect guarantees beyond the title's 'Read' verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and then adds meaningful detail about what is included. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description sufficiently outlines the return content by naming steps, messages, timing, and current-occurrence outcome. It leaves unspecified behavior for invalid or missing reminder IDs, but this is a minor gap for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single reminder_id parameter, and the input schema already describes it straightforwardly. The tool description adds no parameter-level detail, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the full detail of a single reminder-listing its message, timing, steps, and current-occurrence outcome. It is semantically distinguishable from siblings like list_reminders and get_reminder_status, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus get_reminder_status or list_reminders. The single-reminder framing implies one use, but there are no explicit exclusions, prerequisites, or routing cues to help an agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-step delivery and acknowledgment status for the live occurrence: scheduled, sent, confirmed, failed or skipped, with timestamps. This is how you answer 'did that reminder go out?' and 'have they responded yet?'.
You can read acknowledgment but you can never set it — only the human can acknowledge, by pressing 1 on the call or tapping the link.
| Name | Required | Description | Default |
|---|---|---|---|
| step | No | Optional: report on just this step number instead of the whole chain. | |
| reminder_id | Yes | The reminder's id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a key behavioral constraint: acknowledgment is read-only and can only be set by the human via pressing 1 or tapping the link. It also clarifies the tool reports on the 'live occurrence' and includes timestamps. It does not mention side effects, but the read-only nature is strongly implied and the explicit 'you can never set it' is valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states exactly what the tool returns, the second gives concrete use cases, and the third adds the critical behavioral constraint. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with 2 parameters and no output schema, the description covers the purpose, the statuses, the live-occurrence scope, and the read-only acknowledgment constraint. It does not describe the exact return shape, but since there is no output schema and the statuses are enumerated, an agent has enough to call it correctly. Minor gap: no mention of what happens if the reminder_id is invalid or not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds context that the optional 'step' parameter filters to a single step, but it does not add detail beyond the schema's own description. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get'/'check') and resource ('per-step delivery and acknowledgment status for the live occurrence'), and enumerates the exact statuses returned (scheduled, sent, confirmed, failed, skipped). It also gives concrete example questions the tool answers, which distinguishes it from siblings like get_reminder or list_reminders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool ('This is how you answer...'), which is strong usage guidance. It does not explicitly name alternative tools or state when not to use it, but the example questions and the focus on live occurrence status make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's reminders with their next trigger time, how far the current escalation chain has got, and whether the user has acknowledged. Use this to answer 'what am I being reminded about?' or to find the id of a reminder before cancelling or pausing it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reminders to return. 1-100, default 50. | |
| status | No | Only return reminders in this state. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly states that the operation returns information rather than mutating anything, and it discloses the key output dimensions: trigger time, escalation chain state, and acknowledgement. It does not cover ordering or edge cases, but the essential behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the resource and returned fields; the second adds practical usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional filters and no output schema, the description adequately conveys what data will be returned and how to use it. It omits ordering or empty-result behavior, but those are minor gaps given the simple, well-schematized parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters with types, ranges, defaults, and enum meanings. The description adds no parameter-specific detail, making baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('account's reminders'), then names the returned fields: next trigger time, escalation chain progress, and acknowledgement status. It also ties the tool to concrete user questions, making its purpose unambiguous relative to create/cancel/pause siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: answering 'what am I being reminded about?' and finding a reminder id before cancelling or pausing. It does not name sibling tools or state when not to use them, but the context strongly implies this is the read-only listing entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a reminder and cancel its pending steps, keeping the reminder and its history intact. Reversible — the user resumes it from the NudgeBell dashboard. This is the DEFAULT way to stop a reminder: prefer it over cancel_reminder unless the user explicitly asked to delete it or stop it permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes | The reminder's id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the reminder and history remain intact, that the action is reversible from the NudgeBell dashboard, and that pending steps are canceled. This paints a clear non-destructive, reversible picture, though it does not cover permissions or edge cases like pausing an already-paused reminder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: the first front-loads the action and effect, the second adds reversibility and usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description covers purpose, behavior, and selection criteria. It does not discuss return values or errors, but those are not essential for this simple operation, and the default/reversible guidance is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes reminder_id fully (100% coverage), so the baseline is 3. The description adds no additional parameter meaning, but none is needed for this simple single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Stop a reminder and cancel its pending steps') and explicitly differentiates from cancel_reminder by calling itself reversible and the default. An agent can distinguish it from cancel_reminder without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly instructs to prefer this tool over cancel_reminder unless the user explicitly asked to delete or stop permanently. This is an explicit when-to-use and when-not-to-use guideline, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_remindercreate_reminderget_accountget_reminderget_reminder_statuslist_reminderspause_reminderContext-aware reminders that surface when your situation matches, not at a fixed time.
Wake-ups, webhook inboxes, TTL memory, watches and human approval for agents. Paid per call.
Build and send email, SMS, and push straight from your AI agent.
Agentic CRM for service businesses — bookings, customers, WhatsApp, loyalty, invoicing.
Add one secure layer between your agents and this server.
