Сервер MCP (Model Context Protocol), который обеспечивает бесшовную интеграцию с платежными API Payman AI, позволяя помощникам на базе ИИ создавать получателей платежей, искать существующих получателей платежей, отправлять платежи и проверять балансы с помощью естественного языка.
Этот сервер MCP раскрывает платежную функциональность Payman AI как инструменты, которые могут использоваться приложениями LLM, такими как Claude. Он позволяет помощникам AI выполнять следующие операции:
Установите ключи API для аутентификации
Создайте различные типы получателей платежей (TEST_RAILS, US_ACH, CRYPTO_ADDRESS)
Отправляйте платежи зарегистрированным получателям
Поиск получателей платежей по различным критериям
Проверить остатки на счетах
Данная реализация соответствует стандарту Model Context Protocol (MCP), обеспечивая совместимость с любым MCP-совместимым клиентом.
Related MCP server: Monei MCP Server
Безопасная аутентификация API : безопасное управление ключами API в рамках сеанса
Несколько типов получателей платежей :
Получатели TEST_RAILS за тестирование
Получатели платежей US_ACH для банковских переводов в США
CRYPTO_ADDRESS получатели платежей за криптовалютные транзакции
Платежные операции :
Отправляйте платежи с указанием индивидуальных сумм и примечаний
Получить текущие остатки
Возможности поиска :
Поиск получателей платежей по имени, контактной информации, реквизитам счета и т. д.
Обработка ошибок : комплексная обработка ошибок для всех операций API.
Безопасные транспорты : поддерживаются транспорты stdio и SSE (Server-Sent Events)
Чтобы автоматически установить payman_mcp для Claude Desktop через Smithery :
npx -y @smithery/cli install @hrishi0102/payman_mcp --client claudeКлонируйте репозиторий:
git clone https://github.com/yourusername/payman-mcp-server.git
cd payman-mcp-serverУстановите зависимости:
npm install
# OR
yarn installСоздайте код TypeScript:
npm run build
# OR
yarn buildСерверу не требуются никакие файлы конфигурации. Ключи API устанавливаются во время выполнения с помощью инструмента set-api-key .
Запустите сервер в режиме stdio, который совместим с Claude Desktop и аналогичными клиентами MCP:
Проверьте правильность настройки сервера:
node /ABSOLUTE/PATH/TO/PARENT/FOLDER/payman-mcp/build/payman-server.jsЕсли все хорошо, теперь вы можете добавить сервер Payman MCP к любому клиенту.
Для запуска сервера с транспортом SSE (требуются дополнительные зависимости: express и cors ):
node build/payman-server-sse.jsЭто запустит веб-сервер на порту 3001 со следующими конечными точками:
/sse — конечная точка SSE для связи между сервером и клиентом.
/messages — конечная точка для сообщений клиент-сервер.
Откройте файл конфигурации Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Добавьте конфигурацию сервера:
{
"mcpServers": {
"payman": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/payman-mcp-server/build/payman-server.js"]
}
}
}Перезагрузить рабочий стол Клода
Для других клиентов MCP, таких как Cursor, обратитесь к их специальной документации по добавлению серверов MCP.
После подключения сервера к клиенту MCP вы можете использовать следующие инструменты:
Сначала вам необходимо установить ключ API Payman:
Please use the set-api-key tool with my Payman API key: YOUR_API_KEY_HERECreate a test payee named "Test User" with the tag "test"Create a US ACH payee with these details:
- Name: John Doe
- Account Type: checking
- Account Number: 12345678
- Routing Number: 123456789
- Account Holder Name: John Doe
- Account Holder Type: individualCreate a crypto payee with:
- Name: Crypto Wallet
- Address: 0x1234567890abcdef
- Chain: ethereum
- Currency: ETHSend a payment of 100 to payee ID "pay_123abc" with the memo "Monthly service"Search for all payees with the name "John"What's my current balance?set-api-keyУстанавливает ключ API Payman для аутентификации.
Параметры :
apiKey (строка): API-ключ Payman
create-test-rails-payeeСоздает получателя платежа TEST_RAILS для тестирования.
Параметры :
name (строка): Имя получателя платежа
type (строка): "TEST_RAILS" (по умолчанию)
tags (string[]): Необязательные теги для получателя платежа
create-us-ach-payeeСоздает получателя платежа US_ACH для банковских переводов.
Параметры :
type (строка): "US_ACH" (по умолчанию)
accountType (перечисление): «чековый» или «сберегательный»
accountNumber (строка): номер банковского счета
routingNumber (строка): номер маршрута
accountHolderName (строка): Имя владельца счета
accountHolderType (перечисление): «индивидуальный» или «бизнес»
name (строка): Имя этого получателя платежа
Плюс дополнительные необязательные параметры (теги, contactDetails)
create-crypto-payeeСоздает получателя CRYPTO_ADDRESS для криптовалютных платежей.
Параметры :
type (строка): "CRYPTO_ADDRESS" (по умолчанию)
address (строка): адрес криптовалюты
chain (строка): блокчейн для использования
currency (строка): Криптовалюта/токен
name (строка): Имя этого получателя платежа
Плюс дополнительные необязательные параметры (теги, contactDetails)
send-paymentОтправляет платеж получателю.
Параметры :
payeeId (строка): идентификатор получателя платежа
amountDecimal (число): Сумма для отправки
walletId (строка, необязательно): Конкретный кошелек для использования
memo (строка, необязательно): Платежное уведомление
metadata (объект, необязательно): Дополнительные метаданные
search-payeesПоиск получателей платежей по различным критериям.
Параметры : несколько дополнительных параметров поиска
name , contactEmail , accountNumber и т. д.
get-balanceВозвращает текущий баланс счета.
Параметры : Нет
Все инструменты включают надлежащую обработку ошибок и возвращают описательные сообщения об ошибках, если:
API-ключ не установлен
API-запросы не выполняются
Указаны неверные параметры.
Возникают проблемы с сетью
API-ключи хранятся в памяти на протяжении всего сеанса.
Сервер не сохраняет учетные данные на диске.
Все запросы к API Payman используют соответствующие заголовки авторизации.
Модель контекстного протокола для спецификации MCP
Payman AI для платежного API
Zod для проверки входных данных
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The cryptocurrency address to send funds to | |
| chain | Yes | The blockchain to use for the transaction | |
| contactDetails | No | Contact details for this payee | |
| currency | Yes | The currency/token to use for the transaction | |
| name | Yes | The name you wish to associate with this payee for future lookups | |
| tags | No | Optional labels you wish to assign to this payee | |
| type | No | Type of payment rails to use | CRYPTO_ADDRESS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the payee | |
| tags | No | Optional tags for the payee | |
| type | No | Type of payment rails to use | TEST_RAILS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| accountHolderName | Yes | The name of the account holder | |
| accountHolderType | Yes | The type of the account holder | |
| accountNumber | Yes | The bank account number for the account | |
| accountType | Yes | The type of account (checking or savings) | |
| contactDetails | No | Contact details for this payee | |
| name | Yes | The name you wish to associate with this payee for future lookups | |
| routingNumber | Yes | The routing number of the bank | |
| tags | No | Optional labels you wish to assign to this payee | |
| type | No | Type of payment rails to use | US_ACH |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| accountNumber | No | The US Bank account number to search for | |
| agentReference | No | The Payman agent reference (id or handle) to search for | |
| contactEmail | No | The contact email to search for | |
| contactPhoneNumber | No | The contact phone number to search for | |
| contactTaxId | No | The contact tax id to search for | |
| cryptoAddress | No | The crypto address to search for | |
| cryptoChain | No | The crypto chain to search for | |
| cryptoCurrency | No | The crypto currency to search for | |
| name | No | The name of the payee to search for (partial, case-insensitive match) | |
| routingNumber | No | The US Bank routing number to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| amountDecimal | Yes | Amount to send (in decimal) | |
| payeeId | Yes | ID of the payee to send payment to | |
| walletId | No | The ID of the specific wallet from which to send the funds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | The Payman API key to use for authentication |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0create-crypto-payeecreate-test-rails-payeecreate-us-ach-payeeget-balancesearch-payeessend-paymentset-api-keyScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: three tools create different types of payees (crypto, test rails, US ACH), while others handle balance retrieval, payee search, payment sending, and API key management. The naming makes the distinctions obvious even without descriptions.
All tools follow a consistent verb_noun pattern with hyphens (e.g., create-crypto-payee, get-balance, send-payment). The naming is uniform throughout, making it easy to predict and understand each tool's function.
With 7 tools, this server is well-scoped for payment and payee management. The count is appropriate, covering core operations like payee creation, balance checking, searching, payments, and configuration without being overwhelming or insufficient.
The toolset covers key payment workflows: creating payees, retrieving balance, searching payees, sending payments, and setting API keys. A minor gap is the lack of update or delete operations for payees, but agents can likely work around this given the core functionality is present.
GibsonAI MCP server: manage your databases with natural language
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.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Non-custodial crypto payments for AI assistants: balances, payments, and create payment links.
