Ein MCP-Server (Model Context Protocol), der eine nahtlose Integration mit den Zahlungs-APIs von Payman AI bietet und es KI-Assistenten ermöglicht, Zahlungsempfänger zu erstellen, nach vorhandenen Zahlungsempfängern zu suchen, Zahlungen zu senden und Kontostände in natürlicher Sprache zu überprüfen.
Dieser MCP-Server stellt die Zahlungsfunktionalität von Payman AI als Tools bereit, die von LLM-Anwendungen wie Claude genutzt werden können. Er ermöglicht KI-Assistenten die Durchführung folgender Operationen:
API-Schlüssel zur Authentifizierung festlegen
Erstellen Sie verschiedene Arten von Zahlungsempfängern (TEST_RAILS, US_ACH, CRYPTO_ADDRESS)
Senden Sie Zahlungen an registrierte Zahlungsempfänger
Suche nach Zahlungsempfängern anhand verschiedener Kriterien
Kontostände prüfen
Diese Implementierung folgt dem Model Context Protocol (MCP)-Standard und gewährleistet die Kompatibilität mit jedem MCP-kompatiblen Client.
Related MCP server: Monei MCP Server
Sichere API-Authentifizierung : Verwalten Sie API-Schlüssel sicher innerhalb der Sitzung
Mehrere Zahlungsempfängertypen :
TEST_RAILS Zahlungsempfänger zum Testen
US_ACH-Zahlungsempfänger für US-Banküberweisungen
CRYPTO_ADDRESS-Zahlungsempfänger für Kryptowährungstransaktionen
Zahlungsvorgänge :
Senden Sie Zahlungen mit benutzerdefinierten Beträgen und Memos
Aktuelle Guthaben abrufen
Suchfunktionen :
Suchen Sie nach Zahlungsempfängern nach Namen, Kontaktinformationen, Kontodetails usw.
Fehlerbehandlung : Umfassende Fehlerbehandlung für alle API-Operationen
Sichere Transporte : Unterstützt sowohl Standard- als auch SSE-Transporte (Server-Sent Events)
So installieren Sie payman_mcp für Claude Desktop automatisch über Smithery :
npx -y @smithery/cli install @hrishi0102/payman_mcp --client claudeKlonen Sie das Repository:
git clone https://github.com/yourusername/payman-mcp-server.git
cd payman-mcp-serverInstallieren Sie Abhängigkeiten:
npm install
# OR
yarn installErstellen Sie den TypeScript-Code:
npm run build
# OR
yarn buildDer Server benötigt keine Konfigurationsdateien. API-Schlüssel werden zur Laufzeit mit dem Tool set-api-key festgelegt.
Führen Sie den Server im Standardmodus aus, der mit Claude Desktop und ähnlichen MCP-Clients kompatibel ist:
Überprüfen Sie, ob der Server richtig eingerichtet ist:
node /ABSOLUTE/PATH/TO/PARENT/FOLDER/payman-mcp/build/payman-server.jsWenn alles in Ordnung ist, können Sie jetzt den Payman MCP-Server zu jedem Client hinzufügen.
So führen Sie den Server mit SSE-Transport aus (erfordert zusätzliche Abhängigkeiten: express und cors ):
node build/payman-server-sse.jsDadurch wird ein Webserver auf Port 3001 mit den folgenden Endpunkten gestartet:
/sse – Der SSE-Endpunkt für die Server-zu-Client-Kommunikation
/messages - Der Endpunkt für Client-zu-Server-Nachrichten
Öffnen Sie Ihre Claude Desktop-Konfigurationsdatei:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Fügen Sie die Serverkonfiguration hinzu:
{
"mcpServers": {
"payman": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/payman-mcp-server/build/payman-server.js"]
}
}
}Starten Sie Claude Desktop neu
Informationen zum Hinzufügen von MCP-Servern finden Sie bei anderen MCP-Clients wie Cursor in der jeweiligen Dokumentation.
Sobald der Server mit einem MCP-Client verbunden ist, können Sie die folgenden Tools verwenden:
Zuerst müssen Sie Ihren Payman-API-Schlüssel festlegen:
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-keyLegt den Payman-API-Schlüssel für die Authentifizierung fest.
Parameter :
apiKey (Zeichenfolge): Der Payman-API-Schlüssel
create-test-rails-payeeErstellt einen TEST_RAILS-Zahlungsempfänger zum Testen.
Parameter :
name (Zeichenfolge): Name des Zahlungsempfängers
type (Zeichenfolge): "TEST_RAILS" (Standard)
tags (string[]): Optionale Tags für den Zahlungsempfänger
create-us-ach-payeeErstellt einen US_ACH-Zahlungsempfänger für Banküberweisungen.
Parameter :
type (Zeichenfolge): "US_ACH" (Standard)
accountType (enum): „Girokonto“ oder „Sparkonto“
accountNumber (Zeichenfolge): Die Bankkontonummer
routingNumber (Zeichenfolge): Die Routingnummer
accountHolderName (Zeichenfolge): Der Name des Kontoinhabers
accountHolderType (enum): „Einzelperson“ oder „Unternehmen“
name (Zeichenfolge): Name für diesen Zahlungsempfänger
Plus zusätzliche optionale Parameter (Tags, Kontaktdaten)
create-crypto-payeeErstellt einen CRYPTO_ADDRESS-Zahlungsempfänger für Kryptowährungszahlungen.
Parameter :
type (Zeichenfolge): "CRYPTO_ADDRESS" (Standard)
address (Zeichenfolge): Die Kryptowährungsadresse
chain (Zeichenfolge): Die zu verwendende Blockchain
currency (Zeichenfolge): Die Kryptowährung/das Token
name (Zeichenfolge): Name für diesen Zahlungsempfänger
Plus zusätzliche optionale Parameter (Tags, Kontaktdaten)
send-paymentSendet eine Zahlung an einen Zahlungsempfänger.
Parameter :
payeeId (Zeichenfolge): ID des zu zahlenden Zahlungsempfängers
amountDecimal (Zahl): Zu sendender Betrag
walletId (Zeichenfolge, optional): Zu verwendende spezifische Brieftasche
memo (Zeichenfolge, optional): Zahlungsmemo
metadata (Objekt, optional): Zusätzliche Metadaten
search-payeesSuche nach Zahlungsempfängern anhand verschiedener Kriterien.
Parameter : Mehrere optionale Suchparameter
name , contactEmail , accountNumber usw.
get-balanceRuft den aktuellen Kontostand ab.
Parameter : Keine
Alle Tools verfügen über eine ordnungsgemäße Fehlerbehandlung und geben in folgenden Fällen aussagekräftige Fehlermeldungen zurück:
Der API-Schlüssel wurde nicht festgelegt
API-Anfragen schlagen fehl
Es wurden ungültige Parameter angegeben
Es treten Netzwerkprobleme auf
API-Schlüssel werden für die Dauer der Sitzung im Speicher gespeichert
Der Server speichert keine Anmeldeinformationen auf der Festplatte
Alle Anfragen an die Payman-API verwenden die richtigen Autorisierungsheader
Model Context Protocol für die MCP-Spezifikation
Payman AI für die Zahlungs-API
Zod zur Eingabevalidierung
| 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.
