Skip to main content
Glama
Sign In
PushNotif MCP Server

PushNotif MCP Server

by AarsyDesign
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

list_subscribers

Read-onlyIdempotent

Retrieve active subscriber records, segment tags, and platform breakdowns for a workspace or app_id to inspect audience size and platform distribution or find a subscriber_id before updating tags.

Instructions

Retrieve active subscriber device records, assigned segment tags, and platform breakdown counts (Web VAPID, Android FCM, iOS APNs) for the workspace or a specific app_id. Use this tool to inspect audience size, platform distribution, or obtain a subscriber_id before calling update_subscriber_tags; do not use it to view campaign click metrics (use get_campaign_analytics instead) or modify subscriber tags (use update_subscriber_tags instead). Read-only operation requiring PUSHNOTIF_API_KEY with 0 credit cost; filter by app_id and optional tag to narrow results. Returns JSON { total_active, platform_breakdown: { web, android_fcm, ios_apns }, subscribers: [{ id, app_id, platform, tags, created_at }] }.

Input Schema

NameRequiredDescriptionDefault
tagNoOptional segment tag filter (returns only subscribers carrying this tag)
limitNoMaximum number of subscriber records to return (1 to 100, default: 15)
app_idNoOptional application ID filter in format app_xxxx (omit to aggregate across all apps in the workspace)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.2.0
    • changedInput schema / properties / app_id / description
      Previous value: -"Optional application ID filter (format app_xxxx); omit to list subscribers across all workspace apps"New value: +"Optional application ID filter in format app_xxxx (omit to aggregate across all apps in the workspace)"
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of recent subscriber records to return (1 to 100, default: 15)"New value: +"Maximum number of subscriber records to return (1 to 100, default: 15)"
    • addedInput schema / properties / tag
      Added value: +{
+  "description": "Optional segment tag filter (returns only subscribers carrying this tag)",
+  "type": "string"
+}
  2. Changed2 schema fields changedv2.1.2
    • changedInput schema / properties / app_id / description
      Previous value: -"Opsional: filter untuk App ID tertentu"New value: +"Optional application ID filter (format app_xxxx); omit to list subscribers across all workspace apps"
    • changedInput schema / properties / limit / description
      Previous value: -"Jumlah baris pelanggan terbaru yang ditampilkan (default: 15)"New value: +"Maximum number of recent subscriber records to return (1 to 100, default: 15)"
  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?

Goes well beyond the annotations by disclosing the PUSHNOTIF_API_KEY requirement, zero credit cost, and the full JSON return shape — valuable since there is no output schema. It does not discuss pagination/truncation behavior for the limit parameter or how totals relate to the returned page, which keeps it from 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?

Purpose, alternatives, and constraints are front-loaded in the first two sentences, with the return shape last. It is a dense paragraph with some redundancy between the opening enumeration and the trailing return-JSON listing, but every element is functional for an agent without an output schema.

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?

Covers auth, cost, filtering, sibling routing, and return structure — everything an agent needs to call a read-only list tool with no output schema. The absence of an output schema is fully compensated by the inline JSON shape description.

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 all three parameters are already documented in the schema at a baseline of 3. The description reinforces app_id and tag as narrowing filters but adds no new semantics (e.g., how tag filtering interacts with platform_breakdown counts) and never mentions limit.

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 ('Retrieve active subscriber device records... platform breakdown counts') and enumerates exactly what is returned. It explicitly distinguishes itself from get_campaign_analytics and update_subscriber_tags, so an agent can route correctly without opening a 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?

Gives positive use cases (inspect audience size, platform distribution, obtain a subscriber_id before update_subscriber_tags) and two explicit exclusions with the alternative tool named for each. When-to-use and when-not-to-use are both covered.

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