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. |
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.
Add one secure layer between your agents and this server.
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.
