Skip to main content
Glama
AarsyDesign

PushNotif MCP Server

by AarsyDesign
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

create_qris_invoice

Generate a QRIS invoice to top up PushNotif credits via Indonesian banks or e-wallets. Returns a pending checkout URL and adds credits after payment confirmation.

Instructions

Create a prepaid credit top-up invoice payable via Indonesian QRIS (all banks and e-wallets) at a flat rate of Rp 0.20 per credit (Rp 1,000 = 5,000 lifetime credits). Use this tool when the user wants to add credit balance; do not use it to check whether an existing invoice has been paid (use check_billing_and_qris_status instead). Requires PUSHNOTIF_API_KEY, creates a PENDING order valid for 30 minutes, and automatically adds non-expiring credits upon payment webhook confirmation. Provide either package_id ('starter'=Rp 20,000, 'growth'=Rp 50,000, 'pro'=Rp 100,000) or a custom amount_rp (>= 1000). Returns JSON { ok, order: { id, amount_rp, credits_added, status, qris_checkout_url, expires_at } }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amount_rpNoCustom top-up amount in Indonesian Rupiah (minimum 1000, maximum 10000000; 1 IDR = 5 credits)
package_idNoPreset package tier: 'starter' (Rp 20,000 = 100,000 credits), 'growth' (Rp 50,000 = 250,000 credits), or 'pro' (Rp 100,000 = 500,000 credits); overridden if amount_rp is explicitly provided

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.2
    • changedInput schema / properties / amount_rp / description
      Previous value: -"Nominal Rupiah top-up (default: 20000)"New value: +"Custom top-up amount in Indonesian Rupiah (minimum 1000, maximum 10000000; 1 IDR = 5 credits)"
    • changedInput schema / properties / package_id / description
      Previous value: -"Pilih paket: starter, growth, atau pro (opsional jika mengisi amount_rp)"New value: +"Preset package tier: 'starter' (Rp 20,000 = 100,000 credits), 'growth' (Rp 50,000 = 250,000 credits), or 'pro' (Rp 100,000 = 500,000 credits); overridden if amount_rp is explicitly provided"
  2. First observedv2.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), and the description adds materially beyond them: requires PUSHNOTIF_API_KEY, creates a PENDING order valid for 30 minutes, and credits are non-expiring and only granted on payment webhook confirmation. That lifecycle and credential detail is not derivable from the annotations.

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 purpose, then usage routing, then credentials/lifecycle, then return shape — a well-ordered single paragraph. It is somewhat dense and repeats the package pricing already in the schema, so a small amount of text does not earn its place.

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 no-required-param mutation tool with no output schema, the description supplies everything an agent needs: auth requirement, order lifecycle and expiry, when credits land, and an inline return shape ({ ok, order: {...} }). Nothing critical is left to inference.

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 both parameters (amount_rp, package_id) are already fully documented, including the override relationship. The description restates the package tiers and built-in minimum but adds no syntax or format detail beyond the schema, which is the baseline-3 case.

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 ('Create a prepaid credit top-up invoice payable via Indonesian QRIS') and immediately scopes it to banks/e-wallets and the pricing model. An agent can distinguish this from the many account/app/push siblings without opening any 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?

Explicitly gives the trigger ('when the user wants to add credit balance') and a negative case with a named alternative ('do not use it to check whether an existing invoice has been paid (use check_billing_and_qris_status instead)'). This is exactly the when/when-not/alternative structure that removes ambiguity.

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