What can you do with this server?

This server lets an AI assistant create and manage JazzCash payments in Pakistan, including wallet payments, CNIC-enabled mobile account payments, OTC vouchers, status checks, and refunds. * Create a mobile wallet payment (create_payment) — send money to a JazzCash mobile wallet using the recipient's 03XXXXXXXXX number. * Create a CNIC-enabled mobile account payment (create_mobile_account_payment) — pay to a JazzCash Mobile Account using the customer's mobile number and last 6 CNIC digits. * Create an OTC voucher (create_voucher) — generate a voucher the customer redeems offline at a JazzCash outlet (no redeem API exists). * Check payment status (check_payment_status) — query a transaction's current status using its reference number. * Refund a payment (refund_payment) — reverse a transaction (irreversible; per JazzCash typically applies to card transactions). * All payment amounts are specified in PKR rupees and automatically converted to paisa for the JazzCash API. * Transaction references can be auto-generated if omitted; optional bill references can be provided for reconciliation.

How do I use jazzcash-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jazzcash-mcp Check wallet balance for 03001234567" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

jazzcash-mcp

by theYahia

Overview Schema Related Servers Score Discussions

TypeScript

Remote

JazzCash MCP — accept Pakistani mobile wallet payments from an AI assistant

If you were looking for a way to take JazzCash payments from Claude or another AI assistant, charge a CNIC-enabled Mobile Account, issue an over-the-counter voucher or refund a transaction without writing gateway code, this is it. 5 tools cover Mobile Wallet payments, Mobile Account payments, OTC vouchers, status inquiry and refunds. Requests are signed with the JazzCash HMAC-SHA256 secure hash, and responses are hash-verified.

Tools (5)

Tool	Type	Description
`create_payment`	write	Mobile Wallet (MWALLET) payment
`create_mobile_account_payment`	write	CNIC-enabled Mobile Account payment (MWALLET)
`create_voucher`	write	Over-The-Counter (OTC) voucher — returns a voucher number redeemed offline at an outlet
`check_payment_status`	read	Transaction status inquiry (`PaymentInquiry/Inquire`)
`refund_payment`	write, destructive	Refund a transaction (`authorize/Refund`; card transactions per JazzCash)

Related MCP server: paymongo-mcp

Quick Start

{
  "mcpServers": {
    "jazzcash": {
      "command": "npx",
      "args": ["-y", "@theyahia/jazzcash-mcp"],
      "env": {
        "JAZZCASH_MERCHANT_ID": "<YOUR_MERCHANT_ID>",
        "JAZZCASH_PASSWORD": "<YOUR_PASSWORD>",
        "JAZZCASH_INTEGRITY_SALT": "<YOUR_SALT>",
        "JAZZCASH_ENV": "sandbox"
      }
    }
  }
}

Environment Variables

Variable	Required	Default	Description
`JAZZCASH_MERCHANT_ID`	Yes	—	Merchant ID from the JazzCash portal
`JAZZCASH_PASSWORD`	Yes	—	Merchant password
`JAZZCASH_INTEGRITY_SALT`	Yes	—	HMAC integrity salt (shared secret)
`JAZZCASH_ENV`	No	`sandbox`	`sandbox` or `production`
`JAZZCASH_BASE_URL`	No	—	Full base URL override (e.g. for staging); takes precedence over `JAZZCASH_ENV`

The server fails fast at startup if the three required credentials are missing.

Amounts

All amount parameters are in PKR rupees (e.g. 5000 = 5000 PKR). The server converts to paisa (amount × 100, no decimal point) before signing, because JazzCash's pp_Amount is expressed in the lowest denomination. So 5000 is sent to JazzCash as pp_Amount=500000.

Sandbox vs Production

Environment	Host
sandbox (default)	`https://sandbox.jazzcash.com.pk/ApplicationAPI/API`
production	`https://payments.jazzcash.com.pk/ApplicationAPI/API`

The default is sandbox for safety. Set JAZZCASH_ENV=production (or a full JAZZCASH_BASE_URL) to go live.

Verify endpoints against your merchant portal. JazzCash exposes the same operation under slightly different path/version conventions depending on the merchant-account generation, and the modern token-wallet endpoint differs from the documented Payment API. The endpoint paths in src/config.ts are best-evidence canonical values cross-checked against the official docs and multiple integrations; confirm the exact paths and whether pp_Version is expected against the per-merchant API URLs shown in your JazzCash merchant portal before transacting real money.

Security

Request signing — every request carries an HMAC-SHA256 pp_SecureHash (integrity salt as both the prepended prefix and the HMAC key; empty fields excluded; lowercase hex). Verified against the official worked test vector in the test suite.
Response verification — responses that include a pp_SecureHash are recomputed and compared (constant-time); a mismatch raises an error rather than returning unverified data.
No secret leakage — pp_Password/pp_SecureHash are stripped from tool output, and upstream error bodies are never echoed back to the model (only redacted to stderr).

Demo Prompts

"Create a JazzCash payment of 5000 PKR to 03001234567"
"Check the status of transaction TXN-001"
"Refund 3000 PKR for transaction TXN-001"
"Create an OTC voucher for 2000 PKR for 03001234567 (CNIC 123456)"

Removed in 2.0 (and why)

2.0.0 removed three tools that targeted JazzCash endpoints which do not exist, verified against the official documentation and multiple independent integrations:

get_balance — JazzCash has no balance-inquiry API.
redeem_voucher — voucher redemption happens offline at a JazzCash outlet, not via a merchant API.
inquire_transaction — duplicated check_payment_status; both now use the canonical PaymentInquiry/Inquire.

Other breaking changes: create_mobile_account_payment now uses the real MWALLET transaction type (there is no MA type), create_voucher now issues an OTC voucher, amounts are in rupees (auto-converted to paisa), and txn_ref is optional (auto-generated when omitted). See CHANGELOG.md.

Development

npm install
npm run build   # tsc → dist/
npm test        # vitest (schema, hash test-vector, response verification, fetch mocking)
npm run dev     # run from source via tsx

License

MIT

Telegram: @vhodvai

Available Tools

5 tools

check_payment_statusA

Read-only

Look up the status of a JazzCash transaction by its reference (PaymentInquiry/Inquire). Read-only; returns the current pp_ResponseCode/pp_ResponseMessage for the queried transaction.

ParametersJSON Schema

Name	Required	Description	Default
`txn_ref`	Yes	Transaction reference number to inquire about

TDQS

A4.5/5.0

Behavior5/5

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

Consistent with annotations (readOnlyHint=true), adds detail about returned fields (pp_ResponseCode/pp_ResponseMessage) and idempotent nature. No contradiction.

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?

Two sentences, no redundant words, front-loaded with action and context.

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?

Single-parameter tool with annotations; description covers purpose, read-only nature, and return content adequately.

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 already describes txn_ref with 100% coverage; description adds no new parameter info beyond confirming reference usage.

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?

Clear verb ('look up'), resource ('JazzCash transaction status'), and method ('by its reference'). Distinguishes from sibling tools like create_payment and refund_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for status inquiry vs. creation/refund in siblings, but lacks explicit when-not or alternatives beyond stating 'Read-only'.

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

create_mobile_account_paymentA

Create a CNIC-enabled JazzCash Mobile Account payment (MWALLET with the last 6 CNIC digits). amount is in PKR rupees. Returns pp_ResponseCode/pp_ResponseMessage. Money-moving and non-idempotent.

ParametersJSON Schema

Name	Required	Description
`cnic`	Yes	Last 6 digits of the customer's CNIC
`amount`	Yes	Payment amount in PKR rupees (converted to paisa automatically)
`txn_ref`	No	Unique transaction reference (auto-generated if omitted)
`description`	No	Payment description
`mobile_number`	Yes	Mobile account number (03XXXXXXXXX)
`bill_reference`	No	Merchant bill reference for reconciliation (defaults to txn_ref)

TDQS

A3.5/5.0

Behavior4/5

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

The description adds 'Money-moving and non-idempotent' and specifies return fields (pp_ResponseCode/pp_ResponseMessage). The annotations already declare non-idempotent and non-read-only, so this adds useful context beyond the annotations, without contradiction.

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 two concise sentences, front-loading the core purpose. Every sentence adds value, though it could briefly mention the output structure for completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description lacks detail on the full return structure and prerequisites. It does not explain potential errors or safety considerations for a money-moving operation, making it incomplete.

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?

All parameters are described in the schema (100% coverage), so the description adds little beyond clarifying that amount is in PKR and that MWALLET uses CNIC digits. This is adequate but not transformative.

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 clearly states the verb 'Create' and the specific resource 'CNIC-enabled JazzCash Mobile Account payment', including the MWALLET detail and last 6 CNIC digits. This distinguishes it from sibling tools like create_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives like create_payment or refund_payment. It mentions 'Money-moving and non-idempotent' but does not clarify context or exclusions.

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

create_paymentA

Create a JazzCash Mobile Wallet (MWALLET) payment. amount is in PKR rupees (converted to paisa). txn_ref is auto-generated when omitted. Returns the JazzCash pp_ResponseCode/pp_ResponseMessage. Money-moving and non-idempotent — do not retry blindly.

ParametersJSON Schema

Name	Required	Description
`amount`	Yes	Payment amount in PKR rupees (converted to paisa automatically)
`txn_ref`	No	Unique transaction reference (auto-generated if omitted)
`description`	Yes	Payment description
`mobile_number`	Yes	Customer mobile wallet number (03XXXXXXXXX)
`bill_reference`	No	Merchant bill reference for reconciliation (defaults to txn_ref)

TDQS

A4.7/5.0

Behavior5/5

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

Discloses key behaviors beyond annotations: amount conversion to paisa, auto-generated txn_ref, return fields (pp_ResponseCode/pp_ResponseMessage), and non-idempotency warning. No contradiction with annotations (readOnlyHint=false, idempotentHint=false).

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?

Three sentences: first states purpose, second clarifies key parameter behavior, third warns about idempotency. No wasted words, front-loaded with essential 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?

Covers all essential aspects: purpose, parameter conversion, idempotency, response format, and non-idempotency warning. For a 5-parameter tool with no output schema, this description provides comprehensive context.

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?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining amount unit (PKR to paisa), txn_ref auto-generation, and response details. However, some info repeats schema descriptions (e.g., 'converted to paisa automatically').

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?

Clearly states the tool creates a JazzCash Mobile Wallet payment. Specifies verb 'Create' and resource 'JazzCash Mobile Wallet (MWALLET) payment'. Distinguishes from siblings like 'check_payment_status' and 'refund_payment' by focusing on MWALLET creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit warning: 'Money-moving and non-idempotent — do not retry blindly.' Also notes txn_ref auto-generation, guiding use when idempotency is needed. Lacks explicit mention of when to use versus siblings like 'create_mobile_account_payment'.

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

create_voucherA

Create a JazzCash Over-The-Counter (OTC) voucher payment. amount is in PKR rupees. The response carries a voucher number the customer redeems offline at a JazzCash outlet (there is no redeem API). Money-moving and non-idempotent.

ParametersJSON Schema

Name	Required	Description
`cnic`	Yes	Last 6 digits of the customer's CNIC
`amount`	Yes	Voucher amount in PKR rupees (converted to paisa automatically)
`txn_ref`	No	Unique transaction reference (auto-generated if omitted)
`description`	No	Voucher description
`mobile_number`	Yes	Customer mobile number (03XXXXXXXXX)
`bill_reference`	No	Merchant bill reference for reconciliation (defaults to txn_ref)

TDQS

A4/5.0

Behavior4/5

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

Description adds 'money-moving and non-idempotent,' confirming annotations. It also reveals the voucher is redeemed offline (no redeem API) and that the response includes a voucher number, providing behavioral context beyond annotations.

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?

Two dense sentences: first defines purpose and currency, second explains workflow and idempotency. No fluff, front-loaded with key info.

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 payment tool with 6 params (3 required) and no output schema, the description gives essential output hint (voucher number) and offline redemption flow. Lacks error handling or permission details, but adequate given context signals.

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 covers 100% of parameters with descriptions. Description only adds 'amount is in PKR rupees' which is redundant with schema's 'Voucher amount in PKR rupees.' No new semantic value beyond 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?

Description clearly states the tool creates a JazzCash OTC voucher payment, with specific verb and resource. It distinguishes from sibling tools like create_payment or create_mobile_account_payment by specifying 'Over-The-Counter (OTC) voucher'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for one-time offline voucher payments and notes non-idempotency, but does not explicitly compare to siblings or state when not to use this tool. Lacks explicit when-to-use vs alternatives guidance.

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

refund_paymentA

Destructive

Refund a JazzCash transaction (authorize/Refund). amount is in PKR rupees. IRREVERSIBLE — moves money back to the customer. Per JazzCash, refunds apply to card transactions; verify applicability for wallet/OTC.

ParametersJSON Schema

Name	Required	Description	Default
`amount`	Yes	Refund amount in PKR rupees (converted to paisa automatically)
`txn_ref`	Yes	Original transaction reference to refund

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true (irreversible). The description reinforces this and adds context about automatic paisa conversion and transaction type limitations, which is helpful beyond 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.

Conciseness5/5

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

Two sentences, no fluff, front-loaded with the core action and key constraints. Every sentence adds value.

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?

Given the tool has only two parameters and annotations cover safety, the description is fairly complete. It adds applicability notes but lacks any indication of return output, which is acceptable as there is no output schema defined.

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 coverage is 100% with descriptions for both parameters. The description mentions 'amount is in PKR rupees' which is already in the schema, adding no new semantic value. Baseline 3 is appropriate since the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool refunds a JazzCash transaction and specifies the currency (PKR rupees). The action and resource are unambiguous, but it doesn't explicitly distinguish from sibling tools like create_payment, which is acceptable given the naming.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises that refunds are irreversible and provides a caveat about applicability to card transactions only, urging verification for wallet/OTC. This gives reasonable guidance on when to use and what to check, though it does not specify alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv2.0.1Jul 30, 2026
- First observedcheck_payment_status
- First observedcreate_mobile_account_payment
- First observedcreate_payment
- First observedcreate_voucher
- First observedrefund_payment

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: status inquiry, wallet payment, CNIC-based payment, OTC voucher creation, and refund. Descriptions clearly differentiate them, with no functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., check_payment_status, create_payment), making it predictable for agents.

Tool Count5/5

With 5 tools covering creation, status, and refunds, the set is well-scoped for a payment MCP. No unnecessary tools and no obvious missing critical operations.

Completeness4/5

Covers core payment lifecycle: create (3 types), status, refund. Minor gaps like a tool to list all transactions or cancel a pending payment are absent, but the domain is sufficiently addressed.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

modern-treasury A
io.usefulapi
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Finance Payments & Billing
172
inflowOAuth
ai.inflowpay.app
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Agent Orchestration Autonomous Agents Payments & Billing
26
SIMcloud
za.co.simcloud
South African MCP server for airtime, data, SMS, VAS, electricity, balance, and network lookup.
Communication Finance Energy
2
autumn A
io.usefulapi
MCP server for Autumn — read customers, plans, balances & invoices; track usage and attach plans.
Payments & Billing CRM Customer Data Platforms
182

Related MCP Servers

vnpay-mcp
Payments & Billing Finance
theYahia
A
license
B
quality
D
maintenance
MCP server for VNPay payment gateway (Vietnam). Supports payment URL generation, transaction queries, refunds, tokenized payments, and IPN verification with HMAC-SHA512 signing.
Updated 5 months ago (2026-04-01 16:30 UTC)
8
10
MIT
paymongo-mcp
Payments & Billing Finance
theYahia
A
license
A
quality
B
maintenance
MCP server for PayMongo payment gateway (Philippines). Supports payment intents, sources, payments, refunds, and checkout sessions via Basic Auth.
Updated 5 days ago (2026-09-02 19:09 UTC)
24
20
2
MIT
maib-mcp
Payments & Billing E-commerce & Retail
theYahia
A
license
A
quality
D
maintenance
MCP server for MAIB e-commerce payments (Moldova). Supports payments, refunds, recurring billing, one-click payments, and transaction status via OAuth 2.0.
Updated 5 months ago (2026-04-01 16:29 UTC)
8
13
MIT
payme-mcp
Payments & Billing Finance
theYahia
A
license
B
quality
F
maintenance
MCP server for Payme payment system (Uzbekistan). Supports transactions, statements, payment links, and balance queries via JSON-RPC 2.0.
Updated 20 days ago (2026-08-18 13:02 UTC)
8
17
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/jazzcash-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server