Skip to main content
Glama

PushNotif Official MCP Server

update_app_branding

Idempotent

Update an existing application's notification icon URL, automated welcome push message (including drip delay welcome_delay_sec and promo target URL welcome_url), zero-downtime custom VAPID keys (vapid_public_key & vapid_private_key for migrating from OneSignal/LaraPush), 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, custom VAPID key migration, 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, welcome_url, welcome_delay_sec, custom_vapid_updated, 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
welcome_urlNoOptional target promo/onboarding HTTPS URL opened when the subscriber clicks the welcome push notification (defaults to site_url)
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
vapid_public_keyNoOptional URL-safe Base64 VAPID Public Key imported from OneSignal, LaraPush, or Webpushr for zero-downtime migration
vapid_private_keyNoOptional URL-safe Base64 or PEM VAPID Private Key paired with vapid_public_key
welcome_delay_secNoOptional drip delay in seconds (0 to 300, default: 0) before firing the welcome push notification after opt-in
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. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare non-read-only, idempotent, non-destructive behavior, but the description adds important operational context: PUSHNOTIF_API_KEY is required, only provided fields are updated, welcome pushes can deduct credits, and APNs fields must be supplied together. These details materially help an agent invoke the tool safely.

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?

The description is dense but front-loads the update action and then layers use cases, exclusions, prerequisites, operational notes, and return shape. It could be split for readability, but every section adds useful routing or behavioral 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?

For a 14-parameter mutation tool with no output schema, the description is unusually complete: it covers purpose, exclusions, prerequisites, authentication, cost behavior, field dependencies, and even the return JSON keys.

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 the schema already documents all 14 parameters thoroughly. The description adds some grouping and reinforces the APNs field dependency, but most parameter semantics are already covered by 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?

The description states a specific verb and resource: update an existing application's notification icon, welcome push, VAPID keys, and mobile credentials. It clearly distinguishes this tool from create_app and configure_inapp_banner, so an agent can route correctly.

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?

It explicitly lists when to use the tool: app-level branding, onboarding welcome alerts, custom VAPID migration, and native mobile credentials. It also names alternatives for excluded cases and states the prerequisite to call list_apps for app_id.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.