Which integrations are available for this server?

Provides tools for creating payment sessions, querying transaction status, handling refunds, and more through Ant International's Antom payment APIs, which are built on Alipay's payment infrastructure.

How do I use Antom MCP Server?

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., "@Antom MCP Server create a new payment session for $50" 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.

Antom MCP Server

Official

by ant-intl

Overview Schema Related Servers Score Discussions(1)

Python

Remote

Antom MCP Server

A Model Context Protocol (MCP) compatible server that integrates Ant International's Antom payment APIs, enabling AI assistants to handle payment and refund operations seamlessly.

Overview

The Antom MCP Server wraps Ant International's Antom payment APIs into standardized MCP tools, allowing AI assistants to securely process payment-related operations during conversations. With this server, you can create payment sessions, query transaction status, handle refunds, and more directly through AI interactions.

Related MCP server: AlipayPlus MCP Server

Features

💳 Payment Operations

Create Payment Session (create_payment_session): Generate payment sessions for client-side SDK integration
Query Payment Details (query_payment_detail): Retrieve transaction status and information for submitted payment requests
Cancel Payment (cancel_payment): Cancel payments when results are not returned within expected timeframes

💰 Refund Operations

Create Refund (create_refund): Initiate full or partial refunds against successful payments
Query Refund Details (query_refund_detail): Check refund status for previously submitted refund requests

Prerequisites

Before using the Antom MCP Server, ensure you have:

Python 3.11 or higher
uv (recommended package manager) or pip
Valid Antom Merchant Account with:
- Merchant Client ID (CLIENT_ID)
- Merchant RSA Private Key (MERCHANT_PRIVATE_KEY)
- Alipay RSA Public Key (ALIPAY_PUBLIC_KEY)
- Payment Redirect Return URL (PAYMENT_REDIRECT_URL)
- Payment Notification Callback URL (PAYMENT_NOTIFY_URL)

Quick Start

1. Installation

Direct Usage with uvx (Recommended)

uvx ant-intl-antom-mcp

Install from Source

git clone https://github.com/alipay/global-antom-mcp.git
cd global-antom-mcp
uv install

2. MCP Client Configuration

Add the following configuration to your MCP client:

{
  "mcpServers": {
    "antom-mcp-server": {
      "command": "uvx",
      "args": ["ant-intl-antom-mcp"],
      "env": {
        "GATEWAY_URL": "https://open-sea-global.alipay.com",
        "CLIENT_ID": "your_client_id_here",
        "MERCHANT_PRIVATE_KEY": "your_merchant_private_key_here",
        "ALIPAY_PUBLIC_KEY": "your_alipay_public_key_here",
        "PAYMENT_REDIRECT_URL": "/",
        "PAYMENT_NOTIFY_URL": "https://your-domain.com/payment/notify"
      }
    }
  }
}

3. Environment Variables

Variable	Required	Description
`GATEWAY_URL`	❌	Antom API gateway URL (defaults to https://open-sea-global.alipay.com)
`CLIENT_ID`	✅	Merchant client ID for identity verification
`MERCHANT_PRIVATE_KEY`	✅	Merchant RSA private key for request signing
`ALIPAY_PUBLIC_KEY`	✅	Alipay RSA public key for response verification
`PAYMENT_REDIRECT_URL`	❌	The user is redirected to after the payment is completed
`PAYMENT_NOTIFY_URL`	❌	Payment result notification callback URL

Integration Example

Here's how you can integrate the Antom MCP Server with your AI agent (using QwenAgent as an example):

import os
from qwen_agent.agents import Assistant

# Configure the MCP server as a tool
tools = [{
    "mcpServers": {
        "antom-mcp-server": {
            "command": "uvx",
            "args": ["ant-intl-antom-mcp"],
            "env": {
                "CLIENT_ID": os.getenv('CLIENT_ID'),
                "MERCHANT_PRIVATE_KEY": os.getenv('MERCHANT_PRIVATE_KEY'),
                "ALIPAY_PUBLIC_KEY": os.getenv('ALIPAY_PUBLIC_KEY'),
                "GATEWAY_URL": "https://open-sea-global.alipay.com",
                "PAYMENT_REDIRECT_URL": "/",
                "PAYMENT_NOTIFY_URL": "https://your-domain.com/notify"
            }
        }
    }
}]

# Create your AI assistant with payment capabilities
bot = Assistant(
    llm={'model': 'qwen-max', 'api_key': 'your-api-key'},
    function_list=tools,
    system_message="You are a helpful assistant with payment processing capabilities."
)

Changelog

See CHANGELOG.md for a detailed history of changes.

License

This project is licensed under the MIT License.

Acknowledgments

Model Context Protocol for the standard
Antom Integration for the Antom payment platform

Available Tools

5 tools

cancel_paymentA

The tool is used to cancel the payment if the payment result is not returned after a long time. The cancellation cannot be performed if being out of the cancellable period specified in the contract.

    Args:
        payment_request_id: The unique ID that is assigned by a merchant to identify a payment request.Maximum length: 64 characters

ParametersJSON Schema

Name	Required	Description	Default
`payment_request_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist; description adds cancellable period constraint but lacks disclosure of side effects, auth needs, or error scenarios.

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?

Three sentences cover purpose, constraint, and param – concise, but the Args block could be integrated for better flow.

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

Completeness3/5

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

Adequate for a one-param tool with output schema; missing return value hints or error conditions like duplicate cancellation.

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 0%, but description explains payment_request_id's meaning and max length, adding value beyond the schema's title and type.

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 tool cancels a payment when the result is not returned after a long time, distinguishing it from sibling tools like create_payment_session and create_refund.

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?

It specifies when to use (long timeout) and when not (outside cancellable period), but does not guide against siblings like refund, which could be an alternative.

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

create_payment_sessionA

The tool is used to create a payment session which helps you complete the payment process and eliminate intermediate page redirections throughout the entire payment process.

    Args:
        payment_request_id: The unique ID assigned by a merchant to identify a payment request. Maximum length: 64 characters
        order_amount_currency: The transaction currency that is specified in the contract. A 3-letter currency code that follows the ISO 4217 standard.Maximum length: 3 characters
        order_amount_value: The amount to charge as a positive integer in the smallest currency unit. (That is, 100 cents to charge $1.00, or 100 to charge JPY 100, a 0-decimal currency).Value range: 1 - unlimited
        order_description: Summary description of the order, which is used for user consumption records display or other further actions.Maximum length: 256 characters

ParametersJSON Schema

Name	Required	Description	Default
`payment_request_id`	Yes
`order_amount_currency`	Yes
`order_amount_value`	Yes
`order_description`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description implies a write operation (creation) but doesn't disclose side effects, idempotency, or required permissions. It adds parameter constraints but lacks deeper behavioral context.

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 front-loaded with purpose and then lists parameters clearly. It's concise with no unnecessary words, though it could be slightly more structured (e.g., bullet points for parameters).

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

Completeness3/5

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

Given the complexity of a payment tool, the description covers parameter constraints but omits error conditions, prerequisites, or return behavior (though output schema exists). It's adequate but not comprehensive.

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 description coverage is 0%, but the description adds constraints (max lengths, currency format, value range) for all 4 parameters, significantly enhancing meaning beyond the schema's title and type.

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 tool creates a payment session and its benefit of eliminating redirections. It is a specific verb+resource and distinct from sibling tools (cancel, refund, query).

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?

No guidance on when to use this tool versus alternatives. The description only states what it does, without explaining when to prefer it over siblings like query_payment_detail or create_refund.

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

create_refundA

The tool is used to initiate a refund against a successful payment. The refund can be full or partial. A transaction can have multiple refunds as long as the total refund amount is less than or equal to the original transaction amount. If the refund request is out of the refund window determined in the contract, the refund request will be declined.

    Args:
        refund_request_id: The unique ID assigned by the merchant to identify a refund request.Maximum length: 64 characters
        payment_id: The unique ID assigned by Antom for the original payment to be refunded.Maximum length: 64 characters
        refund_amount_currency: The currency used for the corresponding payment of the refund. The value is a 3-letter currency code that follows the ISO 4217 standard.
        refund_amount_value: The amount to charge as a positive integer in the smallest currency unit. (That is, 100 cents to charge $1.00, or 100 to charge JPY 100, a 0-decimal currency).Value range: 1 - unlimited

ParametersJSON Schema

Name	Required	Description	Default
`refund_request_id`	Yes
`payment_id`	Yes
`refund_amount_currency`	Yes
`refund_amount_value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Discloses refund limits and window enforcement, but with no annotations, it omits idempotency, side effects, or error handling specifics.

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?

Concise, well-structured, with purpose, conditions, and parameter details in a logical order without redundancy.

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?

Covers core behavior and parameter semantics; could mention return value structure or error scenarios, but output schema exists and complexity is low.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Each parameter is described with purpose, format, and constraints (e.g., refund_amount_value as smallest currency unit), adding significant value beyond the schema titles.

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 tool initiates a refund against a successful payment, distinguishing it from siblings like cancel_payment or create_payment_session.

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 conditions for use (full/partial refund, multiple refunds allowed, refund window) but lacks explicit when-not-to-use or alternatives.

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

query_payment_detailA

The tool is used to inquire about the transaction status and other information about a previously submitted payment request.

    Args:
        payment_request_id: The unique ID that is assigned by a merchant to identify a payment request.Maximum length: 64 characters

ParametersJSON Schema

Name	Required	Description	Default
`payment_request_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states 'inquire' implying a read-only operation, but does not disclose behavioral traits such as what happens if the payment request ID is invalid, authentication requirements, or any side effects. The description is minimal beyond the basic purpose.

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?

The description is concise with two sentences and a structured Args block. It is front-loaded with the purpose and includes parameter documentation without unnecessary words. Every sentence adds value.

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

Completeness3/5

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

Given that an output schema exists, the description does not need to explain return values. However, it lacks information about error handling, prerequisites, or what to do if the payment request ID does not exist. The description is adequate for a simple query tool but could be more complete.

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?

Although schema coverage is 0%, the description adds meaning to the payment_request_id parameter by stating it is a unique ID assigned by a merchant and specifying a maximum length of 64 characters. This provides context beyond the schema's type and title.

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 tool is used to inquire about transaction status and other information for a previously submitted payment request, using a specific verb ('inquire') and resource ('transaction status and other information'). It distinguishes from siblings like cancel_payment or create_refund which serve different purposes.

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?

The description implies usage for querying previously submitted payment requests but does not explicitly state when to use it versus alternatives (e.g., query_refund_detail) or when not to use it. No exclusions or context for when this tool is appropriate are provided.

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

query_refund_detailB

The tool is used to inquire about the refund status of a previously submitted refund request.

    Args:
        refund_request_id: The unique ID assigned by the merchant to identify a refund request.Maximum length: 64 characters

ParametersJSON Schema

Name	Required	Description	Default
`refund_request_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description must cover behavioral traits. It states query intent but lacks disclosure of auth requirements, rate limits, error handling, or implications of invalid IDs.

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?

Description is concise with a clear opening sentence and minimal redundancy, though the Args section duplicates schema information.

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

Completeness3/5

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

Given known output schema and simple tool, description covers core purpose and parameter meaning, but omits prerequisites, error states, and usage guidance.

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?

With 0% schema description coverage, description adds meaning by explaining refund_request_id as merchant-assigned unique ID and imposing a 64-character limit, but lacks format or example.

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 uses specific verb 'inquire' and resource 'refund status', and clarifies it applies to 'previously submitted refund request', distinguishing it from siblings like create_refund and cancel_payment.

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?

Implicitly indicates use after submitting a refund request, but does not explicitly state when to use this versus siblings like create_refund or query_payment_detail, nor provides exclusion criteria.

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 updatesv1.0.1May 30, 2026
- First observedcancel_payment
- First observedcreate_payment_session
- First observedcreate_refund
- First observedquery_payment_detail
- First observedquery_refund_detail

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool handles a distinct payment operation: creating a payment session, canceling a pending payment, creating a refund, querying payment details, and querying refund details. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., cancel_payment, create_payment_session, create_refund). This provides a predictable and clear naming convention.

Tool Count5/5

With 5 tools, the server is well-scoped for payment processing. The count is neither too few nor too many, covering core payment lifecycle operations without unnecessary clutter.

Completeness5/5

The tool set covers the essential payment operations: initiation, cancellation, refund, and status queries for both payments and refunds. No obvious gaps exist for a typical payment processing workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

Satim Payment Gateway
Finance Developer Tools
zakblacki
A
license
A
quality
C
maintenance
A Model Context Protocol (MCP) server for integrating with the SATIM payment gateway system in Algeria, enabling AI assistants to process CIB/Edhahabia card payments through the SATIM-ePAY platform.
Updated 3 months ago (2026-06-17 00:13 UTC)
5
18
15
GPL 3.0
AlipayPlus MCP Serverofficial
Payments & Billing Finance
alipay
A
license
A
quality
D
maintenance
Integrates Ant International's AlipayPlus payment APIs, enabling AI assistants to handle payment and refund operations seamlessly.
Updated a year ago (2025-07-16 06:29 UTC)
6
8
MIT
WorldFirst MCP Server
Finance Payments & Billing
socialworldfirst
F
license
Not graded
quality
D
maintenance
MCP server that gives AI agents access to WorldFirst cross-border payment APIs, enabling autonomous balance checks, FX quotes, supplier management, and payments.
Updated 6 months ago (2026-03-15 14:46 UTC)
-
YooKassa MCP Server
Payments & Billing E-commerce & Retail
Belolipetsky
A
license
Not graded
quality
B
maintenance
MCP server for the YooKassa payment API, enabling AI assistants to manage payments, refunds, receipts, webhooks, and saved payment methods through natural language.
Updated a month ago (2026-07-29 21:49 UTC)
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/ant-intl/global-antom-mcp'

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

Antom MCP Server

Overview

Features

💳 Payment Operations

💰 Refund Operations

Prerequisites

Quick Start

1. Installation

Direct Usage with uvx (Recommended)

Install from Source

2. MCP Client Configuration

3. Environment Variables

Integration Example

Changelog

License

Acknowledgments

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

AlipayPlus MCP Serverofficial

Latest Blog Posts

MCP directory API