Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send Push Campaign

send-push-campaign
Destructive

Sends or schedules a push campaign to audience app users who allow push notifications, skipping those who do not.

Instructions

Send the push campaign now, or schedule it with scheduled_at. It goes to its audience's app users who allow push; the rest are skipped. The campaign must be a draft or scheduled with every required field set. Call get-push-campaign first and show the user its content. Tell the user the audience: if you set it in this conversation, name those lists, tags and segments and their sizes (get-list, get-segment). The campaign's own record doesn't include its audience, so otherwise ask the user to confirm it in the Arsel dashboard. This reaches real people, and a message that has gone out cannot be recalled. Before calling it, show the user what will go out and to whom, and wait for their go-ahead. A scheduled, queued or sending campaign can be stopped with cancel-push-campaign.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "send-push-campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe push campaign id.
scheduled_atNoISO 8601 date-time in the future, with the user's UTC offset (e.g. 2026-12-01T09:00:00+03:00 for Saudi Arabia), to schedule the campaign. Omit to send now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the irreversibility signal is partly structured. The description nevertheless adds real context beyond them: the message cannot be recalled, only app users who allow push receive it while the rest are skipped, and the campaign record omits its audience so confirmation must sometimes happen in the Arsel dashboard.

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?

Front-loaded with the core action and mode selection, then the preconditions, then the safety ritual. It repeats the 'show the user what goes out and to whom' instruction twice and restates irreversibility, which costs some tightness, but every block is informative rather than padding.

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

Completeness4/5

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

The stakes and preconditions of a destructive, irreversible, open-world send are fully covered, including the audience-confirmation fallback and the cancellation route. It says nothing about the response or what happens on a rejected send (e.g. campaign not in draft), a minor gap given there is no output schema.

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

Parameters3/5

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

Schema coverage is 100% for both parameters, including the ISO 8601 format, UTC-offset example and the 'omit to send now' semantics, so the schema does the heavy lifting. The description restates the scheduling choice with scheduled_at but adds no syntax or edge-case detail beyond it.

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

Purpose4/5

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

States a concrete verb and resource – 'Send the push campaign now, or schedule it with scheduled_at' – which pins down both the action and its two modes. It implicitly separates itself from the raw send-push sibling by scoping to campaigns, but never names that alternative explicitly, so an agent must infer the boundary.

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?

Gives explicit preconditions (must be draft or scheduled with every required field set), a mandatory workflow (call get-push-campaign first, show the content, tell the user the audience and list/tag/segment sizes), a confirmation requirement, and a named alternative (cancel-push-campaign) for stopping a campaign already queued or sending. This is about as complete as when-to-use guidance gets.

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

Deploy Server

Other Tools