MyFatoorah MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MYFATOORAH_BASE_URL | No | HTTPS override for a supported MyFatoorah deployment or test proxy. | Environment URL |
| MYFATOORAH_API_TOKEN | Yes | MyFatoorah API bearer token. Required to call the API. Never expose it to an agent prompt. | |
| MYFATOORAH_TIMEOUT_MS | No | Request timeout in milliseconds, from 1 to 300000. | 30000 |
| MYFATOORAH_ENVIRONMENT | No | MyFatoorah environment. One of: test, kuwait, uae, saudi_arabia, qatar, or egypt. | test |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| myfatoorah_get_payment_methodsA | List payment methods enabled for this account. Read ApiName from the result and pass it as paymentMethod when creating a hosted payment. |
| myfatoorah_create_paymentA | Creates a payment/invoice using POST /v3/payments. In a live environment this creates a real payable invoice. Omit paymentMethod to show all enabled methods; use notificationOption for invoicing. The returned PaymentURL is where the customer pays. |
| myfatoorah_get_paymentA | Gets authoritative payment details by PaymentId using GET /v3/payments/{paymentId}. Treat payment as successful only when Invoice.Status is PAID and Transaction.Status is SUCCESS. |
| myfatoorah_get_invoiceA | Gets an invoice by exactly one lookup type. Invoice ID uses /v3/invoices/{value}; external identifier returns the most recent matching invoice and uses /v3/invoices/externalIdentifier/{value}. |
| myfatoorah_create_refundA | Creates a real full or partial refund using POST /v3/refunds. This moves money in live environments. Call only after the user explicitly approves the exact PaymentId and amount; confirm must be true. |
| myfatoorah_get_refundA | Gets a refund by RefundId using GET /v3/refunds/{refundId}. Refund statuses include Refunded, Canceled, and Pending. |
| myfatoorah_api_requestA | Escape hatch for documented MyFatoorah v2/v3 endpoints not covered by another tool. Accepts only safe relative /v2/ or /v3/ paths and GET, POST, or PUT. Absolute URLs are blocked so credentials cannot be sent elsewhere. POST/PUT require confirm=true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| create-payment-safely | Guides an agent through safe payment-link creation and verification. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| myfatoorah-configuration | Safe runtime configuration. Never includes the API token. |
TDQS
Scored across 7 tools
Each core tool targets a distinct resource and action: payment methods, payments, invoices, and refunds are clearly separated. The api_request escape hatch is explicitly scoped to endpoints not covered by the other tools, so it complements rather than overlaps with them.
Six tools consistently follow the myfatoorah_verb_noun pattern, which is predictable and readable. The only deviation is myfatoorah_api_request, a noun-style escape hatch, which is a minor exception rather than a systemic inconsistency.
Seven tools is well-scoped for a payment-focused server: it covers payment methods, payment creation/retrieval, invoice retrieval, refund creation/retrieval, plus one generic escape hatch. Every tool earns its place, and the count is neither bloated nor too thin.
The set covers the core payment workflow: create payment, check payment status, retrieve invoice, create refund, and check refund status. It lacks explicit cancel/update/list operations, but the api_request escape hatch covers documented endpoints not individually modeled, so agents are not left with a hard dead end.