Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send Push Notification

send-push
Destructive

Sends a push notification to one contact across all active devices, identified by contact ID, email, phone, or external ID; confirm the message and recipient before sending.

Instructions

Send a push notification to one contact; every active device they registered receives it. Identify the contact with contact_id alone, or with any of external_id, email and phone_number. Contacts who turned push off are skipped. 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. See what was sent with list-push-notifications.

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": {
      "title": "<title>",
      "body": "<body>"
    },
    "name": "send-push"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes
emailNo
titleYes
categoryNoLabel for grouping in analytics, e.g. `order_update` or `otp`.
icon_urlNoSmall icon, https only.
priorityNo
deep_linkNoOpened when the notification is tapped.
image_urlNoLarge image, https only.
contact_idNoArsel contact id, from list-contacts. Cannot be combined with `external_id`, `email` or `phone_number`.
external_idNoThe organization's own user id for the contact.
ttl_secondsNoHow long delivery is retried for an offline device.
data_payloadNoFlat string map delivered to the app. Keys reserved by Arsel or Firebase are rejected.
phone_numberNoE.164 phone number, e.g. +966501234567.
action_buttonsNo
android_channel_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructiveHint/openWorldHint annotations, it discloses that the message reaches real people, that it cannot be recalled once sent, and that delivery fans out to all active devices — exactly the consequences an agent needs before a non-idempotent send.

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

Conciseness5/5

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

Front-loads the action and scope, then identity rules, then the safety warning and the follow-up pointer — four tight sentences with no filler.

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?

For a 15-parameter, non-idempotent send with no output schema, the description covers identity, fan-out, irreversibility and confirmation. It stops short of saying what the call returns or how partial device failures are reported, which it defers to list-push-notifications.

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?

Clarifies the contact-identity contract ('contact_id alone, or any of external_id, email and phone_number'), which reinforces rather than merely repeats the schema's exclusivity note. It leaves the delivery-tuning params (ttl_seconds, priority, category, data_payload) to the schema, which covers them at 60%.

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

Purpose5/5

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

States a specific verb and resource ('Send a push notification') plus the delivery scope ('to one contact; every active device they registered receives it'), which distinguishes it from campaign-style siblings without needing their names.

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 pre-call guidance ('show the user what will go out and to whom, and wait for their go-ahead'), explains which contacts are skipped, and points to list-push-notifications for verification after the fact.

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