ifthenpay Payments MCP

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

No annotations are provided, so the description carries the full burden. It discloses the basic flow (creating a session and redirecting to a hosted checkout) but lacks details on idempotency, authentication, rate limits, or side effects beyond mutation.

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 two sentences long, front-loaded with the main action, and contains no extraneous words. Every word adds value.

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 7 parameters and no output schema or annotations, the description is adequate but could include more, such as the structure of the response (e.g., that it returns a payment URL) or how to handle the URL. The sibling tools are similar, so additional detail would aid differentiation.

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 each parameter already described. The description does not add meaningful context beyond the schema, though it groups the redirect URLs implicitly. Baseline 3 is appropriate since the schema covers the parameters.

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 creates a credit/debit card payment session and returns a payment URL. The name and description distinguish it from sibling tools like mbway_request_payment or multibanco_create_reference, as it's specifically for credit/debit cards.

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 does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites. The purpose is implied by the tool's name and description, but no direct guidance is given.

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

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

No annotations are provided, so the description carries the burden. It discloses the possible return statuses (pending, paid, declined, timeout, cancelled), which gives good behavioral insight. It does not mention idempotency or side effects, but 'checks status' implies a read-only operation.

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 wasted words. The most important information (what it does and what it returns) is front-loaded.

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 covers the action and return values adequately. It could mention polling behavior or that it only works for pending requests, but it is sufficiently complete for most use cases.

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 baseline is 3. The description adds value by noting that request_id comes from mbway_request_payment, linking to a sibling tool and providing usage context 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 clearly states the tool checks the status of a previously requested MB WAY payment, with a specific verb and resource. It distinguishes from sibling mbway_request_payment by implying it is the follow-up step.

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 indicates it is for previously requested payments, implying use after mbway_request_payment. It does not explicitly mention when not to use or list alternatives, but the context from sibling names is clear enough.

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

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

With no annotations, the description carries the full burden and does disclose the key non-obvious behavior: this is asynchronous, the customer approves out-of-band in the MB WAY app, and the outcome must be fetched via mbway_check_status. It omits retry/idempotency behavior around order_id, request expiry, and what happens if the customer declines, so it is strong but not complete.

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?

Three short sentences, front-loaded with the action and the required customer step, ending on the actionable next call. No filler or restatement of the name.

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 payment-initiation tool with no annotations and no output schema, the description covers the essential flow and the mandatory polling step. It is nearly complete, missing only failure/timeout and decline handling, which an agent would reasonably need for error paths.

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 all five parameters (including the country-code#number phone format and the max-15-character order_id) are already fully documented in the schema. The description adds no additional parameter meaning, so the 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?

States a specific verb and resource ('Sends an MB WAY payment request') and pins the distinctive mechanism ('customer's mobile phone' with approval 'in the MB WAY app'), which separates it from the card/PIX/Payshop payment siblings. It also names the paired tool mbway_check_status, so the agent can place it in the flow without opening a schema.

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?

'Use mbway_check_status to check the result' gives explicit follow-up guidance and implies the async two-step pattern. It does not, however, say when to choose MB WAY over the other create_payment siblings or what preconditions (valid MB WAY key, reachable phone) must hold, so it stops short of full when/when-not coverage.

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

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

No annotations are provided, placing full burden on the description. It lacks disclosure of important behavioral traits such as idempotency, error handling, default expiry (expiry_days optional but behavior unspecified), and what happens on duplicate order_id. The description only states the basic creation action.

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, clear sentence that front-loads the purpose with no unnecessary words. Every part 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?

For a tool with 4 parameters and no output schema, the description covers the purpose but misses behavioral details like idempotency, error scenarios, and response format. It is adequate for basic selection but incomplete for full reliance.

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%, with each parameter having a description in the schema. The description does not add additional meaning or usage guidance beyond the schema, so baseline score 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 identifies the verb ('Creates'), resource ('Multibanco payment reference'), and outcome ('customer can use to pay at any ATM or via online banking in Portugal'). It distinguishes the tool from siblings like 'creditcard_create_payment' and 'payshop_create_reference' by specifying the Multibanco payment method.

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 Portuguese ATM/online banking payments but does not explicitly state when to use this tool versus alternatives like Mbway or creditcard. No when-not conditions or alternative recommendations are provided, leaving the agent to infer from context.

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

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

With no annotations, the description carries the burden. It does disclose the default result limit ('up to 1000 most recent payments if no filters are applied') and the credential requirement (bo_key), which is helpful. However, it doesn't mention pagination, response format, error behavior, or whether filters are combined (AND semantics). These are notable gaps for a list operation, but the disclosed information adds some value.

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 filler: the first identifies the action, resource, and credential; the second lists filters and default behavior. It's front-loaded with the core purpose and scannable for an 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?

For a simple list tool with 100% schema coverage, the description covers the return limit and filter scope. Missing: whether multiple filters are combined, exact response structure, and any note on date range boundaries. Those are common expectations for a list endpoint and not fully disclosed, but the description is adequate 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?

Schema coverage is 100%, so the schema documents all parameters. The description adds the default behavior context and briefly restates filter categories, but doesn't add deeper semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting; the description's summary of filter types doesn't conflict with but doesn't enrich 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?

States a clear verb ('Lists') with a specific resource ('completed payments') and the credential used (Backoffice Key). It also distinguishes itself from siblings like mbway_request_payment and multibanco_create_reference by indicating it's a read/list operation, not a payment creation tool. The filter list and default behavior (1000 most recent) add specificity beyond the name alone.

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 says it filters by payment method, date range, order ID, reference or request ID, which implies read-after-create usage or listing past completed payments. It doesn't explicitly say 'use this instead of create/payment tools when listing completed payments', but the contrast with sibling create/status tools is clear from the description's wording. There are no explicit exclusions or alternative routing, so a 4 rather than 5.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, idempotency, or error conditions. For a creation tool, details about uniqueness of references, expiry handling, or lifecycle are missing.

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, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose without redundancy.

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 an output schema and annotations, the description is insufficient. It does not explain expected return values, error behavior, or practical usage notes, leaving significant gaps 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?

The input schema covers all 4 parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema, so the 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), resource (Payshop payment reference), and context (payment at Payshop agent or CTT in Portugal), distinguishing it from sibling tools like multibanco_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?

The description lacks explicit guidance on when to use this tool versus alternatives (e.g., for Payshop-specific payments). No mention of prerequisites or conditions under which it should be avoided.

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

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 does disclose that the tool creates a payment, returns a URL and PIN, and uses a hosted checkout. However, it omits important behavioral context such as whether the customer is charged immediately, expiry behavior beyond optional parameters, idempotency, or required gateway configuration.

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 short sentences with no filler. It front-loads the primary action and output, then adds useful context about supported payment methods. Every sentence 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?

For a 14-parameter tool with no output schema, the description supplies the essential context: it creates a hosted payment link, returns a URL and PIN, and supports multiple payment methods. The lack of explicit flow guidance or edge-case handling is a minor gap because the schema thoroughly documents all parameters.

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%, and each parameter already has a meaningful description. The tool description adds no parameter-level semantics beyond confirming the hosted-checkout payment flow, so the 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 a Pay by Link / PINPAY payment') and the key outputs ('shareable payment URL and a PIN code'). This is specific enough to distinguish it from sibling tools like multibanco_create_reference or creditcard_create_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 hosted-checkout context implies this is the right tool for creating a payment link that supports multiple payment methods, but there is no explicit when-to-use guidance or comparison with sibling payment-creation tools. Selection relies on inference from the name and the phrase 'Pay by Link / PINPAY.'

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

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. It adequately states that the tool creates a payment and returns URL and QR code, and notes the CPF requirement. However, it does not disclose side effects (e.g., whether it charges the customer immediately), error conditions, or idempotency behavior, which are important for a payment 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 concise (two sentences) and front-loaded with the primary action and outputs. The second sentence adds a critical requirement. While effective, it could be slightly more structured (e.g., separating preconditions).

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 13 parameters (8 required) and no output schema, the description covers the key output (URL and QR code) and a critical precondition (CPF). It also implies the use case (Brazilian customers). However, it does not explain the redirect_url behavior or how to check payment status, though sibling tools like payments_list may cover that.

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 the schema already describes all parameters. The description adds no parameter-specific semantics beyond what is in the schema, except reinforcing the CPF requirement. Baseline is 3, and the description does not significantly exceed that.

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'), target resource ('for Brazilian customers'), and outputs ('Returns a payment URL and a QR code value'). It distinguishes from sibling tools by specifying the payment method and customer geography.

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 explicitly states a precondition ('Customer must have a CPF number'), which helps the agent know when the tool is applicable. However, it does not provide guidance on when to use this tool over alternatives like creditcard_create_payment or mbway_request_payment, nor does it mention when not to use it.

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