Loading ToolBench
MCP server for PayMongo — payments, GCash, Maya, refunds (Philippines)
PayMongo MCP has well-structured tool definitions with consistent naming (verb_noun pattern), comprehensive parameter descriptions, and proper Zod schema integration. All 24 tools have descriptions and input schemas. Tool annotations (readOnly/destructive) are present and correctly applied. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is basic (try/catch wrapping); no recovery guidance or categorization. Some parameter descriptions lack format constraints (e.g., 'amount in centavos' is clear, but webhook URLs lack validation hints). Composition is sound, tools chain well (e.g., create_payment_intent → get_payment_intent). Security: API key injection via environment is correct; no secrets in params.
Archive or unarchive a Payment Link.
Create a hosted checkout session (returns a checkout URL).
Create a customer record (stores PII for reuse across payments).
Create a PayMongo Payment Link (no-code shareable checkout). Returns a checkout_url and reference_number.
Charge a chargeable source to create a payment (moves money).
Create a PayMongo payment intent — the object that tracks a payment through its lifecycle.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects). Forces agents to guess what data is available for downstream tool calls.
Error handling is minimal. Errors are caught and returned as text with isError=true, but no recovery guidance, categorization (retryable vs fatal), or actionable next steps. LLMs cannot determine whether to retry, ask the user, or abort.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Create a payment method (e.g. a card) to attach to a payment intent. Handle card data with care.
Refund a payment, fully or partially (moves money back to the customer).
Create a GCash/GrabPay payment source (returns a redirect checkout URL).
Register a webhook endpoint for event delivery. The response includes the per-webhook signing secret (store it to verify signatures).
Retrieve a checkout session by its ID.
Retrieve a customer by its ID.
Retrieve a Payment Link by link_id, or look it up by reference_number.
Retrieve a PayMongo payment intent by its ID.
Retrieve a payment method by its ID.
Retrieve a refund by its ID.
Retrieve a payment source by its ID.
Retrieve a webhook by its ID.
List customers with cursor pagination (before/after by customer ID).
List payments with cursor pagination (before/after by payment ID).
List refunds with cursor pagination (before/after by refund ID).
List all registered webhooks.
Update a webhook's URL/events and/or enable/disable it. Provide any combination of url, events, enabled.
Locally verify a PayMongo webhook's 'Paymongo-Signature' header (HMAC-SHA256 over `timestamp.body`). No network call — uses the per-webhook signing secret you pass in.
create_payment_method accepts raw card details (card_number, exp_month, exp_year, cvc) as parameters. This is a PCI-DSS violation, card data should never transit through agent logs or traces. Recommend tokenization flow or server-side card handling.
Pagination parameters (before/after cursors) lack documentation of cursor format and behavior. LLMs cannot reliably construct pagination chains without explicit guidance on what cursor values look like and how to iterate.
No dry-run or confirmation mechanism for destructive operations (create_payment, create_refund, create_checkout). Agents can accidentally charge or refund without a safety gate.