This server is a unified payment orchestration tool (MCP/HTTP) for West African providers. You can:
List Providers (list_providers): See all available providers and their configuration.
Initiate Payment (initiate_payment): Start a payment and get a checkout URL.
Verify Payment (verify_payment): Check payment status by transaction ID.
Refund Payment (refund_payment): Issue full or partial refunds.
Generate Payment Link (generate_payment_link): Create shareable payment links.
Initiate Payout (initiate_payout): Disburse funds to mobile money or bank accounts.
Verify Payout (verify_payout): Check payout status.
List Transactions (list_transactions): Retrieve and filter past transactions.
Receive Webhooks: Act as a webhook receiver with signature verification.
Multi-Provider & Multi-Mode: Works with CinetPay, Wave, Hub2, etc., in mock, sandbox, or live modes.
MCP & REST: Available over stdio (MCP) and HTTP API.
Security: API key auth, HMAC verification, rate limiting; bring-your-own-keys, no custody.
Database: Requires PostgreSQL for storing transactions and API keys.
Click on "Install 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., "@WariMCP Initiate a payment of 5000 XOF via FedaPay to 2250701234567"
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.
WariMCP is an MCP (Model Context Protocol) server that gives AI agents and REST clients a unified interface to West African payment providers. It exposes 10 providers through a single API — payments, payouts, refunds, webhooks — with FedaPay as the recommended primary and Hub2 as the recommended secondary. Runs as an MCP stdio server (for Claude/Cursor/Windsurf), an Express HTTP API, or both simultaneously.
git clone https://github.com/Bigabou007-dev/warimcp.git
cd warimcp
npm install
cp .env.example .env # edit with your credentials
npm run db:migrate # set up PostgreSQL schema
npm run db:seed-api-key # generate your first API key
npm run dev # starts MCP + HTTP on port 3000Requires Node >= 22 and PostgreSQL 16+.
Related MCP server: PayLink MCP Server
9 providers are available in the codebase. The recommended production setup is FedaPay + Hub2.
Provider | Key | Region | Methods | Currencies | Status |
FedaPay |
| CI, SN, BJ, TG, BF, ML, NE, GW | MTN, Orange, Moov, Wave, Card | XOF, XAF, GNF | Recommended Primary — live keys, true aggregator |
Hub2 |
| CI, SN, ML, BF, TG, BJ, NE, CM | Mobile Money | XOF, XAF | Recommended Secondary — pending sandbox access |
Wave |
| CI, SN, ML, BF, UG, TZ | Wave wallet | XOF | Requires RCCM |
Flutterwave |
| CI, SN, NG, GH, KE + 4 more | Mobile Money, Card, Bank | XOF, XAF, NGN, GHS, KES, USD, EUR | Available |
KKiaPay |
| CI, SN, BJ, BF, ML, TG, NE, GW | MTN, Orange, Wave, Card | XOF, XAF | Available |
Moneroo |
| CI, SN, BJ, BF + 10 more | MTN, Orange, Wave, Moov, Card, Bank | XOF, XAF, GNF, CDF, NGN, GHS, KES, USD, EUR | Available |
MTN MoMo |
| CI, GH, UG, RW, BJ, CM, CG | MTN Mobile Money | EUR | Available |
PAPSS |
| CI, KE, NG, GH | Bank Transfer | XOF, KES, NGN, GHS | Future |
Mock |
| All | All | All | Testing only |
Set WARIMCP_MODE=mock to route all providers through the mock provider (no API keys needed).
All payment/payout endpoints require an X-Api-Key header. Generate keys with npm run db:seed-api-key.
Method | Path | Auth | Description |
|
| No | Health check |
|
| No | List all providers and their config status |
|
| Yes | Initiate a payment (returns checkout URL) |
|
| Yes | Verify payment status |
|
| Yes | Full or partial refund |
|
| Yes | List transactions (filterable by provider, status) |
|
| Yes | Generate a shareable payment link |
|
| Yes | Disburse to mobile money or bank |
|
| Yes | Verify payout status |
|
| No | Inbound webhook receiver (signature-verified) |
When registered as an MCP server, WariMCP exposes these tools to AI agents:
Tool | Description |
| List all providers, their config status, and supported rails |
| Start a payment via any provider — returns a checkout URL |
| Check the status of a payment by transaction ID |
| Issue a full or partial refund |
| List recent transactions with provider/status filters |
| Create a shareable payment link |
| Disburse funds to a mobile money wallet or bank account |
| Check the status of a payout |
Register WariMCP with any MCP client (Claude Desktop, Cursor, Windsurf, VS Code) using npx:
{
"mcpServers": {
"warimcp": {
"command": "npx",
"args": ["-y", "warimcp"],
"env": {
"WARIMCP_TRANSPORT": "stdio",
"WARIMCP_MODE": "live",
"DATABASE_URL": "postgresql://warimcp:yourpass@localhost:5432/warimcp",
"FEDAPAY_SECRET_KEY": "your-own-fedapay-key"
}
}
}
}Bring your own keys.
FEDAPAY_SECRET_KEYis your FedaPay account — settlement goes to you, never to an intermediary. SetWARIMCP_MODE=mockto exercise the tools with no keys and no real money. A reachable PostgreSQL instance is required (DATABASE_URL); runnpm run db:migrateagainst it once. For local development, pointcommandatnodeandargsatdist/index.jsinstead.
Helmet with Content-Security-Policy (default-src 'self', no inline scripts)
Timing-safe HMAC verification for Wave and Hub2 webhooks (crypto.timingSafeEqual)
HMAC-SHA256 signed webhook relay — outbound relays include X-WariMCP-Signature header
API key auth with SHA-256 hashed storage, per-key permissions, and per-key rate limits
Token bucket rate limiting — 60 req/min default per API key
Error sanitization — provider errors are caught and rewritten; internal details never leak to clients
Non-root Docker user — container runs as dedicated warimcp user (UID 1001)
Zod validation on all inputs with strict schemas (amount bounds, phone format, UUID checks)
WariMCP holds no funds and ships no credentials. It only instructs licensed payment service providers; money settles directly into the account that the keys belong to — never an intermediary account. Each operator runs their own instance with their own PSP credentials and is the merchant of record, responsible for their own licensing and regulatory compliance.
An earlier "manual payment collection" feature (which routed funds into a personal mobile-money account with SMS reconciliation) was removed in 2026-06 as incompatible with this no-custody posture. Do not reintroduce custody of third-party funds.
All configuration is via environment variables (see .env.example):
# Mode: mock | sandbox | live
WARIMCP_MODE=mock
# Transport: stdio | http | both
WARIMCP_TRANSPORT=both
WARIMCP_PORT=3000
# Database
DATABASE_URL=postgresql://warimcp:changeme@localhost:5432/warimcp
# Primary — FedaPay
FEDAPAY_SECRET_KEY=
FEDAPAY_PUBLIC_KEY=
# Secondary — Hub2
HUB2_API_KEY=
# Other providers (configure as needed)
WAVE_API_KEY=
WAVE_WEBHOOK_SECRET=
FLUTTERWAVE_SECRET_KEY=
FLUTTERWAVE_PUBLIC_KEY=
KKIAPAY_PUBLIC_KEY=
KKIAPAY_PRIVATE_KEY=
KKIAPAY_SECRET=
MONEROO_SECRET_KEY=
MTN_MOMO_COLLECTION_SUBSCRIPTION_KEY=
MTN_MOMO_API_USER=
MTN_MOMO_API_KEY=
MTN_MOMO_ENVIRONMENT=sandbox
MTN_MOMO_CALLBACK_URL=
PAPSS_API_KEY=
# Webhooks
WARIMCP_WEBHOOK_BASE_URL=
WARIMCP_RELAY_SECRET=# Set DB_PASSWORD in .env, then:
docker compose up -dRuns two containers on the npm_proxy network:
warimcp — Node 22 Alpine, non-root, 512 MB limit, health-checked at /health
warimcp_db — PostgreSQL 16 Alpine, 256 MB limit, persistent volume
The HTTP transport is used in Docker (WARIMCP_TRANSPORT=http). For MCP stdio access, run the server directly with node dist/index.js.
Phase 1 (current): FedaPay as primary aggregator + Hub2 as secondary. All 10 provider adapters implemented. No-custody, bring-your-own-keys posture.
Phase 2: Wave activation once RCCM is filed. Full webhook verification for all active providers. Automatic provider fallback (FedaPay -> Hub2).
Phase 3: PAPSS pan-African corridor (CI to KE/NG/GH). Multi-currency settlement. Bulk payouts.
Sandbox-first spike (2026-08-05, board-reviewed). The agentic bridge (
authorize_and_pay) is NOT production-ready for multi-merchant use. Known gaps, tracked as product requirements indocs/superpowers/specs/2026-08-05-track4-whatsapp-merchant-product.md§10: trusted agent keys are env-based (a per-merchant key registry is required), the replay-nonce store is in-memory (a persistent store is required), and payment mandates carry no customer identity. No tenant isolation exists yet: do not run more than one merchant on a shared instance. No real-money operation before the regulatory gate chain completes (RCCM, ARTCI, counsel review).
License policy (2026-08-05): WariMCP core is and stays MIT. Commercial offerings (partner integrations, hosted services) are separate layers and do not change the license of this repository.
Generate a shareable payment link for a customer
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in whole currency units | |
| currency | No | ISO currency code | XOF |
| provider | No | Payment provider | cinetpay |
| description | No | Payment description | Payment |
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, but it only states the basic action. It does not disclose what the tool returns (e.g., a URL), whether it creates a persistent record, expires, requires authentication, or has any side effects, making the tool's behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the verb and object. It is appropriately sized and contains no filler or redundant information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain the return value, expiration or sharing behavior, or how the 'customer' reference maps to the input parameters. The tool's complexity is moderate, but the description leaves major gaps that could lead to incorrect invocation.
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?
The schema descriptions cover all four parameters, but the description introduces a 'customer' concept that is not represented in the schema, creating ambiguity about how a customer is specified. The description adds no additional semantic value beyond the schema's own parameter descriptions, and the mismatch reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate) and the resource (shareable payment link for a customer), which is specific enough to convey the primary function. However, it does not explicitly differentiate from sibling tools like initiate_payment, which could also produce a payment URL, so it misses the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as initiate_payment or verify_payment. It also doesn't mention any prerequisites or context (e.g., whether a customer must exist). This leaves the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a payment through any configured WariMCP provider. Returns a checkout URL for the customer.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in whole currency units (e.g. 5000 for 5000 XOF) | |
| currency | No | ISO currency code: XOF, XAF, CDF, GNF | XOF |
| provider | No | Payment provider: cinetpay, wave, mock | cinetpay |
| returnUrl | No | Redirect URL after payment | |
| callbackUrl | No | Your webhook URL for payment notifications | |
| description | No | Payment description shown to customer | Payment |
| customerName | Yes | Full customer name | |
| customerEmail | No | Customer email | |
| customerPhone | Yes | Phone in international format: +2250707070707 | |
| idempotencyKey | Yes | Unique key to prevent duplicate payments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that a checkout URL is returned, but does not mention side effects, idempotency behavior, authentication requirements, or the asynchronous nature of the payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that directly state the action and the return value. No unnecessary words or repetition are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations, and multiple related sibling tools), the description is too minimal. It does not explain operational context, payment lifecycle, or edge cases, making it insufficient for an agent to fully understand the tool's role.
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?
The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific detail beyond what the schema provides, and its mention of 'any configured WariMCP provider' only restates the provider capability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates a payment and returns a checkout URL, using a specific verb and resource. However, it does not explicitly differentiate this from sibling tools like generate_payment_link or initiate_payout, relying mostly on the tool name and schema for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or context. It simply states the action without explaining when it should be preferred over other payment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disburse funds to a mobile money wallet or bank account (seller payouts)
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payout amount | |
| method | No | Payout method | mobile_money |
| currency | No | Currency | XOF |
| provider | No | Payout provider: wave | wave |
| recipientName | Yes | Recipient name | |
| idempotencyKey | Yes | Unique key to prevent duplicate payouts | |
| recipientPhone | Yes | Recipient phone: +2250707070707 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only states the action ('disburse funds') without disclosing side effects, idempotency requirements, or failure modes. The schema includes an idempotencyKey but the description does not highlight it, leaving the agent uninformed about critical behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and includes a clarifying parenthetical. Every word contributes; there is no fluff or repetition.
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?
The schema fully documents all parameters, which mitigates the lack of detail. However, with no output schema and no annotations, the description does not explain return format, operational prerequisites, or potential errors. It is a minimal viable description for a 7-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 7 parameters, so the baseline is 3. The description adds no extra meaning beyond the schema, except for implicitly mentioning the 'method' choice via 'mobile money or bank account'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combo ('Disburse funds to a mobile money wallet or bank account') and adds context ('seller payouts') that distinguishes it from sibling tools like initiate_payment or refund_payment. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for seller payouts, but it does not explicitly state when to use this tool over alternatives or mention exclusions. There is no reference to sibling tools or scenarios where another tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all WariMCP payment providers, their configuration status, and supported rails
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns all providers, with configuration status and supported rails, which goes beyond the tool name. It does not mention performance, auth, or error behavior, but for a read-only list operation this is relatively transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource, includes the key output fields, and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description adequately covers what it does and what information it returns. It could specify the exact response shape, but it already mentions the main fields (providers, status, rails), making it sufficient for agent decision-making.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details because none exist; nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'List' and the resource 'all WariMCP payment providers', and further details the included attributes (configuration status and supported rails). It is distinct from sibling tools, which focus on payments, transactions, and payouts rather than provider enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for discovering available payment providers and their capabilities, but it does not explicitly state when to use it versus alternatives or mention exclusions. As a simple enumeration tool, context is inferable, but there is no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent payment transactions with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| offset | No | Pagination offset | |
| status | No | Filter by status: pending, completed, failed, refunded | |
| provider | No | Filter by provider: cinetpay, wave, mock |
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 only states the obvious ('list') and does not explain what 'recent' means, sorting behavior, or whether the operation is read-only. It adds no context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It front-loads the core action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It fails to clarify the meaning of 'recent', the structure of results, or how this tool fits into the payment workflow. The schema covers inputs but not outputs or behavioral expectations.
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?
The input schema has 100% description coverage, so baseline is 3. The description's 'optional filters' is redundant with schema fields, but it does not add any new semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('list'), a distinct resource ('recent payment transactions'), and a scope ('with optional filters'). It distinguishes itself from sibling tools like initiate_payment and list_providers by clearly targeting transaction listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention contrast with payment initiation, verification, or provider listing, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a refund for a completed payment transaction
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Partial refund amount (omit for full refund) | |
| reason | No | Reason for refund | |
| transactionId | Yes | The WariMCP transaction ID to refund |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses only the 'completed payment' eligibility constraint, omitting refund-side effects, idempotency, or permission requirements. Limited behavioral detail.
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?
One clear, front-loaded sentence with no extraneous words. Efficiently communicates the core action.
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?
The tool is a financial mutation with no output schema or annotations. The description is too brief to cover return behavior, side effects, or usage context, leaving significant gaps for an agent.
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?
Input schema describes all three parameters with meaningful descriptions (amount, reason, transactionId), achieving 100% schema coverage. The tool description adds no parameter-specific semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('issue') and resource ('refund for a completed payment transaction'), clearly distinguishing it from payment initiation/verification siblings. The action and target are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for refunding completed payments but provides no explicit alternatives or when-not conditions. Sibling names suggest payment initiation/verification, but no direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a payment transaction
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | The WariMCP transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'check the status', which implies a read operation, but does not disclose the return format, any limitations, authentication requirements, or potential side effects. This is a significant gap for a read tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core action, and contains no superfluous information. It is appropriately concise for the tool's simplicity.
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?
The tool has a single parameter and no output schema, so complexity is low. However, without annotations or output schema, the description should ideally mention what the response will contain or any edge cases. The description covers the core purpose but misses the result shape, making it adequate but not fully complete.
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?
The input schema has one parameter with a full description, achieving 100% coverage. The tool description does not add any parameter information, but the baseline of 3 is appropriate because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('check') and the resource ('status of a payment transaction'), which is specific enough to distinguish from sibling tools like list_transactions or initiate_payment. The resource is well-defined and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context where a different tool should be used. This is a minimal viable description but lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a payout
| Name | Required | Description | Default |
|---|---|---|---|
| payoutId | Yes | The WariMCP payout ID |
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 only says 'Check the status of a payout,' which implies a read operation but does not disclose potential side effects, error behavior, or the nature of the returned status. The description is too sparse to convey meaningful behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is appropriately sized and front-loaded, with every word contributing to the core meaning.
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?
The tool is simple with one well-documented parameter, but there is no output schema and no annotations. The description does not explain what the response will contain or how to interpret the status, leaving a notable gap for a tool that is meant to return status information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the single parameter (payoutId) with a clear description, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (check) and the resource (payout), and it distinguishes from sibling tools like verify_payment and initiate_payout by specifying payout status checks. This is a specific verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking payout status, but it does not explicitly state when to use this tool versus alternatives like verify_payment or initiate_payout. No exclusions or preconditions are mentioned, so the guidance is only implied.
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. Dates show when Glama detected each change.
v2.0.0generate_payment_linkinitiate_paymentinitiate_payoutlist_providerslist_transactionsrefund_paymentverify_paymentverify_payoutTools are mostly distinct, but initiate_payment and generate_payment_link both create payment flows, which could cause confusion. Other tools (verify, refund, list, payout) are clearly separated.
All tools follow a consistent verb_noun pattern with clear verbs (list, initiate, verify, refund, generate) and nouns (providers, payment, link, payout, transactions). No mixed conventions.
8 tools is well-scoped for a payments server, covering payment and payout operations without unnecessary bloat.
The server covers the main payment lifecycle (initiate, verify, refund, list) and payout lifecycle (initiate, verify). Missing a dedicated single-transaction retrieval or cancel operation, but these can be worked around with list/verify.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
African intelligence infrastructure for AI apps, developers, and data products via MCP.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bigabou007-dev/warimcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
