Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Payme MCP Server Generate a checkout link for 50,000 UZS"
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.
MCP server for Payme — the leading payment system in Uzbekistan. Enables AI agents (Claude, GPT, Cursor, etc.) to process payments, manage cards, and generate checkout links through the Model Context Protocol.
Stripe, PayPal, and Square all have MCP servers. Payme didn't — until now. If you're building AI agents for Uzbekistan's market, this is the missing piece.
Related MCP server: payme-mcp
Tool | Description |
| Tokenize a payment card (Uzcard, Humo) |
| Verify card with SMS code |
| Check if a card token is valid |
| Remove a saved card |
| Create a payment receipt (invoice) |
| Pay a receipt with a card token |
| Send receipt notification via SMS |
| Cancel/refund a receipt |
| Check receipt status |
| Generate a Payme checkout payment link |
npx payme-mcpThat's it. One command — downloads, installs, and runs automatically.
Get your credentials from merchant.paycom.uz, then add to your AI tool:
Add to claude_desktop_config.json:
{
"mcpServers": {
"payme": {
"command": "npx",
"args": ["-y", "payme-mcp"],
"env": {
"PAYME_ID": "your_merchant_id",
"PAYME_KEY": "your_merchant_key",
"PAYME_TEST": "true"
}
}
}
}Add to .mcp.json in your project root:
{
"mcpServers": {
"payme": {
"command": "npx",
"args": ["-y", "payme-mcp"],
"env": {
"PAYME_ID": "your_merchant_id",
"PAYME_KEY": "your_merchant_key",
"PAYME_TEST": "true"
}
}
}
}Add to MCP settings:
{
"payme": {
"command": "npx",
"args": ["-y", "payme-mcp"],
"env": {
"PAYME_ID": "your_merchant_id",
"PAYME_KEY": "your_merchant_key"
}
}
}Once connected, your AI agent can:
Create a payment link:
"Generate a Payme checkout link for order #1234, amount 99,000 UZS"
Process a card payment:
"Tokenize card 8600XXXXXXXXXXXX, verify it, then charge 50,000 UZS"
Check payment status:
"Check the status of receipt 63abc..."
Cancel a payment:
"Cancel receipt 63abc... and notify the customer"
Variable | Required | Description |
| Yes | Your Payme merchant ID |
| Yes | Your Payme merchant key |
| No | Set to |
Payme uses tiyin (1 UZS = 100 tiyin):
UZS | Tiyin |
1,000 | 100,000 |
9,900 | 990,000 |
99,000 | 9,900,000 |
990,000 | 99,000,000 |
State | Meaning |
0 | Created (waiting for payment) |
4 | Paid |
21 | Held (funds reserved) |
50 | Cancelled |
git clone https://github.com/sirliboyev-uz/payme-mcp.git
cd payme-mcp
npm install
npm run buildCard numbers are tokenized by Payme — tokens are safe to store
Never log or store raw card numbers
Use PAYME_TEST=true for development/testing
All API calls use HTTPS
MIT — see LICENSE
Built by SirliAI
Check if a card token is valid and get card details (masked number, expiry, status). Example: cards_check({ token: '630e5e...' })
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Card token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation (checking validity) and lists returned fields, but does not disclose permissions, side effects, or rate limits. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence stating purpose and an example. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers the return values (masked number, expiry, status). It is nearly complete, though error scenarios or validation constraints could add polish.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Card token'. The description adds an example but no additional semantic meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating a card token and returning card details (masked number, expiry, status). This distinguishes it from sibling tools like cards_create or cards_verify, which have different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The example provides a usage pattern but does not differentiate it from siblings like cards_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tokenize a payment card (Uzcard, Humo). Returns a reusable token. After creation, verify the card with SMS code using cards_verify. Example: cards_create({ cardNumber: '8600123456789012', expire: '0399' })
| Name | Required | Description | Default |
|---|---|---|---|
| save | No | Save card for future use | |
| expire | Yes | Card expiry in MMYY format (e.g. '0399') | |
| cardNumber | Yes | 16-digit card number (e.g. '8600123456789012') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the return of a reusable token and provides an example, but lacks details on side effects, security, error handling, or the role of the 'save' parameter, which is important given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a clear code example. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, flow, and example, but lacks details on the 'save' parameter's effect and the output token format. With no output schema, this gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the schema by specifying supported card types (Uzcard, Humo) and the output nature (reusable token). Schema coverage is 100%, so baseline 3 is exceeded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tokenizes a payment card (Uzcard, Humo) and returns a reusable token. It distinguishes from sibling tools by implication (creation vs. verification/removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use cards_verify after creation, providing a clear usage flow. However, does not discuss 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.
Remove a saved card token. The token will no longer be usable. Example: cards_remove({ token: '630e5e...' })
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Card token to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It indicates the action is destructive ('will no longer be usable'), but does not disclose additional behavioral details such as error states, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example. Every element contributes meaning without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema or annotations, the description is fairly complete. It covers purpose, consequence, and provides an example. Minor gaps include missing return value or error handling information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter described in schema). The description adds an example value ('630e5e...') but does not elaborate on format or constraints beyond the schema. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Remove a saved card token') and the resource ('card token'). It clearly distinguishes from sibling tools like cards_create and cards_verify, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a concrete example of usage and states the consequence ('will no longer be usable'). However, it does not explicitly mention when to prefer this tool over alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a card using the SMS code sent to the cardholder. Must be called after cards_create. Example: cards_verify({ token: '630e5e...', code: '666666' })
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | SMS verification code | |
| token | Yes | Card token from cards_create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavioral traits like idempotency, error handling, or rate limits. Only mentions verifying with SMS, leaving agent uninformed about important behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, front-loaded with purpose, no wasted words. Very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 parameters, but missing output description (e.g., what a successful verification returns). Precondition is stated, but completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds a concrete example but no additional semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (verify a card using SMS code) and distinguishes from siblings by specifying it must be called after cards_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Must be called after cards_create', providing a clear usage guidance of when to use. Does not mention when not to use or alternatives, but the precondition is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay a receipt using a verified card token. The card must be verified first. Example: receipts_pay({ receiptId: '63...', token: '630e5e...' })
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Verified card token from cards_verify | |
| receiptId | Yes | Receipt ID from receipts_create |
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 discloses the action and prerequisite but does not mention side effects, return values, or limitations (e.g., whether the token expires after use). The transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, with no redundancy. The main action is stated first, then prerequisite, then example. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the essential purpose, prerequisite, and an example. It could mention the return value or failure cases, but it is sufficient for most usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described. The tool description adds an example that clarifies the format, but it does not significantly enhance meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Pay a receipt' using a verified card token. It distinguishes from sibling tools like receipts_send and cards_verify by specifying the payment action and requiring a verified card token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite 'The card must be verified first,' giving clear usage context. It does not mention when not to use or alternatives, but the condition is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send receipt notification to customer via SMS. Example: receipts_send({ receiptId: '63...', phone: '998901234567' })
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number (e.g. '998901234567') | |
| receiptId | Yes | Receipt ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It describes the basic action but omits potential side effects, prerequisites (e.g., customer consent), or limitations (e.g., rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an example, front-loading the core action. No superfluous words, making it highly concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description covers the basic purpose and provides an example. However, it lacks details on return values or error conditions, and does not address usage context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds an example but does not provide significant additional meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a receipt notification via SMS, specifying the verb, resource, and medium. It distinguishes itself from sibling tools like cards_create or receipts_pay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use this tool. Alternatives are not mentioned, and context for preferring this over related tools like receipts_pay is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cards_checkcards_createcards_removecards_verifyreceipts_payreceipts_sendScored across 6 tools
Each tool has a clear, distinct purpose: card token lifecycle (create, check, verify, remove) and receipt actions (pay, send). No overlap or ambiguity.
All tools follow a consistent snake_case verb_noun pattern: cards_create, cards_check, cards_verify, cards_remove, receipts_pay, receipts_send.
6 tools is well-scoped for a payment card and receipt management server. Each tool earns its place without unnecessary bloat or deficiency.
Covers the full card token lifecycle and key receipt operations. Minor gap: no refund or receipt status query, but core workflow (tokenize, verify, pay) is complete.
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.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Agent Commerce Protocol MCP — bridges Stripe ACP + Google AP2 + Coinbase x402 for agent payments
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
