Skip to main content
Glama

Create reminder call

create_reminder

Schedule a new reminder phone call.

This places REAL calls, so get the schedule right the first time: resolve the
timezone via whoami, and read the result back to the user afterwards.

Provide exactly one schedule: run_at (one-off), cron_expr, or interval_days.
Leave the voice arguments empty to use the account's default voice.

Args:
    title: Short label shown in the app, e.g. "Morning pills" (max 120 chars).
    message_text: Exactly what the voice says on the call, written as speech —
        "Time to take your blood pressure tablet." (max 600 chars). Avoid
        abbreviations and symbols that sound wrong when read aloud.
    type: "once" for a single call, "recurring" for a repeating schedule.
    timezone: IANA timezone the schedule is anchored to, e.g. "America/New_York".
    run_at: ISO 8601 local datetime for a one-off call. Required when type="once".
    cron_expr: Cron schedule for recurring calls, e.g. "0 8 * * 1-5" = weekdays 8am.
    interval_days: Repeat every N days (1-365). Simpler alternative to cron_expr.
    start_date: ISO date; the recurring series does not fire before this.
    end_date: ISO date; the series stops after this (e.g. end of a medication course).
    skip_dates: Local dates to skip, ["2026-08-12"] format — holidays, travel.
    recipient_id: Call a care-recipient (from list_recipients) instead of the
        account owner. The recipient must have consented.
    voice_id: Override the account voice for this reminder only (see list_voices).
    personality: Speaking style — "gentle", "cheerful", "professional", "energetic".
    language: BCP-47 language tag for the spoken message, e.g. "en-GB", "hi-IN".
    speaking_rate: Speech speed, 0.8 (slower) to 1.2 (faster). 1.0 is normal.
    whatsapp_fallback: Send the reminder on WhatsApp if the call isn't answered.
    email_fallback: Also email the reminder if the call isn't answered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYes
titleYes
run_atNo
end_dateNo
languageNo
timezoneYes
voice_idNo
cron_exprNo
skip_datesNo
start_dateNo
personalityNo
message_textYes
recipient_idNo
interval_daysNo
speaking_rateNo
email_fallbackNo
whatsapp_fallbackNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly=false, idempotent=false, openWorld=true, so the safety profile is covered. The description adds material context beyond that: this dials REAL phone numbers, the schedule must be right the first time, and the recipient must have already consented. It stops short of describing rate limits, failure behavior, or what happens if the call is unanswered despite the fallback flags.

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 critical warning about real calls and the one-schedule rule are front-loaded before the long Args block, and every parameter line earns its place for a 17-param tool. Slightly verbose in places, but nothing is redundant given the argument count.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the description supplies the missing schedule-mode disambiguation, timezone resolution step, fallback semantics, and per-parameter constraints. An agent has everything needed to construct a correct call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 17 parameters, so the description carries the full burden and does so thoroughly: every argument has meaning, format, an example, and constraints (max 120 chars, max 600 chars, 1-365 days, 0.8-1.2 rate), plus the conditional rule that run_at is required when type='once'. This is exactly the compensation a low-coverage schema needs.

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 and resource ('Schedule a new reminder phone call') and makes the real-world side effect explicit, which cleanly separates it from update_reminder, pause_reminder, and set_reminder_voice siblings. An agent can identify the tool's job 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.

Usage Guidelines4/5

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

Gives concrete operating guidance: provide exactly one schedule (run_at / cron_expr / interval_days), resolve timezone via whoami, read the result back to the user, and leave voice args empty to use the account default. It defers to list_recipients and list_voices for dependent lookups, though it never states when to prefer update_reminder over creating a new one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources