Skip to main content
Glama
Sign In
PushNotif MCP Server

PushNotif MCP Server

by AarsyDesign
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

update_app_branding

Idempotent

Update an existing app's notification icon URL, automated welcome push message, and Android/iOS native credentials by app_id, changing only the fields provided.

Instructions

Update an existing application's notification icon URL, automated welcome push message, and optional native mobile push credentials (Android FCM HTTP v1 service account JSON and iOS APNs .p8 key). Use this tool to configure app-level branding, onboarding welcome alerts, or native mobile credentials; do not use it to create a new app (use create_app instead) or configure on-site HTML popups (use configure_inapp_banner instead). Prerequisite: call list_apps first to obtain app_id. Requires PUSHNOTIF_API_KEY and idempotently updates only the fields provided at 0 configuration cost (when welcome_enabled=true, each new subscriber welcome push deducts 1 credit; APNs requires apns_key_id, apns_team_id, apns_bundle_id, and apns_p8_key together). Returns JSON { ok, app_id, icon_url, welcome_enabled, android_fcm_configured, ios_apns_configured }.

Input Schema

NameRequiredDescriptionDefault
app_idYesTarget application ID in format app_xxxx (obtain from list_apps)
icon_urlNoOptional direct HTTPS URL to a square PNG/JPG/WebP brand icon (recommended 192x192px)
apns_key_idNoOptional 10-character Apple Developer APNs Key ID (provide together with apns_team_id, apns_bundle_id, and apns_p8_key)
apns_p8_keyNoOptional full PEM content of Apple's AuthKey_XXXX.p8 private key file
apns_team_idNoOptional 10-character Apple Developer Team ID
welcome_bodyNoBody text of the automated welcome push notification (max 180 characters; used when welcome_enabled=true)
welcome_titleNoHeadline of the automated welcome push notification (max 80 characters; used when welcome_enabled=true)
apns_bundle_idNoOptional iOS application Bundle Identifier (e.g., 'id.company.app')
welcome_enabledNoSet true to automatically send a welcome push notification immediately after a visitor subscribes
fcm_service_account_jsonNoOptional raw JSON string of Google Firebase Service Account key for native Android FCM HTTP v1 delivery

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.2.0
    • addedInput schema / properties / apns_bundle_id
      Added value: +{
+  "description": "Optional iOS application Bundle Identifier (e.g., 'id.company.app')",
+  "type": "string"
+}
    • addedInput schema / properties / apns_key_id
      Added value: +{
+  "description": "Optional 10-character Apple Developer APNs Key ID (provide together with apns_team_id, apns_bundle_id, and apns_p8_key)",
+  "type": "string"
+}
    • addedInput schema / properties / apns_p8_key
      Added value: +{
+  "description": "Optional full PEM content of Apple's AuthKey_XXXX.p8 private key file",
+  "type": "string"
+}
    • addedInput schema / properties / apns_team_id
      Added value: +{
+  "description": "Optional 10-character Apple Developer Team ID",
+  "type": "string"
+}
    • addedInput schema / properties / fcm_service_account_json
      Added value: +{
+  "description": "Optional raw JSON string of Google Firebase Service Account key for native Android FCM HTTP v1 delivery",
+  "type": "string"
+}
    • changedInput schema / properties / welcome_body / description
      Previous value: -"Body text of the automated welcome push notification (max 180 characters)"New value: +"Body text of the automated welcome push notification (max 180 characters; used when welcome_enabled=true)"
    • changedInput schema / properties / welcome_enabled / description
      Previous value: -"Set true to automatically send a welcome push notification immediately after a visitor grants permission"New value: +"Set true to automatically send a welcome push notification immediately after a visitor subscribes"
    • changedInput schema / properties / welcome_title / description
      Previous value: -"Headline of the automated welcome push notification (max 80 characters)"New value: +"Headline of the automated welcome push notification (max 80 characters; used when welcome_enabled=true)"
  2. Changed5 schema fields changedv2.1.2
    • changedInput schema / properties / app_id / description
      Previous value: -"App ID yang ingin diubah (misal: app_xxxx)"New value: +"Target application ID in format app_xxxx (obtain from list_apps)"
    • changedInput schema / properties / icon_url / description
      Previous value: -"URL gambar logo PNG/JPG aplikasi"New value: +"Optional direct HTTPS URL to a square PNG/JPG/WebP brand icon (recommended 192x192px)"
    • changedInput schema / properties / welcome_body / description
      Previous value: -"Isi pesan notifikasi sambutan"New value: +"Body text of the automated welcome push notification (max 180 characters)"
    • changedInput schema / properties / welcome_enabled / description
      Previous value: -"Aktifkan/matikan pesan sambutan otomatis"New value: +"Set true to automatically send a welcome push notification immediately after a visitor grants permission"
    • changedInput schema / properties / welcome_title / description
      Previous value: -"Judul notifikasi sambutan saat user baru klik Izinkan"New value: +"Headline of the automated welcome push notification (max 80 characters)"
  3. First observedv2.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses the auth requirement (PUSHNOTIF_API_KEY), partial-update behavior (only provided fields change), cost implications (1 credit per welcome push when welcome_enabled=true), the all-or-nothing APNs field group, and the return shape. The only gap is absence of any confirmation of irreversibility or rollback for credential overwrites, which keeps it 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.

Conciseness4/5

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

Front-loads the action and affected fields, then layers usage exclusions, prerequisites, and return contract in a logical order with zero filler sentences. It is dense and long for a single paragraph, but nearly every clause carries operational information.

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 10 parameters and no output schema, the description compensates by naming the returned JSON keys and stating the prerequisite and credential grouping rules. An agent has everything needed to invoke it correctly and interpret the response.

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 description coverage is 100%, so per-parameter meaning is already fully documented; the description mainly restates the field set. It does add cross-field semantics the schema cannot express — the APNs four-field coupling and the credit cost tied to welcome_enabled — but that added value is modest against a fully documented schema, so baseline 3 is fair.

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?

Names a specific verb+resource (update an existing application's branding) and enumerates exactly which fields it touches: icon URL, welcome push copy, and native mobile credentials. It also explicitly delineates from create_app and configure_inapp_banner, so an agent can distinguish it from siblings without opening schemas.

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 positive triggers (configure app-level branding, onboarding welcome alerts, native mobile credentials), explicit exclusions with named alternatives (use create_app instead, use configure_inapp_banner instead), and a prerequisite (call list_apps first to obtain app_id). 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.

Deploy Server

Other Tools