Skip to main content
Glama

schedule_push_notification

Schedule one-time or recurring push notification campaigns for future delivery, or cancel a pending scheduled dispatch before it executes.

Instructions

Schedule a one-time or recurring push notification campaign for a future timestamp, or cancel an existing pending schedule. Use this tool for delayed or recurring broadcasts (daily, weekly, cron); do not use it for immediate sending (use send_push_notification instead). Prerequisite: call list_apps first to obtain app_id, or call get_campaign_analytics to find a cancel_campaign_id. Requires PUSHNOTIF_API_KEY; credits (1 per delivered device) are deducted only when the scheduled dispatch executes. Pass cancel_campaign_id ('cmp_sch_xxxx') to cancel a queued job, or pass app_id, title, body, and scheduled_for (ISO-8601) to create one. Returns JSON { ok, action, scheduled_campaign: { id, app_id, title, scheduled_for, recurrence_rule, status } }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOptional HTTPS destination URL opened on tap
bodyNoNotification body text (required when creating a schedule; 1 to 240 characters)
titleNoNotification headline (required when creating a schedule; 1 to 100 characters)
app_idNoTarget application ID in format app_xxxx (required when creating a schedule)
scheduled_forNoISO-8601 execution timestamp (e.g., '2026-10-21T08:00:00+07:00')
recurrence_ruleNoRecurrence pattern: 'once' (default), 'daily', 'twice_daily', 'weekly', 'monthly', 'every_30m', 'every_3h', 'every_6h', or a 5-field cron expression
cancel_campaign_idNoOptional scheduled campaign ID (format cmp_sch_xxxx from get_campaign_analytics) to cancel and delete before execution

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.1.2
    • changedInput schema / properties / app_id / description
      Previous value: -"App ID tujuan (misal: app_xxxx)"New value: +"Target application ID in format app_xxxx (required when creating a schedule)"
    • changedInput schema / properties / body / description
      Previous value: -"Isi pesan notifikasi"New value: +"Notification body text (required when creating a schedule; 1 to 240 characters)"
    • changedInput schema / properties / cancel_campaign_id / description
      Previous value: -"Isi jika ingin membatalkan/menghapus jadwal kampanye (cmp_sch_xxxx)"New value: +"Optional scheduled campaign ID (format cmp_sch_xxxx from get_campaign_analytics) to cancel and delete before execution"
    • changedInput schema / properties / recurrence_rule / description
      Previous value: -"Aturan perulangan: once, daily, twice_daily, weekly, monthly, every_30m, every_3h, every_6h, atau ekspresi cron kustom (misal: 0 5,12,15,18,19 * * *)"New value: +"Recurrence pattern: 'once' (default), 'daily', 'twice_daily', 'weekly', 'monthly', 'every_30m', 'every_3h', 'every_6h', or a 5-field cron expression"
    • changedInput schema / properties / scheduled_for / description
      Previous value: -"Waktu kirim format ISO-8601 (misal: 2026-10-17T06:00:00Z)"New value: +"ISO-8601 execution timestamp (e.g., '2026-10-21T08:00:00+07:00')"
    • changedInput schema / properties / title / description
      Previous value: -"Judul pesan notifikasi"New value: +"Notification headline (required when creating a schedule; 1 to 100 characters)"
    • changedInput schema / properties / url / description
      Previous value: -"URL tujuan saat notifikasi diketuk"New value: +"Optional HTTPS destination URL opened on tap"
  2. First observedv2.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds context the annotations do not carry: PUSHNOTIF_API_KEY requirement, credit billing of 1 per delivered device charged only at dispatch execution, and that cancellation deletes a queued job before execution. The cancel-is-delete wording is consistent with a not-yet-delivered job rather than user data destruction, so it does not contradict destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the primary routing rule are front-loaded, and nearly every sentence carries load (prereqs, auth, billing, return shape). It is a dense single block with no formatting, which makes the two operating modes harder to scan than they need to be.

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

Completeness5/5

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

With no output schema, the description compensates by disclosing the return shape ({ ok, action, scheduled_campaign: {...} }), and it covers prerequisites, auth, billing timing, and both operating modes. Complete enough for an agent to invoke correctly on the first try.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds the crucial mode-switching semantics: passing cancel_campaign_id cancels, whereas passing app_id + title + body + scheduled_for creates. It also flags the ID format expectations, though individual field-level constraints largely duplicate the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (schedule/cancel) plus resource (future push notification campaign) and explicitly distinguishes itself from the sibling send_push_notification for immediate sending. An agent can tell the two apart 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.

Usage Guidelines5/5

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

Names the when ('delayed or recurring broadcasts: daily, weekly, cron'), the when-not ('immediate sending'), the alternative to use instead, and the precondition calls (list_apps for app_id, get_campaign_analytics for cancel_campaign_id). Routing is fully determined.

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