What can you do with this server?

This server provides an interface to integrate with the SATIM payment gateway in Algeria for processing CIB/Edhahabia card payments. With this server, you can: * Configure merchant credentials for SATIM gateway access * Register payment orders with details like amount, return URLs, and unique identifiers * Get payment form URLs to redirect customers to the SATIM payment page * Confirm order status after customer payment attempts * Process full or partial refunds for completed transactions * Validate and interpret payment responses to determine final status * Handle error and confirmation codes effectively

Which integrations are available for this server?

Enables direct access to Razorpay account data through a standardized interface, as mentioned in the package description.

How do I use Satim Payment Gateway Integration?

1. Click on "Deploy 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., "@Satim Payment Gateway Integration register an order for 2500 DA with order number INV_2024_789" 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.

Satim Payment Gateway Integration

by zakblacki

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Obviously you should have already an account created and working to get credentials from here : https://cibweb.dz/fr/login

Satim Payment Gateway Integration

A Model Context Protocol (MCP) server for integrating with the SATIM payment gateway system in Algeria. The server provides a structured interface for processing CIB/Edhahabia card payments through the SATIM-ePAY platform. This package enables AI assistants like Cursor, Claude, and Copilot to directly access your account data through a standardized interface.

Quick Start

# Clone the repository
git clone https://github.com/zakblacki/Satim-Payment-Gateway-Integration.git
cd satim-payment-gateway-integration

# Install dependencies
npm install

# Run the server
npx tsx satim-mcp-server.ts
or
npm run dev

# Demo 
Launch index.html

Related MCP server: Antom MCP Server

Installation

Prerequisites

Node.js 18+
npm or yarn

Step-by-Step Setup

Clone and enter the project directory:

git clone https://github.com/zakblacki/Satim-Payment-Gateway-Integration.git
cd satim-payment-gateway-integration

Initialize the project (if package.json doesn't exist):

npm init -y

Configure package.json for ES modules:

npm pkg set type=module

Install dependencies:

# Core dependencies
npm install @modelcontextprotocol/sdk axios

# Development dependencies
npm install --save-dev typescript @types/node tsx

Running the Server

Option 1: Direct execution with tsx (Recommended for development)

npx tsx satim-mcp-server.ts

Option 2: Compile and run

# Compile TypeScript
npm run build

# Run compiled JavaScript
npm start

Option 3: Development mode with auto-reload

npm run dev

Configuration

MCP Client Configuration

To use this server with an MCP client (like Claude Desktop), add to your configuration:

{
  "mcpServers": {
      "satim-payment": {
       "command": "npx",
       "args": ["@devqxi/satim-payment-gateway-mcp"],
       "env": {
        "SATIM_USERNAME": "your_test_username",
        "SATIM_PASSWORD": "your_test_password",
        "NODE_ENV": "development"
      }
    }
  }
}

Initial Setup

Before using any payment tools, configure your SATIM credentials:

// Configure credentials
await mcp.callTool("configure_credentials", {
  userName: "your_merchant_username",
  password: "your_merchant_password"
});

Environment Variables

For production, consider using environment variables:

SATIM_USERNAME=your_merchant_username
SATIM_PASSWORD=your_merchant_password
SATIM_TERMINAL_ID=your_terminal_id
SATIM_BASE_URL=https://test.satim.dz/payment/rest  # or https://satim.dz/payment/rest for production

Payment Flow

The complete payment process follows these steps:

1. Order Registration

const registrationResult = await mcp.callTool("register_order", {
  orderNumber: "ORDER_001_2024",
  amountInDA: 1500.50,  // Amount in Algerian Dinars
  returnUrl: "https://yoursite.com/payment/success",
  failUrl: "https://yoursite.com/payment/failure",
  force_terminal_id: "E005005097",
  udf1: "merchant_ref_123",
  language: "FR"
});

// Response includes orderId and formUrl
// Redirect customer to formUrl for payment

2. Customer Payment

Customer fills CIB/Edhahabia card details on SATIM form
Customer is redirected back to your returnUrl/failUrl

3. Order Confirmation

const confirmResult = await mcp.callTool("confirm_order", {
  orderId: "received_order_id",
  language: "FR"
});

// Validate the response
const validation = await mcp.callTool("validate_payment_response", {
  response: confirmResult
});

4. Display Results

Based on validation results, display appropriate messages to customers.

Tools

configure_credentials

Configure SATIM gateway credentials.

Parameters:

userName (string, required): Merchant login
password (string, required): Merchant password

register_order

Parameters:

orderNumber (string, required): Unique order identifier
amountInDA (number, required): Amount in Algerian Dinars (min: 50 DA)
returnUrl (string, required): Success redirect URL
failUrl (string, optional): Failure redirect URL
force_terminal_id (string, required): Bank-assigned terminal ID
udf1 (string, required): SATIM-specific parameter
currency (string, optional): Currency code (default: "012" for DZD)
language (string, optional): Interface language ("AR", "FR", "EN")
description (string, optional): Order description
udf2-udf5 (string, optional): Additional parameters

Response:

{
  "orderId": "123456789AZERTYUIOPL",
  "formUrl": "https://test.satim.dz/payment/merchants/merchant1/payment_fr.html?mdOrder=123456789AZERTYUIOPL"
}

confirm_order

Confirm order status after payment attempt.

Parameters:

orderId (string, required): Order ID from registration
language (string, optional): Response language

Response:

{
  "orderNumber": "ORDER_001_2024",
  "actionCode": 0,
  "actionCodeDescription": "Votre paiement a été accepté",
  "amount": 150050,
  "errorCode": "0",
  "orderStatus": 2,
  "approvalCode": "303004",
  "params": {
    "respCode": "00",
    "respCode_desc": "Votre paiement a été accepté"
  }
}

refund_order

Process a refund for a completed order.

Parameters:

orderId (string, required): Order ID to refund
amountInDA (number, required): Refund amount in DA
currency (string, optional): Currency code
language (string, optional): Response language

Response:

{
  "errorCode": 0
}

validate_payment_response

Validate and interpret payment response.

Parameters:

response (object, required): Order confirmation response

Response:

{
  "status": "ACCEPTED",
  "displayMessage": "Votre paiement a été accepté",
  "shouldShowContactInfo": false,
  "contactNumber": "3020 3020"
}

Testing

Method 1: Quick Test

Create a simple test file test-simple.js:

import { spawn } from 'child_process';

// Start the MCP server
const server = spawn('npx', ['tsx', 'satim-mcp-server.ts'], {
  stdio: ['pipe', 'pipe', 'inherit']
});

console.log('SATIM MCP Server started for testing');

// Let it run for a few seconds then exit
setTimeout(() => {
  server.kill();
  console.log('Test completed');
}, 5000);

Run with:

node test-simple.js

Method 2: Full Integration Test

Create test-client.ts following the example in the documentation, then run:

npm run test

Method 3: HTTP Wrapper for API Testing

Use the HTTP wrapper example provided in the documentation to create REST API endpoints for easier testing with tools like Postman or curl.

Troubleshooting

Common Issues and Solutions

"Cannot use import statement outside a module"

# Make sure package.json has "type": "module"
npm pkg set type=module

"Module not found" errors

# Reinstall dependencies
rm -rf node_modules package-lock.json
npm install

TypeScript compilation errors

# Check tsconfig.json configuration
# Make sure all dependencies are installed
npm install --save-dev @types/node

Server connection issues

# Check if server is running
ps aux | grep tsx

# Check for port conflicts
lsof -i :3000  # if using HTTP wrapper

Debug Mode

Enable debug logging:

DEBUG=true npx tsx satim-mcp-server.ts

Integration Requirements

SSL Security

Mandatory: Your website must have SSL certificate
All API calls must use HTTPS

User Interface Requirements

Payment Page

Display final amount prominently (bold, larger font)
Include CAPTCHA to prevent automated submissions
Show CIB logo on payment button
Display terms and conditions with customer acknowledgment
Redirect to SATIM page in independent browser window

Success Page Display

For accepted payments, show:

Transaction message (respCode_desc)
Transaction ID (orderId)
Order number (orderNumber)
Authorization code (approvalCode)
Transaction date/time
Payment amount with currency
Payment method (CIB/Edhahabia)
SATIM contact: 3020 3020

Success Page Actions

Print receipt option
Download PDF receipt
Email PDF receipt to third party

Rejection Page

Display rejection message in three languages
Show SATIM contact information

Amount Handling

Amounts must be multiplied by 100 when sent to SATIM:

50.00 DA → send 5000
806.50 DA → send 80650

The MCP server handles this conversion automatically.

Error Handling

Order Registration Errors

Invalid credentials
Duplicate order number
Invalid amount (< 50 DA)
Missing required parameters

Confirmation Errors

Error Code	Description
0	Successfully confirmed
1	Empty order ID
2	Already confirmed
3	Access denied
5	Access denied
6	Unknown order
7	System error

Refund Errors

Error Code	Description
0	No system error
5	Password change required / Empty order ID
6	Wrong order number
7	Payment state error / Amount error / System error

Examples

Complete Payment Flow

// 1. Configure credentials
await mcp.callTool("configure_credentials", {
  userName: "test_merchant",
  password: "test_password"
});

// 2. Register order
const order = await mcp.callTool("register_order", {
  orderNumber: `ORDER_${Date.now()}`,
  amountInDA: 250.75,
  returnUrl: "https://mystore.dz/payment/success",
  failUrl: "https://mystore.dz/payment/failure",
  force_terminal_id: "E005005097",
  udf1: "customer_ref_456",
  language: "FR",
  description: "Achat produit électronique"
});

// 3. Redirect customer to order.formUrl
// Customer completes payment and returns

// 4. Confirm payment
const confirmation = await mcp.callTool("confirm_order", {
  orderId: order.orderId,
  language: "FR"
});

// 5. Validate response
const validation = await mcp.callTool("validate_payment_response", {
  response: confirmation
});

// 6. Handle result
if (validation.status === "ACCEPTED") {
  // Process successful payment
  console.log("Payment successful:", validation.displayMessage);
} else if (validation.status === "REJECTED") {
  // Handle rejection
  console.log("Payment rejected");
} else {
  // Handle error
  console.log("Payment error:", validation.displayMessage);
}

Processing Refunds

// Full refund
const refund = await mcp.callTool("refund_order", {
  orderId: "123456789AZERTYUIOPL",
  amountInDA: 250.75,  // Full original amount
  language: "FR"
});

// Partial refund
const partialRefund = await mcp.callTool("refund_order", {
  orderId: "123456789AZERTYUIOPL",
  amountInDA: 100.00,  // Partial amount
  language: "FR"
});

Security Considerations

Credentials Management

Store credentials securely (environment variables, key vault)
Use HTTPS for all communications
Implement proper authentication for your API endpoints

Order Number Security

Use unique, non-sequential order numbers
Include timestamp or random elements
Validate order ownership before confirmation

Data Validation

Always validate amounts on server side
Verify order status before processing confirmations
Implement idempotency for refund operations

Logging and Monitoring

Log all payment transactions
Monitor for suspicious activities
Implement rate limiting for API calls

Production Deployment

Environment Configuration

# Production endpoints
SATIM_BASE_URL=https://satim.dz/payment/rest

# Development/Testing endpoints  
SATIM_BASE_URL=https://test.satim.dz/payment/rest

Health Checks

Implement health check endpoints to monitor gateway connectivity:

// Add to your server
app.get('/health/satim', async (req, res) => {
  try {
    // Test connection to SATIM
    const response = await axios.get(`${SATIM_BASE_URL}/health`);
    res.json({ status: 'healthy', satim: 'connected' });
  } catch (error) {
    res.status(503).json({ status: 'unhealthy', error: error.message });
  }
});

Support and Contact

SATIM Support: 3020 3020 (toll-free)
Technical Issues: Contact your integration specialist
Documentation: Refer to official SATIM integration guides

This MCP server implementation follows SATIM's official API specifications and includes all required integration points for Algerian e-commerce platforms.

Available Tools

5 tools

configure_credentialsC

Configure SATIM payment gateway credentials

ParametersJSON Schema

Name	Required	Description	Default
`password`	Yes	Merchant's password received during registration
`userName`	Yes	Merchant's login received during registration

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('configure'), but doesn't specify whether this is a one-time setup, if it overwrites existing credentials, requires specific permissions, or has side effects like authentication changes. This is a significant gap for a tool that likely modifies system state.

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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, and the tool's likely role in mutating payment credentials, the description is incomplete. It doesn't address behavioral aspects like security implications, error handling, or what success looks like, which are critical for an agent to use this tool safely and effectively.

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?

The schema description coverage is 100%, with both parameters ('userName' and 'password') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or validation rules, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('configure') and the resource ('SATIM payment gateway credentials'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings like 'register_order' or 'validate_payment_response', which might also involve credential handling in some contexts.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing registration first), exclusions, or how it relates to sibling tools like 'register_order', leaving the agent to guess the appropriate context.

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

confirm_orderC

Confirm order status after payment attempt

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Language for response messages
`orderId`	Yes	Order ID returned from registration

TDQS

C2.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 of behavioral disclosure. It mentions 'confirm order status', which suggests a read operation, but doesn't clarify if this is a safe query, requires specific permissions, has side effects, or details response behavior. This is inadequate for a tool with zero annotation coverage.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly with zero waste.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'confirm' entails behaviorally, what the return values might be, or how it fits with sibling tools. For a tool with 2 parameters and potential complexity in order processing, more context is needed to be fully helpful.

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?

The schema description coverage is 100%, so the input schema already documents both parameters ('orderId' and 'language') with descriptions and enum values. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or usage context, but this is acceptable given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as 'Confirm order status after payment attempt', which includes a specific verb ('Confirm') and resource ('order status'), but it's somewhat vague about what 'confirm' entails—does it check, update, or finalize status? It doesn't clearly distinguish from siblings like 'validate_payment_response', which might overlap in functionality.

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?

The description provides minimal guidance by mentioning 'after payment attempt', implying usage timing, but it doesn't specify when to use this tool versus alternatives like 'validate_payment_response' or 'register_order'. No explicit when-not-to-use or prerequisite information is given, leaving gaps in usage context.

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

refund_orderC

Process refund for a completed order

ParametersJSON Schema

Name	Required	Description	Default
`amountInDA`	Yes	Refund amount in Algerian Dinars
`currency`	No	Currency code	012
`language`	No	Language for response messages
`orderId`	Yes	Order ID to refund

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Process refund' implies a financial mutation, but it doesn't disclose critical traits like required permissions, whether refunds are reversible, rate limits, or what happens if the order isn't completed. This is inadequate for a tool with potential financial impact.

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 perfectly concise at five words, front-loading the core purpose ('Process refund') without any wasted language. Every word earns its place, making it efficient for quick comprehension by an AI agent.

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

Completeness2/5

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

Given the tool's complexity (financial mutation with 4 parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects, return values, error conditions, or usage boundaries, leaving the agent with significant uncertainty about how to invoke it correctly.

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?

The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters (e.g., how 'amountInDA' relates to 'currency') or provide additional context about parameter usage. The baseline score of 3 reflects adequate but minimal value added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Process refund') and resource ('for a completed order'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'confirm_order' or 'register_order' that might also handle order-related operations, which prevents a perfect score.

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?

The description provides minimal guidance by specifying 'for a completed order', which implies this tool shouldn't be used for pending or cancelled orders. However, it offers no explicit when-to-use rules, alternatives (e.g., vs. 'confirm_order'), or prerequisites, leaving significant gaps in usage context.

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

register_orderC

ParametersJSON Schema

Name	Required	Description	Default
`amountInDA`	Yes	Order amount in Algerian Dinars (minimum 50 DA)
`currency`	No	Currency code according to ISO 4217 (012 for DZD)	012
`description`	No	Order description
`failUrl`	No	URL to redirect after failed payment
`force_terminal_id`	Yes	Terminal ID assigned by bank (mandatory)
`language`	No	Language for the payment interface
`orderNumber`	Yes	Unique order identifier in merchant's system
`returnUrl`	Yes	URL to redirect after successful payment
`udf1`	Yes	SATIM specific parameter (mandatory)
`udf2`	No	Additional parameter
`udf3`	No	Additional parameter
`udf4`	No	Additional parameter
`udf5`	No	Additional parameter

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a registration operation but doesn't clarify if this creates a persistent record, initiates a payment, returns a transaction ID, or has side effects like authentication requirements or rate limits. For a payment gateway tool with 13 parameters, this is insufficient.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

Completeness2/5

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

For a complex payment gateway tool with 13 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after registration (e.g., returns a payment URL, transaction ID), error conditions, or how it fits with sibling tools like 'configure_credentials'. The agent lacks crucial context for proper usage.

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?

The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond the tool's overall purpose. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('register') and resource ('new order with SATIM payment gateway'), providing a specific purpose. However, it doesn't differentiate from sibling tools like 'confirm_order' or 'refund_order', which would require explicit comparison to achieve a score of 5.

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?

The description provides no guidance on when to use this tool versus alternatives like 'confirm_order' or 'refund_order'. It lacks context about prerequisites, such as needing configured credentials first, or when this operation is appropriate in a payment workflow.

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

validate_payment_responseC

Validate and interpret payment response status

ParametersJSON Schema

Name	Required	Description	Default
`response`	Yes	Order confirmation response object

TDQS

C2.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 of behavioral disclosure. The description mentions 'validate and interpret', which implies a read-only analysis, but doesn't specify whether this tool performs any side effects, requires specific permissions, handles errors, or what the output format might be. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 extremely concise with just one sentence: 'Validate and interpret payment response status'. It is front-loaded and wastes no words, making it easy to parse quickly. Every word contributes directly to the purpose statement.

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

Completeness2/5

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

Given the complexity of validating and interpreting payment responses, the description is incomplete. There are no annotations, no output schema, and the description doesn't explain what the tool returns (e.g., validation results, status codes, error messages). For a tool that likely processes critical payment data, more context on behavior and outputs is needed to be fully useful.

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?

The input schema has 100% description coverage, with the single parameter 'response' documented as 'Order confirmation response object'. The description adds no additional meaning beyond this, as it doesn't explain what constitutes a valid response object or how validation and interpretation are applied. With high schema coverage, the baseline score of 3 is appropriate, but no extra value is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as 'validate and interpret payment response status', which is clear but somewhat vague. It specifies the action ('validate and interpret') and the resource ('payment response status'), but doesn't distinguish it from sibling tools like 'confirm_order' or 'refund_order'. The description could be more specific about what validation and interpretation entails.

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?

The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'confirm_order' and 'refund_order' that might handle related payment operations, but the description doesn't indicate when this validation tool should be invoked versus those alternatives. No context, exclusions, or prerequisites are mentioned.

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.

5 tool updatesv1.0.0Aug 15, 2025
- First observedconfigure_credentials
- First observedconfirm_order
- First observedrefund_order
- First observedregister_order
- First observedvalidate_payment_response

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-04-18 09:45 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: configure_credentials handles setup, register_order initiates payments, validate_payment_response processes responses, confirm_order checks status, and refund_order handles refunds. The descriptions make it easy for an agent to select the right tool for each payment workflow step.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with clear action verbs (configure, confirm, refund, register, validate) and specific nouns (credentials, order, payment_response). The naming is uniform and predictable throughout the set.

Tool Count5/5

Five tools is well-scoped for a payment gateway integration, covering the essential operations: setup, order registration, response validation, status confirmation, and refunds. Each tool earns its place without redundancy or obvious gaps.

Completeness5/5

The tool set provides complete coverage for the payment gateway domain, including configuration, order lifecycle (register, confirm, refund), and response validation. There are no dead ends or missing operations for typical payment processing workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

intelligence-gateway
com.tkawen
Unified MCP gateway to Algeria TKAWEN ecosystem: commerce, certification and AI tools.
E-commerce & Retail AI & Machine Learning
2
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
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
Bitrix24 BOAuth
io.github.bitrix24
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
ERP Systems Project Management Communication
2

Related MCP Servers

Daraja MCP
Finance Cloud Platforms Autonomous Agents
jameskanyiri
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that integrates AI applications with Safaricom's Daraja API, enabling AI-driven financial transactions and automation through M-Pesa services.
Updated 4 months ago (2026-04-29 16:36 UTC)
14
-
Antom MCP Serverofficial
Payments & Billing Finance
ant-intl
A
license
A
quality
D
maintenance
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.
Updated a year ago (2025-07-16 06:25 UTC)
5
7
MIT
cinetpay-mcpofficial
Finance Payments & Billing
cinetpay
A
license
A
quality
D
maintenance
MCP server that connects AI assistants to the CinetPay API for mobile money payments across Africa, enabling balance checks, payment initialization, transfers, and more.
Updated 6 months ago (2026-03-21 21:08 UTC)
7
5 npm
MIT
adaptis-mcp-server
Payments & Billing Finance
fredericktvf
F
license
Not graded
quality
B
maintenance
A local MCP server that lets AI agents interact with the Adaptis (MEG) payment gateway, enabling payment link creation, transaction queries, refunds, and integration helpers like generating signed forms and verifying callbacks.
Updated 2 months ago (2026-07-21 13:55 UTC)
-

Obviously you should have already an account created and working to get credentials from here : https://cibweb.dz/fr/login

Satim Payment Gateway Integration

Quick Start

Table of Contents

Installation

Prerequisites

Step-by-Step Setup

Running the Server

Option 1: Direct execution with tsx (Recommended for development)

Option 2: Compile and run

Option 3: Development mode with auto-reload

Configuration

MCP Client Configuration

Initial Setup

Environment Variables

Payment Flow

1. Order Registration

2. Customer Payment

3. Order Confirmation

4. Display Results

Tools

configure_credentials

register_order

confirm_order

refund_order

validate_payment_response

Testing

Method 1: Quick Test

Method 2: Full Integration Test

Method 3: HTTP Wrapper for API Testing

Troubleshooting

Common Issues and Solutions

Debug Mode

Integration Requirements

SSL Security

User Interface Requirements

Payment Page

Success Page Display

Success Page Actions

Rejection Page

Amount Handling

Error Handling

Order Registration Errors

Confirmation Errors

Refund Errors

Examples

Complete Payment Flow

Processing Refunds

Security Considerations

Credentials Management

Order Number Security

Data Validation

Logging and Monitoring

Production Deployment

Environment Configuration

Health Checks

Support and Contact

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Antom MCP Serverofficial

cinetpay-mcpofficial