The Payman AI MCP Server enables AI assistants to interact with payment APIs through natural language, offering seamless payment operations. With this server, you can:
Set API Key: Authenticate using a Payman API key
Create Payees: Add payees of different types (TEST_RAILS, US_ACH, CRYPTO_ADDRESS)
Send Payments: Transfer funds to registered payees with custom amounts and memos
Search Payees: Find payees based on criteria like name or contact information
Check Balances: Retrieve the current account balance
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., "@Payman AI MCP Server Send $50 to John Doe for lunch expenses"
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.
An MCP (Model Context Protocol) server that provides seamless integration with Payman AI's payment APIs, allowing AI assistants to create payees, search for existing payees, send payments, and check balances through natural language.
This MCP server exposes Payman AI's payment functionality as tools that can be used by LLM applications such as Claude. It enables AI assistants to perform the following operations:
Set API keys for authentication
Create different types of payees (TEST_RAILS, US_ACH, CRYPTO_ADDRESS)
Send payments to registered payees
Search for payees based on various criteria
Check account balances
This implementation follows the Model Context Protocol (MCP) standard, ensuring compatibility with any MCP-compatible client.
Related MCP server: Monei MCP Server
Secure API Authentication: Manage API keys securely within the session
Multiple Payee Types:
TEST_RAILS payees for testing
US_ACH payees for US bank transfers
CRYPTO_ADDRESS payees for cryptocurrency transactions
Payment Operations:
Send payments with custom amounts and memos
Retrieve current balances
Search Capabilities:
Search payees by name, contact information, account details, etc.
Error Handling: Comprehensive error handling for all API operations
Secure Transports: Supports both stdio and SSE (Server-Sent Events) transports
To install payman_mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @hrishi0102/payman_mcp --client claudeClone the repository:
git clone https://github.com/yourusername/payman-mcp-server.git
cd payman-mcp-serverInstall dependencies:
npm install
# OR
yarn installBuild the TypeScript code:
npm run build
# OR
yarn buildThe server does not require any configuration files. API keys are set at runtime using the set-api-key tool.
Run the server in stdio mode, which is compatible with Claude Desktop and similar MCP clients:
Check if the server is properly setup:
node /ABSOLUTE/PATH/TO/PARENT/FOLDER/payman-mcp/build/payman-server.jsIf everything is good, you can now add the Payman MCP server to any client.
To run the server with SSE transport (requires additional dependencies: express and cors):
node build/payman-server-sse.jsThis will start a web server on port 3001 with the following endpoints:
/sse - The SSE endpoint for server-to-client communication
/messages - The endpoint for client-to-server messages
Open your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the server configuration:
{
"mcpServers": {
"payman": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/payman-mcp-server/build/payman-server.js"]
}
}
}Restart Claude Desktop
For other MCP clients like Cursor, refer to their specific documentation for adding MCP servers.
Once the server is connected to an MCP client, you can use the following tools:
First, you need to set your Payman API key:
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-keySets the Payman API key for authentication.
Parameters:
apiKey (string): The Payman API key
create-test-rails-payeeCreates a TEST_RAILS payee for testing.
Parameters:
name (string): Name of the payee
type (string): "TEST_RAILS" (default)
tags (string[]): Optional tags for the payee
create-us-ach-payeeCreates a US_ACH payee for bank transfers.
Parameters:
type (string): "US_ACH" (default)
accountType (enum): "checking" or "savings"
accountNumber (string): The bank account number
routingNumber (string): The routing number
accountHolderName (string): The name of the account holder
accountHolderType (enum): "individual" or "business"
name (string): Name for this payee
Plus additional optional parameters (tags, contactDetails)
create-crypto-payeeCreates a CRYPTO_ADDRESS payee for cryptocurrency payments.
Parameters:
type (string): "CRYPTO_ADDRESS" (default)
address (string): The cryptocurrency address
chain (string): The blockchain to use
currency (string): The cryptocurrency/token
name (string): Name for this payee
Plus additional optional parameters (tags, contactDetails)
send-paymentSends a payment to a payee.
Parameters:
payeeId (string): ID of the payee to pay
amountDecimal (number): Amount to send
walletId (string, optional): Specific wallet to use
memo (string, optional): Payment memo
metadata (object, optional): Additional metadata
search-payeesSearch for payees based on various criteria.
Parameters: Multiple optional search parameters
name, contactEmail, accountNumber, etc.
get-balanceRetrieves the current account balance.
Parameters: None
All tools include proper error handling and will return descriptive error messages if:
The API key has not been set
API requests fail
Invalid parameters are provided
Network issues occur
API keys are stored in memory for the duration of the session
The server does not persist any credentials to disk
All requests to the Payman API use proper authorization headers
Model Context Protocol for the MCP specification
Payman AI for the payment API
Zod for input validation
| 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.
