ifthenpay Payments MCP
Server Details
Remote MCP for ifthenpay payments: Multibanco, MB WAY and Payshop.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.6/5 across 9 of 9 tools scored.
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.
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.
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.
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.
Available Tools
9 toolscofidis_create_paymentBInspect
Creates a Cofidis Pay instalment payment. Returns a payment URL where the customer can complete the purchase in instalments.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount in EUR. Cofidis has minimum and maximum limits per customer. | |
| order_id | Yes | Unique order identifier in your system (max 15 characters). | |
| return_url | Yes | URL to redirect the customer after the payment flow. The API appends &Success=True on approval, or another value on failure. | |
| cofidis_key | Yes | ifthenpay Cofidis Pay key. | |
| description | No | Short description or reference for the payment (e.g. order number). | |
| customer_name | No | Full name of the customer. | |
| customer_email | No | Email address of the customer. | |
| customer_phone | No | Customer phone number including country code (e.g. +351256245560). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions returning a URL for customer redirection but lacks details on side effects, authentication, idempotency, or error conditions.
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?
Two concise sentences, front-loaded with purpose and output. No unnecessary words.
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 description captures the core purpose but lacks details on flow, error handling, and response format for a payment tool of this complexity.
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%, so the description adds no new meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 specific action (creates a Cofidis Pay instalment payment) and the output (payment URL for customer completion). It distinguishes from sibling tools which are other payment methods.
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 on when to use this tool vs alternatives. No mention of prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
creditcard_create_paymentAInspect
Creates a credit/debit card payment session and returns a payment URL. The customer is redirected to a hosted checkout page to complete payment with their card.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount in EUR (e.g. 10.50). | |
| language | No | Language for the checkout page (e.g. "pt", "en"). Defaults to "pt". | |
| order_id | Yes | Unique order identifier in your system (max 15 characters). | |
| ccard_key | Yes | ifthenpay Credit Card key. | |
| error_url | Yes | URL to redirect the customer if the payment fails. | |
| cancel_url | Yes | URL to redirect the customer if they cancel the payment. | |
| success_url | Yes | URL to redirect the customer after a successful payment. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that a session is created and a URL returned, but fails to mention side effects (e.g., whether payment is captured immediately, idempotency, or failure scenarios). For a financial tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant wording. Purpose is front-loaded, and every word earns its place.
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?
No output schema exists, but description explains the flow (session creation, URL return, redirect). Lacks details on post-payment confirmation (e.g., webhooks, status polling) and error handling, which are important for a payment 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?
Input schema has 100% coverage with clear descriptions for all 7 parameters. The tool description adds context about the session creation and URL return but does not enhance parameter meaning beyond schema. Baseline 3 is appropriate.
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 'Creates a credit/debit card payment session and returns a payment URL', specifying the exact action and resource. It distinguishes this tool from sibling payment methods (COFIDIS, MBWay, etc.) by specifically mentioning credit/debit card.
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 card payment sessions but does not explicitly state when to use this tool versus alternatives like cofidis_create_payment. No when-not guidance or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mbway_check_statusAInspect
Checks the status of a previously requested MB WAY payment. Returns pending, paid, declined, timeout, or cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| mbway_key | Yes | ifthenpay MB WAY key. | |
| request_id | Yes | Request ID returned by mbway_request_payment. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It lists possible return statuses (pending, paid, etc.), which is good, but does not disclose idempotency, authentication needs, or side effects.
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?
Single sentence that front-loads the primary action with no unnecessary words or filler.
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 simple status-check tool with no output schema, the description provides return statuses, covering the main missing info. Could add error handling details, but adequate overall.
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 coverage is 100% with both parameters described. The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
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 checks the status of an MB WAY payment, using a specific verb and resource, and distinguishes it from sibling tools like mbway_request_payment.
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 after a payment request by referencing 'previously requested', but does not explicitly state when to use this vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mbway_request_paymentAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Customer mobile number in format "351#912345678" (country code # number). | |
| amount | Yes | Payment amount in EUR (e.g. 10.50). | |
| order_id | Yes | Unique order identifier in your system. | |
| mbway_key | Yes | ifthenpay MB WAY key. | |
| description | No | Short payment description shown in the MB WAY app. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions async approval but omits error scenarios, response structure, idempotency, or timeout details.
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?
Two sentences with no extraneous words, front-loaded with the core action and followed by a practical usage tip.
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?
Lacks details on return values, error handling, and confirmation steps beyond suggesting status check; incomplete for a payment tool with no output schema.
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 coverage is 100%, so description adds no additional meaning beyond the parameter descriptions already present in 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 clearly states the action ('sends') and the resource ('MB WAY payment request'), and distinguishes from sibling tool mbway_check_status by specifying the asynchronous workflow.
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?
Provides clear context that the customer approves in the app and that results should be checked via mbway_check_status, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
multibanco_create_referenceBInspect
Creates a Multibanco payment reference that the customer can use to pay at any ATM or via online banking in Portugal.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount in EUR (e.g. 10.50). | |
| mb_key | Yes | ifthenpay Multibanco key. | |
| order_id | Yes | Unique order identifier in your system. | |
| expiry_days | No | Number of days until the reference expires. Defaults to no expiry if omitted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states creation but omits side effects, idempotency, or authorization requirements. For a mutation tool, more behavioral context is needed.
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?
Single concise sentence front-loading key action and context with no extraneous words.
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?
Missing information on return value (no output schema), prerequisites for obtaining mb_key, and error scenarios. For a 4-parameter tool, more completeness is expected.
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 covers 100% of parameters with descriptions. Description adds no additional meaning beyond what schema already provides, so baseline score of 3 applies.
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?
Description clearly states the tool creates a Multibanco payment reference for ATM or online banking in Portugal, using a specific verb and resource. It distinguishes from sibling payment methods like creditcard_create_payment or payshop_create_reference.
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?
Description implies usage for generating ATM payment references but lacks explicit when-to-use vs alternatives (e.g., other payment methods) or prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payments_listAInspect
Lists completed payments using the ifthenpay Backoffice Key. Filter by payment method, date range, order ID, reference or request ID. Returns up to 1000 most recent payments if no filters are applied.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Filter by exact payment amount. | |
| bo_key | Yes | ifthenpay Backoffice Key (provided when signing the contract). | |
| entity | No | Payment method entity filter. Use: MB, MBWAY, PAYSHOP, CCARD, COFIDIS, GOOGLE, APPLE, PIX, or a 5-digit Multibanco entity number. Leave blank for all methods. | |
| date_end | No | End date/time in format dd-MM-yyyy HH:mm:ss (e.g. 31-01-2024 23:59:59). | |
| order_id | No | Filter by order identifier. | |
| reference | No | Filter by payment reference (Multibanco/Payshop reference or orderId for other methods). | |
| date_start | No | Start date/time in format dd-MM-yyyy HH:mm:ss (e.g. 01-01-2024 00:00:00). | |
| request_id | No | Filter by the unique request token returned at payment creation. | |
| sub_entity | No | Payment method key or sub-entity (e.g. MB KEY, MBWAY KEY, PAYSHOP KEY). Leave blank to match all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that only completed payments are returned, and there is a limit of 1000 results without filters. It does not mention auth requirements beyond the required bo_key, but that is covered. No contradictions.
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 three sentences covering purpose, filtering, and default behavior. No extraneous information, front-loaded, and efficient.
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 no output schema, the description covers what the tool does and the return limit. It lacks specifics on response format or sorting, but is sufficient for a list tool. Almost 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?
Schema description coverage is 100%, so the schema already fully describes parameters. The tool description only summarizes filter options without adding new meaning beyond the schema. Baseline 3 applies.
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 lists completed payments, specifies the required authentication (Backoffice Key), and lists filter options. It distinguishes itself from sibling tools which are all creation/check operations.
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 clear context for when to use this tool (listing completed payments with filters) and mentions the default return of up to 1000 payments. It does not explicitly exclude use cases or name alternatives, but sibling tools are all different operations, so implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payshop_create_referenceBInspect
Creates a Payshop payment reference that the customer can use to pay at any Payshop agent or CTT (postal service) in Portugal.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount in EUR (e.g. 10.50). | |
| order_id | Yes | Unique order identifier in your system (max 25 characters). | |
| expiry_date | No | Expiry date in YYYYMMDD format (e.g. 20301231). Leave blank for no expiry. | |
| payshop_key | Yes | ifthenpay Payshop key. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention the output format, success/failure responses, or any side effects. This is a significant gap for a payment creation tool.
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 concise sentence that conveys the essential purpose without any extraneous information. It is well-structured for quick consumption.
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 absence of annotations and an output schema, the description is incomplete. It lacks details on what the tool returns (e.g., the reference number), error handling, and how to use the generated reference. This leaves the agent under-informed for 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 covers all four parameters with descriptions, so the description adds little beyond context. It reinforces the purpose of the reference but does not provide additional semantics for individual parameters. Baseline score of 3 is appropriate.
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 ('creates'), the resource ('Payshop payment reference'), and the context (payment at Payshop agents or CTT in Portugal). This effectively distinguishes it from sibling tools for other payment methods.
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 when to use this tool (for Payshop payments) but does not explicitly state when not to use it or mention alternatives. Given the sibling tools list, more explicit guidance would improve decision-making for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pinpay_create_paymentAInspect
Creates a Pay by Link / PINPAY payment. Returns a shareable payment URL and a PIN code. The hosted checkout supports multiple payment methods including Credit Card, Google Pay, and Apple Pay.
| Name | Required | Description | Default |
|---|---|---|---|
| otp | No | One-time payment: "true" makes the link expire after a single payment. | |
| lang | No | Language for the payment page: pt, en, es, fr. Defaults to pt. | |
| amount | Yes | Payment amount in EUR (e.g. 10.50). | |
| accounts | No | Payment methods to show in the gateway, separated by semicolons. Format: METHOD|KEY (e.g. "MBWAY|MBWAY-KEY;MB|MB-KEY;PAYSHOP|PAYSHOP-KEY;CCARD|CCARD-KEY"). Leave blank to use gateway defaults. | |
| order_id | Yes | Unique order identifier in your system (max 15 characters). | |
| error_url | No | URL to redirect the customer if the payment fails. | |
| cancel_url | No | URL to redirect the customer if they cancel. | |
| description | No | Short description shown on the payment page (max 200 characters). | |
| expiry_date | No | Link expiry date in YYYYMMDD format (e.g. 20301231). Leave blank for no expiry. | |
| gateway_key | Yes | ifthenpay Gateway key for Pay by Link / PINPAY. | |
| success_url | No | URL to redirect the customer after a successful payment. | |
| btn_close_url | No | URL for the close/back button on the payment page. | |
| btn_close_label | No | Label text for the close/back button. | |
| selected_method | No | Pre-select a payment method: 1=Multibanco, 2=MB WAY, 3=Payshop, 4=Credit Card, 7=Cofidis Pay, 8=Pix. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially covers behavior (returns URL & PIN, supports multiple methods) but omits important details like authentication requirements, idempotency, or what happens on failure. No contradiction with missing annotations.
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?
Two concise sentences that front-load the essential information. Every sentence adds value without redundancy or waffle.
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 14 parameters and no output schema, the description covers the main returns but lacks details on response structure, error handling, or additional behavioral context. Adequate but not comprehensive.
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 coverage is 100% with clear parameter descriptions. The tool description adds minimal extra semantics beyond stating the return values and supported methods. Baseline 3 is appropriate.
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 starts with a clear verb-resource pair ('Creates a Pay by Link / PINPAY payment') and specifies what is returned ('shareable payment URL and a PIN code'). It also distinguishes from sibling tools that focus on specific payment methods.
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 explicit guidance on when to use this tool over siblings like `creditcard_create_payment` or `mbway_request_payment`. The description implies it's for general Pay by Link, but lacks direct comparison or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pix_create_paymentAInspect
Creates a PIX payment for Brazilian customers. Returns a payment URL and a QR code value. Customer must have a CPF number (Brazilian tax ID).
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount in BRL (e.g. 50.00). | |
| pix_key | Yes | ifthenpay PIX key. | |
| order_id | Yes | Unique order identifier in your system (max 25 characters). | |
| description | No | Short description or reference for the payment (max 200 characters). | |
| customer_cpf | Yes | Customer CPF number (Brazilian tax ID), digits only (e.g. 74026594025). | |
| redirect_url | Yes | URL to redirect the customer after payment. Check payment status via the status API after redirect. | |
| customer_city | No | Customer city. | |
| customer_name | Yes | Full name of the customer (max 150 characters). | |
| customer_email | Yes | Customer email address. | |
| customer_phone | Yes | Customer phone number including country code (e.g. +5585912345678). | |
| customer_state | No | Customer state (e.g. CE, SP). | |
| customer_address | No | Customer street address. | |
| customer_zip_code | No | Customer postal/ZIP code. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must convey behavioral traits. It mentions that the tool creates a payment and returns specific values, but it fails to disclose important behaviors such as idempotency, whether the payment is immediately chargeable, or if multiple calls with the same order_id are safe. The description is too minimal for a mutation operation with no annotations.
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 at three sentences, with no redundant phrases. It front-loads the core purpose and output, then adds a critical prerequisite. Every sentence serves a clear purpose, making it efficient for an AI agent.
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 has 13 parameters (8 required), no output schema, and no annotations, the description is relatively brief. It covers the basic purpose and output, but lacks details on post-creation steps (e.g., how to process the payment URL or verify status). The redirect_url parameter's schema hints at status checking, but the description does not reinforce this. The description is adequate but not comprehensive for the tool's complexity.
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 the baseline is 3. The description adds marginal value by emphasizing the CPF requirement and the return of a URL and QR code. It does not, however, provide additional meaning about how parameters interact or format nuances beyond the schema. This meets the baseline but does not exceed it.
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 ('Creates a PIX payment'), targets a specific customer group ('for Brazilian customers'), and lists distinct outputs ('Returns a payment URL and a QR code value'). This differentiates it from sibling payment tools like 'creditcard_create_payment' or 'mbway_request_payment'.
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 includes a key prerequisite ('Customer must have a CPF number (Brazilian tax ID)'), which guides usage context. However, it does not explicitly state when not to use this tool over alternatives (e.g., 'If the customer does not have a CPF, use a different payment method'). The sibling tool list provides some implicit guidance but lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!