Schedule real phone-call reminders with WhatsApp follow-up — medication, wake-ups, family check-ins.
Scored across 25 tools
Most tools have clearly distinct purposes (e.g., create_reminder vs update_reminder vs pause_reminder), and descriptions explicitly route ambiguous cases. Some near-overlaps exist among reminder customization tools (update_reminder, set_reminder_channels, set_skip_dates) and voice tools (set_reminder_voice vs clear_reminder_voice vs set_voice_settings), but the descriptions resolve them.
Tool names consistently use snake_case with a verb_noun (or verb_noun_noun) structure: add_recipient, create_reminder, get_usage, list_voices, set_reminder_voice, etc. The only minor outliers are whoami and list_upcoming, but they remain intuitive and do not break the overall pattern.
25 tools is on the heavy side for the domain, but each tool earns its place across reminders, recipients, voices, fallbacks, and account status. The set could be slightly consolidated (e.g., separate setters for reminder fields), but the breadth matches a feature-rich reminder service.
Reminder lifecycle is well covered: create, read, list, update, delete, pause, resume, skip, channel fallback, and per-reminder voice overrides. Recipient management covers add, list, remove, and re-verify, but lacks an explicit update_recipient for changing a name or phone number without removing and re-adding.
Add another person who can receive reminder calls, e.g. an elderly parent.
ReminderIt immediately places a consent verification call to the number; reminders
are only delivered after that person accepts. Only add someone the user genuinely
has permission to call, and confirm the number digit by digit before submitting —
a typo calls a stranger.
Args:
name: The person's name, used in the call greeting.
phone: Their number in full E.164 format, e.g. "+447700900123".
relationship: Optional label for the user's own reference, e.g. "Mother".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| phone | Yes | ||
| relationship | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (destructiveHint/openWorldHint/non-idempotent) by disclosing the concrete side effect: an immediate consent verification call is placed and reminders are delivered only after acceptance. It also warns that a typo results in a real call to a stranger, which is critical behavioral context for an outbound-calling mutation.
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?
Front-loads the purpose, then safety warnings, then a clean Args block. Slightly verbose with illustrative asides (e.g. 'an elderly parent', 'Mother'), but each sentence contributes meaning rather than restating the schema.
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 destructive, outbound-calling mutation with an output schema present, the description covers purpose, side effects, consent flow, and every parameter's semantics. An agent has everything needed to call it correctly and safely.
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 0%, so the description carries the full burden, and it does: it documents all three params, explains that name is used in the call greeting, mandates full E.164 format with a concrete example for phone, and clarifies relationship is an optional user-facing label.
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 ('Add another person who can receive reminder calls') and the domain concept (recipient of reminder calls). It is clearly separable from siblings like remove_recipient, list_recipients, and resend_recipient_verification.
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?
Gives a clear usage context (adding a new recipient) plus important preconditions — only add someone the user has permission to call, and confirm the number digit by digit. It does not explicitly route to siblings such as resend_recipient_verification for already-added people, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a reminder's custom voice so it uses the account default again.
Args:
reminder_id: Reminder whose voice override should be cleared.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the useful outcome that the override is dropped and the account default takes over, but says nothing about permissions or recoverability of the removed voice.
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?
Front-loaded single sentence that states the effect immediately. The trailing Args block largely restates the schema and is minor filler, but nothing is confusing or bloated.
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?
An output schema exists, so return values need not be explained, and annotations cover destructive/idempotent semantics. For a one-parameter mutation the description is nearly sufficient, missing only permission/authorization context.
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 0% and the only parameter is bare (reminder_id, string). The description does gloss it as 'Reminder whose voice override should be cleared', which is marginally more than the name alone, but adds no format, ID type, or validity guidance.
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 (remove/clear) and resource (a reminder's custom voice) plus the resulting state (account default). It implicitly contrasts with set_reminder_voice, but never names any sibling to route the agent explicitly.
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?
Use is implied by the effect described (reverting to the account default), but there is no explicit when-to-use/when-not, no prerequisites, and no pointer to set_reminder_voice as the inverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| title | Yes | ||
| run_at | No | ||
| end_date | No | ||
| language | No | ||
| timezone | Yes | ||
| voice_id | No | ||
| cron_expr | No | ||
| skip_dates | No | ||
| start_date | No | ||
| personality | No | ||
| message_text | Yes | ||
| recipient_id | No | ||
| interval_days | No | ||
| speaking_rate | No | ||
| email_fallback | No | ||
| whatsapp_fallback | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Permanently delete a reminder. This cannot be undone.
Confirm with the user first, quoting the reminder's title and schedule. If they may
want it later, use pause_reminder instead.
Args:
reminder_id: Reminder to delete (from list_reminders).
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description still adds real value beyond them: the irreversibility ('cannot be undone') and the mandatory user-confirmation step, which is not expressible in annotations. It does not mention permission/auth requirements or error behavior, keeping it out of 5 territory.
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?
Front-loads the destructive action and its irreversibility, then the confirmation rule, then the alternative. All sentences earn their place. The 'Args:' block slightly duplicates a single obvious parameter, which is minor padding.
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 destructive tool with an output schema available, everything an agent needs is present: what is destroyed, that it is irreversible, that confirmation is required, and the safer alternative. No missing decision-relevant information.
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 0% and the schema only carries a bare string with no description, so the description must compensate. It does: it identifies reminder_id as the target and names list_reminders as the source for obtaining it, which is meaningful provenance beyond the type declaration. It stops short of format details.
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 ('Permanently delete a reminder') and immediately differentiates from the sibling pause_reminder, which is the closest overlap in the tool list. An agent can select this without opening either 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?
Explicit when-to-use (user wants it gone), when-not (they may want it later -> pause_reminder), and a required confirmation workflow with the exact content to quote (title and schedule). This is routing plus procedural guidance, not just context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show recent delivery history — what was actually called, sent, or missed.
Use this to answer "did it call me?", "why didn't I get it?", or to confirm a
reminder is really firing. Statuses: completed/answered = the person picked up;
no-answer/busy = rang but nobody answered (a WhatsApp fallback usually follows);
failed = the call could not be placed; blocked = suppressed before dialling (no
credit, unsupported country, or a recipient who hasn't consented);
sent/delivered/read = a WhatsApp or email fallback.
Args:
limit: Number of recent delivery records (1-50, default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/safe, so the description sensibly spends its budget on domain behavior: it explains what each status means and that no-answer/busy typically triggers a WhatsApp fallback, and that blocked means no credit was consumed. That is real value beyond the structured fields, though it says nothing about ordering or pagination.
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?
Front-loaded purpose sentence, then usage, then a status glossary, then args — a logical progression where each block earns its place. The status list is dense but justified for interpretation of results.
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?
An output schema exists so return values need not be described, and annotations carry the safety profile; the description fills the remaining gaps (when to use, status meaning, parameter range). For a single-parameter read tool this is complete.
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 0%, so the description must carry the parameter. It supplies the meaningful constraint missing from the schema — the 1-50 range — plus the record-count meaning, while the default is already present in the schema. Slightly more (what 'recent' means, ordering) would be ideal.
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 ('Show recent delivery history') and immediately scopes it to calls, sent messages, and misses. This is distinguishable from list_reminders/get_reminder, which are about reminder configuration rather than delivery outcomes.
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?
Gives explicit triggering questions ('did it call me?', 'why didn't I get it?') and the diagnostic purpose of confirming a reminder is firing. It stops short of naming when NOT to use it or pointing to an alternative sibling, so it misses the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full configuration of one reminder as JSON.
Use when you need detail that list_reminders omits — the exact spoken message,
cron expression, skip dates, channel toggles, or voice override. Also use this to
read current values before a partial update, so you don't overwrite settings.
Args:
reminder_id: Reminder ID from list_reminders.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context beyond that: the return is full JSON configuration and includes fields the list view lacks (cron, skip dates, channel toggles, voice override). It does not contradict any annotation.
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?
Front-loaded purpose in the first sentence, then usage, then the argument note. Everything earns its place, though the field enumeration ('spoken message, cron expression, skip dates...') in the usage sentence slightly runs long.
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?
An output schema exists, so return values need not be explained. For a one-parameter read tool with strong annotations, the description supplies everything an agent needs: purpose, when to use, an alternative to avoid, and where the ID comes from.
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 0%, so the description must carry the parameter. It does add provenance ('Reminder ID from list_reminders'), telling the agent where to obtain a valid ID, which is real value the schema lacks. It stops short of format details, but for a single opaque ID that is acceptable.
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 ('get the full configuration of one reminder') and immediately distinguishes it from the sibling list_reminders by noting it returns detail the list omits. An agent can tell it apart from list_reminders and update_reminder without opening a 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?
Explicit when-to-use: 'when you need detail that list_reminders omits — the exact spoken message, cron expression, skip dates, channel toggles, or voice override.' It also names a second scenario (read before a partial update to avoid overwriting settings), which is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get remaining call quota, calls used, plan, and the current billing period.
Check before creating several reminders or suggesting a test call, and whenever a delivery fails unexpectedly. One call OR one WhatsApp fallback each consume one unit from the same pool. When the balance is low or zero, tell the user plainly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the quota consumption model (one call OR one WhatsApp fallback per unit, shared pool) and the instruction to surface a low/zero balance plainly to the user.
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?
Front-loaded with what is returned, followed by when to call and one behavioral caveat about quota accounting. Three short sentences, each carrying a distinct payload, 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?
With an output schema present and no parameters, the description does not need to explain return values or inputs, yet still covers purpose, invocation timing, quota mechanics, and expected user-facing behavior. Nothing an agent needs to select or call it 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?
The tool takes zero parameters, so per the rubric the baseline is 4. The description appropriately spends no words on parameter semantics and instead uses its space for quota semantics.
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 names a specific verb (get) and enumerates exactly what is returned (remaining call quota, calls used, plan, current billing period), which is far more than the title 'Check call balance' conveys. It is clearly distinct from siblings like get_recent_calls or whoami, but it never explicitly contrasts itself with them, so it lands just short of the top mark.
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?
It gives concrete triggering situations: check before creating several reminders or suggesting a test_call, and whenever a delivery fails unexpectedly. There is no statement of when not to call or an alternative tool, since none exists for quota, but the positive guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the account's default voice — the voice every reminder uses unless overridden.
Read this before changing anything, so you can report what actually changed and leave unrelated settings alone.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description still adds value by framing the tool as a read-before-write baseline and clarifying the override relationship, though it adds nothing about scope or auth.
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 short sentences, front-loaded with the purpose and followed by actionable usage framing. Every clause carries weight, with only a minor bit of editorializing in the rationale.
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 zero-parameter, read-only tool with an output schema, the description supplies purpose plus workflow context, which is sufficient. It does not need to explain return values, so nothing essential 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?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate at the parameter level, and the schema is complete.
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 and resource ('Show the account's default voice') and clarifies the semantics of 'default' — the voice reminders use unless overridden — which meaningfully separates it from list_voices and the per-reminder voice tools. It does not name a sibling explicitly, so it falls just short of a 5.
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?
It gives clear contextual guidance ('Read this before changing anything, so you can report what actually changed and leave unrelated settings alone'), effectively telling the agent to call this prior to set_voice_settings. It stops short of naming alternatives or explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List care-recipients — other people this account can send reminders to.
Needed to get the recipient_id for create_reminder. Consent status matters: only
"confirmed" recipients receive calls; "pending" means they haven't accepted the
verification call yet, so reminders to them will be blocked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description goes further by disclosing domain state semantics that annotations cannot express — the meaning of "confirmed" vs "pending" consent and the concrete consequence that reminders to pending recipients are silently blocked.
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 short, front-loaded statements: purpose, then why (recipient_id for create_reminder), then a caveat about consent status. Zero filler, and the most decision-relevant sentence (routing) comes before the nuance.
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?
With an output schema present, return-shape details are unnecessary, and the zero-parameter surface means no argument documentation is owed. The description covers everything an agent needs: what it returns conceptually, when to call it, and how to interpret the consent field.
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 tool takes zero parameters, so there are no parameter semantics to explain and the schema cannot leave gaps. The baseline of 4 applies; the description correctly spends its words on results interpretation instead.
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+resource ("List care-recipients") and immediately defines the resource in plain terms ("other people this account can send reminders to"), which cleanly separates it from siblings like list_reminders, list_voices, and list_upcoming. An agent can identify the right 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?
Explicitly names the downstream consumer and the condition that selects this tool: "Needed to get the recipient_id for create_reminder." It also supplies the domain prerequisite (only "confirmed" recipients can receive calls; "pending" ones are blocked), so the agent knows both when to call it and how to interpret the result before acting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every reminder on the account with its schedule, state and next call time.
Start here for almost any request about existing reminders — it is the only way to
discover reminder IDs, which every other reminder tool needs. Paused reminders show
WHY they are paused (out_of_credit, destination_not_allowed, completed).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine behavioral value beyond that by disclosing that paused reminders surface the reason they are paused, with the enumerated causes (out_of_credit, destination_not_allowed, completed).
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 short sentences with zero waste; the scoping/role statement is front-loaded before the return-content detail. 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 zero-parameter read-only list tool with an output schema already defining the return shape, the description covers the discovery role, the state semantics and the paused-reason values. Nothing an agent needs in order to call it 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?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly spends no words on parameters.
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+resource (list reminders) and enumerates what is returned: schedule, state and next call time. The claim that it is 'the only way to discover reminder IDs' distinguishes it from siblings like get_reminder, which require an ID the agent would not otherwise have.
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 says to 'start here for almost any request about existing reminders', giving strong routing guidance for a discovery tool. It does not, however, name alternatives such as get_reminder or list_upcoming or state when those are preferable, so there is no explicit when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the next scheduled calls across ALL reminders, in chronological order.
Answers "what's coming up?" better than list_reminders, because it expands
recurring rules into actual upcoming occurrences and merges them into one timeline.
Args:
limit: How many upcoming occurrences to return (1-50, default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so safety is covered. The description adds genuinely new behavioral context: recurrence rules are expanded into concrete occurrences and merged into a single chronological timeline, which the agent cannot infer from annotations or schema.
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?
Front-loaded with the core purpose and the sibling comparison, then a compact Args note. Slight verbosity in the two-paragraph split, but every sentence carries information and there is no filler.
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?
An output schema exists, so return-value explanation is unnecessary. Purpose, sibling routing, recurrence expansion behavior, and the single parameter's range are all covered for a simple read-only list 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 description coverage is 0%, so the description must compensate. It documents the sole parameter's meaning plus the valid range (1-50) and default (10), which the schema does not state beyond the default. Good compensation for a 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 verb (show/list) and resource (next scheduled calls across all reminders) with explicit scope ('ALL reminders, in chronological order'). It directly names and distinguishes itself from the sibling list_reminders, so an agent can select correctly without reading schemas.
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 routes the agent: 'Answers "what's coming up?" better than list_reminders, because it expands recurring rules into actual upcoming occurrences.' This names the alternative and the condition that favors this tool, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the voices available on this account, with language, accent and tier.
Call before set_voice_settings or set_reminder_voice to get valid voice IDs —
never guess one. Voices marked premium may not be included in every plan; if the
account's plan doesn't include one, calls fall back to a standard voice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds real behavioral context beyond them: premium voices may be plan-gated and calls fall back to a standard voice rather than failing. It doesn't restate anything from the annotations.
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 short sentences, purpose first, prerequisite second, with the plan/fallback caveat last. No filler and nothing redundant with structured fields.
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?
An output schema exists, so return values need no narration; the description supplies purpose, prerequisite ordering, and the one non-obvious behavioral caveat. Complete for a zero-parameter listing 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. No parameter guidance is needed or expected.
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 (list) and resource (voices) and enumerates the returned attributes (language, accent, tier). An agent can distinguish this read-only catalog tool from set_voice_settings or set_reminder_voice at a glance.
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 says when to call it (before set_voice_settings or set_reminder_voice) and gives a hard rule ('never guess one'), which is exactly the routing guidance sibling tools need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a reminder so it stops calling, keeping all its settings intact.
Prefer this over delete_reminder whenever the user might want it back — it is
fully reversible with resume_reminder.
Args:
reminder_id: Reminder to pause (from list_reminders).
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnly=false, destructive=true, idempotent=true), so the bar is lower; the description still adds the salient behavior that state is preserved and the action is reversible via resume_reminder. It does not address edge cases (e.g. an already-paused reminder, whether an in-flight call is affected), which is the only real gap for a 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 short lines: purpose first, then the alternative-selection rule, then the single argument. Every sentence carries distinct information and the decision-relevant content 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?
An output schema exists, so return values need not be explained; for a one-parameter, idempotent mutation the description covers intent, the sibling it displaces, the reversal path, and how to supply the argument. Nothing needed to call it 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 description coverage is 0%, so the schema only gives 'reminder_id: string'. The description compensates by defining the parameter's meaning and its provenance ('from list_reminders'), which tells the agent where to obtain a valid value rather than just the type.
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?
Specific verb (pause) plus resource (reminder) and an explicit statement of effect: it 'stops calling' while 'keeping all its settings intact'. That distinguishes it cleanly from delete_reminder, resume_reminder, and update_reminder 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?
Explicitly routes the agent: prefer this over delete_reminder 'whenever the user might want it back', and names resume_reminder as the reversal path. Both a when-to-use rule and a named alternative are given, so nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a short audio sample of a voice so the user can hear it before choosing.
Returns a URL to the generated audio. Useful when a user is deciding between
voices, or wants to check how their own reminder wording will sound.
Args:
voice_id: Voice ID from list_voices.
text: Words to speak in the sample. Defaults to a standard demo line; pass the
user's actual reminder message to preview exactly what they'll hear.
personality: "gentle", "cheerful", "professional", or "energetic".
language: BCP-47 tag, e.g. "en-GB".
speaking_rate: 0.8 to 1.2.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| language | No | ||
| voice_id | Yes | ||
| personality | No | gentle | |
| speaking_rate | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it returns a URL to generated audio, text defaults to a standard demo line, and passing the user's actual message previews exactly what they will hear.
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 prose is tight and front-loaded, with the return artifact stated in the first line. The Args block is well-organized but slightly verbose in places (e.g., repeating that text can be the user's reminder message).
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?
An output schema exists, so return-value detail is not required, yet the description still notes the URL. All five parameters are documented despite 0% schema coverage, leaving little an agent needs that 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 description coverage is 0%, so the description carries the full burden and does so thoroughly: voice_id's source (list_voices), text's default and intended use, the four allowed personality values (enums not present in the schema), language as a BCP-47 tag with example, and the 0.8–1.2 speaking_rate range.
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 opens with a specific verb and resource ('Generate a short audio sample of a voice') and states the intent ('so the user can hear it before choosing'). It is clearly distinguishable from siblings like list_voices, set_reminder_voice, and test_call, which do different things with voices.
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?
It gives concrete usage contexts: deciding between voices, or checking how the user's own reminder wording will sound. It does not name an alternative tool or state when not to use this one, so it falls short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a care-recipient from the account.
Any reminders targeting them will stop being delivered. Confirm with the user first.
Args:
recipient_id: Recipient to remove (from list_recipients).
| Name | Required | Description | Default |
|---|---|---|---|
| recipient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered structurally. The description adds real behavioral context beyond that: removing the recipient stops delivery of any reminders targeting them, which is the key downstream effect an agent must warn about.
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 short sentences with the consequence and the confirmation requirement front-loaded, followed by a compact Args block. The Args formatting is slightly boilerplate for a single parameter but the content is not wasted.
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?
With an output schema present, return values need not be explained, and the annotations cover safety and idempotency. The description supplies the destructive consequence and the confirmation step; the only real gap is whether the removal is reversible.
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 0% for the single parameter, so the description must carry the load. It does add value by telling the agent where the recipient_id comes from (list_recipients), but it does not specify the ID format or validate what a valid value looks like.
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 and resource ('Remove a care-recipient from the account'), which cleanly contrasts with the add_recipient sibling. It stops short of explicitly naming the sibling or scoping what 'remove' means (soft-delete vs. permanent), so it is clear but not maximally differentiated.
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?
It gives an actionable usage rule ('Confirm with the user first') and routes the agent to list_recipients as the source of the ID. There is no explicit when-not guidance, but there is no alternative removal tool in the sibling set to point to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-send the consent verification call to a recipient who hasn't confirmed yet.
Use when list_recipients shows consent as pending and the person missed the first
call. Don't repeat it more than necessary — each attempt rings their phone.
Args:
recipient_id: Recipient to re-verify (from list_recipients).
| Name | Required | Description | Default |
|---|---|---|---|
| recipient_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true. The description adds genuinely new behavioral context by disclosing the real-world side effect ('each attempt rings their phone') and warning against over-use, though it says nothing about permissions or what a failed attempt looks like.
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 short, front-loaded sentences: purpose, when-to-use/caution, then the Args note. No padding and no repetition of the title.
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?
An output schema exists so return values need no explanation, and the description covers purpose, trigger, caution, and the one parameter's provenance. Nothing an agent needs to call this 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 0% on the single parameter, but the description compensates by explaining what recipient_id means ('Recipient to re-verify') and where to obtain it ('from list_recipients'), which the bare string schema does not convey.
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+resource ('re-send the consent verification call') and scopes it to recipients who haven't confirmed. This clearly distinguishes it from siblings like test_call, add_recipient, or list_recipients.
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 names the trigger condition ('list_recipients shows consent as pending and the person missed the first call') and gives a when-not constraint ('don't repeat it more than necessary'), routing the agent to the sibling that supplies the ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a paused reminder so it starts calling on its schedule again.
If it was paused automatically for out_of_credit and the account still has no calls
left, it will pause again at the next occurrence — check get_usage and tell the user.
Args:
reminder_id: Reminder to resume (from list_reminders).
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuinely new behavior: a reminder paused for out_of_credit will re-pause at the next occurrence if the account is still empty, and the agent should check get_usage and inform the user. That is a non-obvious side effect worth surfacing.
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 main sentence is front-loaded and the credit caveat follows logically. The 'Args:' block is slightly redundant for a one-parameter tool but not wasteful enough to penalize heavily.
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?
An output schema exists, so return values need not be described. The description covers the primary action and the key failure/edge case (re-pausing without credit), but omits whether the reminder must currently be paused and what happens to the schedule for a missed occurrence.
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 0% and the single parameter is undocumented in the schema, so the description must compensate. It does name the parameter and its source ('from list_reminders'), which tells the agent where to obtain a valid id, though it adds no format or validation detail.
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 ('resume') and resource ('a paused reminder') plus the effect ('starts calling on its schedule again'). This clearly distinguishes it from the sibling pause_reminder and from create_reminder/delete_reminder without needing to open any other definition.
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?
Gives a clear context of use (resuming a paused reminder) and routes the agent to get_usage for the out_of_credit case. It does not explicitly name pause_reminder as the inverse alternative or state preconditions like 'only call on a currently paused reminder', so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose what happens when a reminder call isn't answered.
The phone call itself is always attempted. These toggles control the follow-ups:
WhatsApp is on by default, email is off. Note each delivered fallback also consumes
one call from the account's quota.
Args:
reminder_id: Reminder to configure (from list_reminders).
whatsapp_fallback: True to send a WhatsApp message when the call is missed.
email_fallback: True to also email the reminder when the call is missed.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes | ||
| email_fallback | No | ||
| whatsapp_fallback | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (destructiveHint=true, idempotentHint=true), and the description adds genuinely new behavior: per-fallback quota consumption ('each delivered fallback also consumes one call from the account's quota') and the default channel states. It does not explain what 'destructive' toggling-off actually does or what a null value means, leaving a small gap.
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?
Front-loaded with the core intent, then the always-attempted scoping rule, then the quota caveat. The Args block is efficient, with only mild redundancy between the prose defaults and the per-argument lines.
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?
An output schema exists so return values need no explanation, and the description covers defaults, quota cost, and call behavior. What's missing is the effect of null/omitted arguments on an idempotent, destructive-hinted setter, which an agent would want before re-invoking.
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 0% schema description coverage, the description must carry the burden and largely does: it defines reminder_id's source (list_reminders), and explains both booleans as miss-triggered channels. The defaults quoted ('WhatsApp is on by default, email is off') add meaning beyond the schema's bare 'default: null', though the null-vs-unchanged semantics remain ambiguous.
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 opening line names a specific decision ('Choose what happens when a reminder call isn't answered') and the body scopes it precisely: the call is always attempted, only the follow-up channels are configured. This is clearly distinct from siblings like set_reminder_voice or set_skip_dates.
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?
It gives clear operating context — the call attempt is unconditional and only fallbacks are toggled — and points to list_reminders as the source of reminder_id. It stops short of naming alternatives or when-not to use this tool (e.g., vs. set_reminder_voice), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give one reminder its own voice, overriding the account default.
Use when a specific reminder should sound different — a calm, slower voice for
medication; an energetic one for a workout; a different language for a relative.
Call list_voices first to get valid voice IDs, and preview_voice if the user
wants to hear it before committing. Other reminders are unaffected.
Args:
reminder_id: Reminder to restyle (from list_reminders).
voice_id: Voice ID from list_voices.
personality: "gentle", "cheerful", "professional", or "energetic".
language: BCP-47 tag for the spoken message, e.g. "en-GB", "es-ES", "hi-IN".
speaking_rate: 0.8 (slower, good for elderly listeners) to 1.2 (faster).
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ||
| voice_id | No | ||
| personality | No | ||
| reminder_id | Yes | ||
| speaking_rate | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true, so the agent knows this is an idempotent-but-overwriting mutation. The description adds genuine scope context ('other reminders are unaffected', override of the account default), but given destructiveHint=true it never says whether an existing per-reminder voice config is overwritten or merged, nor any permission requirements. Useful but incomplete against a destructive mutation.
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?
Well front-loaded: the one-line purpose and routing guidance precede the Args block. The scenario examples are illustrative rather than filler. Slightly long, but every element contributes.
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 an idempotent, non-read-only mutation with an output schema, the definition covers purpose, when/when-not, sibling routing, scope of effect, and all five parameters. Return values are handled by the output schema, so nothing an agent needs to call this 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 0%, so the description carries the full burden and does: it names the source for reminder_id (list_reminders) and voice_id (list_voices), enumerates personality values, gives BCP-47 examples for language, and specifies a numeric range with semantic interpretation for speaking_rate. This is meaningfully beyond the bare-typed nullable 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?
States a specific verb and resource ('Give one reminder its own voice') plus the exact scope ('overriding the account default'). An agent can distinguish it from clear_reminder_voice (removes a per-reminder voice) and set_voice_settings (account-level) 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?
Gives concrete when-to-use scenarios (medication, workout, foreign-language relative), names the prerequisite tools (list_voices, preview_voice), and explicitly bounds the effect with 'Other reminders are unaffected.' Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the specific dates a recurring reminder should NOT call.
The right way to handle holidays, travel, or a pause of a few days — far better
than deleting a reminder and rebuilding it. This REPLACES the existing skip list,
so include dates the user still wants skipped (read them with get_reminder first).
Pass an empty list to clear all skips.
Args:
reminder_id: Reminder to adjust (from list_reminders).
skip_dates: Local dates in "YYYY-MM-DD" form, e.g. ["2026-08-12", "2026-08-13"].
| Name | Required | Description | Default |
|---|---|---|---|
| skip_dates | Yes | ||
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds the crucial detail that the call REPLACES the existing skip list rather than appending, plus the clearing behavior and the required prerequisite read. It explains what gets destroyed, which annotations only flag.
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?
Front-loaded with the core action, then motivation, then the destructive warning, then a clean Args block. No filler sentences; each part 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?
An output schema exists so return values need not be described, and for a two-parameter mutation the description covers the replacement semantics, the prerequisite, the format, and the clearing case. Nothing an agent needs to call it 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 0%, so the description must carry parameter meaning, and it does: reminder_id is sourced 'from list_reminders', skip_dates is specified as local dates in 'YYYY-MM-DD' form with a concrete example array. That fully compensates for the undocumented 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 description states a specific verb (Set) and resource (skip dates for a recurring reminder's no-call days), which is clear and concrete. However, it never names or contrasts with the closest sibling, skip_next_occurrence, leaving some ambiguity about which tool handles one-off skips versus a full skip list.
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 frames when to use it (holidays, travel, a few-day pause) versus the alternative of deleting and rebuilding a reminder, and gives the prerequisite workflow: read existing skips with get_reminder first, and pass an empty list to clear. That is a complete when/when-not/alternative picture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the account's DEFAULT voice, affecting every reminder without an override.
For a single reminder only, use set_reminder_voice instead. Get valid IDs from
list_voices; preview_voice lets the user hear one first.
Args:
voice_id: Voice ID from list_voices.
personality: "gentle", "cheerful", "professional", or "energetic".
language: BCP-47 tag, e.g. "en-US", "en-GB", "hi-IN".
speaking_rate: 0.8 (slower — often better for elderly listeners) to 1.2 (faster).
greet_by_name: Whether calls open by greeting the user by name.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ||
| voice_id | No | ||
| personality | No | ||
| greet_by_name | No | ||
| speaking_rate | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false; the description adds the blast radius ('affecting every reminder without an override'), which is exactly the kind of impact context annotations can't express. It stops short of saying whether omitted optional fields retain current values or clear them.
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 short routing/context sentences followed by a tight parameter block; the scope warning is front-loaded and no sentence is redundant given the bare schema.
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?
Output schema exists, so return values need no explanation, and alternatives plus every parameter are covered. The one gap is the all-optional, null-defaulted schema: the description never says what happens to a field the caller omits.
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 0% and contains no enums, so the description carries the full burden and does: voice_id provenance, the four literal personality values, BCP-47 language examples, the meaningful speaking_rate range with a use-case rationale, and the meaning of greet_by_name. This is materially more than the schema provides.
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 ('Change the account's DEFAULT voice') and immediately scopes the effect ('affecting every reminder without an override'), which cleanly separates it from set_reminder_voice. An agent can pick it 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?
Explicitly routes to the alternative for the narrow case ('For a single reminder only, use set_reminder_voice instead') and names the lookup/preview tools (list_voices, preview_voice) with their purpose. Both when-to-use and when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Skip only the next scheduled call, leaving the rest of the schedule untouched.
Use for "not tomorrow, but keep it going after that". To skip particular calendar
dates instead, use set_skip_dates.
Args:
reminder_id: Reminder whose next call should be skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds the meaningful behavioral detail that the change is narrowly scoped to a single occurrence and leaves the remaining schedule intact — a useful blast-radius statement. It does not address reversibility or how to undo the skip, so it falls short of a 5.
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 short, front-loaded sentences that deliver purpose, use case, and alternative before the Args block. No filler.
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?
An output schema exists, so return values need not be described. For a single-param mutation tool with annotations covering safety, the description supplies purpose, scope, and routing to the alternative — everything an agent needs to select and invoke it 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 description coverage is 0%, so the description must carry the param meaning; it does explain reminder_id as 'Reminder whose next call should be skipped,' which is meaningfully more than the bare property name. It does not specify the expected ID format, so it is not fully compensating.
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 (skip) and resource (the next scheduled call) with an explicit scope qualifier: 'only the next scheduled call, leaving the rest of the schedule untouched.' This distinguishes it cleanly from the sibling set_skip_dates.
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?
Gives an explicit use case ('not tomorrow, but keep it going after that') and names the alternative tool with the condition that selects it ('To skip particular calendar dates instead, use set_skip_dates'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an immediate test call for a reminder so the user can hear it right now.
The phone will ring within seconds — only do this when the user has asked to test,
and never repeatedly. It consumes one call from their quota and does not change
the schedule.
Args:
reminder_id: Reminder to test (from list_reminders).
| Name | Required | Description | Default |
|---|---|---|---|
| reminder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, destructive, open-world. The description adds real context beyond them: the phone rings within seconds (latency), it burns one call from the user's quota (the actual cost), and it does not alter the schedule (bounded side effect). That is exactly the extra disclosure annotations cannot carry.
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 tight sentences plus a single arg line; the immediate-action summary and the guardrail are front-loaded, and every sentence adds information.
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?
Covers side effect (quota), reversibility (schedule unchanged), timing, and the parameter source; an output schema exists so return values need no explanation. Nothing needed to call it 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 description coverage is 0%, so the schema documents nothing about reminder_id. The description compensates by stating it is the 'Reminder to test' and where to obtain it ('from list_reminders'), though it gives no format or validation details.
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 — 'Place an immediate test call for a reminder' — with the immediacy qualifier that separates it from create_reminder or list_reminders. An agent can distinguish this from every sibling 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?
Gives explicit when ('only when the user has asked to test') and when-not ('never repeatedly'), plus a concrete constraint (consumes one quota call). It also routes the agent to list_reminders for the required ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a reminder's wording or schedule. Only the fields you pass are changed.
Use for "move it to 7am", "say it differently", "stop after the 20th". To pause or
resume, use pause_reminder / resume_reminder. To change the voice, use
set_reminder_voice. To skip particular dates, use set_skip_dates.
Args:
reminder_id: Reminder to edit (from list_reminders).
title: New short label.
message_text: New spoken message (written as natural speech, max 600 chars).
cron_expr: New cron schedule, e.g. "0 7 * * *" for daily 7am.
interval_days: New "every N days" interval (1-365).
run_at: New ISO 8601 datetime for a one-off reminder.
timezone: New IANA timezone. Changing this moves every future call.
start_date: New ISO start date for a recurring series.
end_date: New ISO end date; the series stops after it.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| run_at | No | ||
| end_date | No | ||
| timezone | No | ||
| cron_expr | No | ||
| start_date | No | ||
| reminder_id | Yes | ||
| message_text | No | ||
| interval_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds non-obvious behavioral context: partial updates (unspecified fields untouched), that changing timezone 'moves every future call', and that the series stops after end_date. It does not explain what the destructiveHint implies (e.g., whether an edit can clobber existing schedule state), which keeps it from a 5.
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?
Front-loaded with purpose and the key partial-update guarantee, then a routing sentence, then a scannable Args block. Given 9 parameters, the length is justified and no sentence is redundant.
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?
An output schema exists, so return values need not be described. With usage routing, partial-update semantics, and full parameter documentation, an agent has everything needed to call this mutation 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 description coverage is 0%, so the description carries the full parameter burden — and it does: every one of the 9 params is documented with format and meaning, including a cron example, the 1-365 interval bound, the 600-char message limit, ISO date expectations, and the source of reminder_id (list_reminders).
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 ('Edit a reminder's wording or schedule') and immediately clarifies the partial-update semantics with 'Only the fields you pass are changed.' An agent can distinguish this from create_reminder, delete_reminder, and the pause/resume siblings without opening a 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 explicit user-phrase triggers ('move it to 7am', 'say it differently', 'stop after the 20th') plus three named alternatives with the condition that selects each: pause_reminder/resume_reminder, set_reminder_voice, and set_skip_dates. This is exactly the when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the connected ReminderIt account: who it is, their timezone, plan and quota.
Two jobs. First, it is the connection check — call it when the user asks "am I
connected?", "which account is this?", or when another tool returns an auth error,
to confirm the API key is valid and see whose account it opens.
Second, call it BEFORE creating or rescheduling a reminder: it returns the user's
saved timezone, so you can schedule silently instead of asking. It also warns when
the phone is unverified or the account is opted out — in either case no reminder can
be delivered, so surface that before scheduling anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context — that it can reveal delivery blockers (unverified phone, opted-out account) and that these block reminder delivery, which is not encoded anywhere in the structured fields.
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?
Front-loaded with the core identity statement, then split into two clearly labelled jobs. Every sentence carries actionable information; nothing is repeated from the title or annotations.
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?
An output schema exists, so return-value explanation is unnecessary, and the description instead supplies the pre-call reasoning (auth validation, timezone reuse, delivery blockers) an agent needs to use the tool 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?
The tool takes no parameters, so per the baseline no compensating parameter documentation is needed and the schema (empty object) is fully aligned with the description.
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 ('Identify the connected ReminderIt account') and enumerates the returned dimensions (identity, timezone, plan, quota). It is clearly distinguishable from get_usage or get_voice_settings by scoping to account identity.
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 names two triggering conditions: connection/auth-error checks, and calling BEFORE creating or rescheduling a reminder to reuse the saved timezone. It goes further by stating when not to proceed (unverified phone or opted-out account) rather than leaving that to inference.
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.
add_recipientclear_reminder_voicecreate_reminderdelete_reminderget_recent_callsget_reminderget_usageget_voice_settingslist_recipientslist_reminderslist_upcominglist_voicespause_reminderpreview_voiceremove_recipientresend_recipient_verificationresume_reminderset_reminder_channelsset_reminder_voiceset_skip_datesset_voice_settingsskip_next_occurrencetest_callupdate_reminderwhoamiReminders your agent creates: email, WhatsApp, SMS or call, in steps you set. Stops on acknowledge.
Calls your phone when an AI task finishes or is blocked — hear it, say what's next.
Wake-ups, webhook inboxes, TTL memory, watches and human approval for agents. Paid per call.
AI voice agents that make real phone calls: single calls or campaigns, with transcripts and notes.
Add one secure layer between your agents and this server.
