Skip to main content
Glama

ifthenpay Payments MCP

by com.ifthenpay

mbway_request_payment

Sends an MB WAY payment request to the customer's mobile phone. The customer approves the payment in the MB WAY app. Use mbway_check_status to check the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
phoneYesCustomer mobile number in format "351#912345678" (country code # number).
amountYesPayment amount in EUR (e.g. 10.50).
order_idYesUnique order identifier in your system.
mbway_keyYesifthenpay MB WAY key.
descriptionNoShort payment description shown in the MB WAY app.

TDQS

A3.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 must fully disclose behavioral traits. It mentions that the customer approves in the MB WAY app, but lacks details on timeout, failure modes, idempotency, or authorization requirements, leaving significant gaps.

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 concise with two sentences, front-loading the primary action and immediately providing a usage guideline. Every sentence serves a clear purpose with no redundancy.

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

Completeness3/5

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

Given no output schema, the description should clarify what the tool returns. It only states that it sends a request and references checking status, but does not mention return values or success indicators. Completeness is adequate but not thorough.

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% coverage with descriptions for all parameters. The description adds no new information beyond the schema, such as the phone number format and amount in EUR, but does not enhance understanding further. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states that the tool sends an MB WAY payment request to the customer's mobile phone, using specific verbs and resource. It also differentiates from the sibling tool mbway_check_status by indicating its distinct role in the payment flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions to use mbway_check_status to check the result, providing a clear when-not-to-use scenario. However, it does not offer guidance on when to choose MB WAY over other payment methods like creditcard_create_payment.

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

All ifthenpay Payments MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct payment method or action (e.g., cofidis_create_payment vs mbway_request_payment), and the two MB WAY tools are clearly complementary (request vs check status). No ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent `method_action` pattern in snake_case (e.g., creditcard_create_payment, mbway_check_status, payments_list). Actions like `create_payment`, `create_reference`, and `request_payment` are appropriate for their respective methods.

Tool Count5/5

9 tools is well-scoped for a payment gateway MCP server, covering multiple payment methods and a list endpoint. Each tool serves a clear purpose without redundancy.

Completeness4/5

Covers creation for all payment methods and includes a status check for MB WAY. However, dedicated status/retrieve tools for other payment methods are missing; they rely on the payments_list endpoint. Missing cancellation or refund tools, which are common in payment systems.

Resources