Skip to main content
Glama
Sign In
CigalPay MCP Server

CigalPay MCP Server

Official
by cigalpay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Create a crypto payment link

create_checkout

Creates a USD or EUR payment and returns a CigalPay checkout link so customers can pay in their chosen crypto; the rate is locked for 30 minutes up to 5,000 per payment.

Instructions

Create a payment priced in USD or EUR and return the CigalPay checkout link to send to the customer. The customer chooses the coin on the checkout page; the rate is locked for 30 minutes. Maximum 5,000 per payment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount": "<amount>",
      "currency": "<currency>",
      "description": "<description>"
    },
    "name": "create_checkout"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoCheckout language (default en)
amountYesPrice in the currency, e.g. 49.9
currencyYes
order_idNoYour reference for this payment (generated if omitted)
notify_urlNoPublic HTTPS URL that receives signed payment notifications
return_urlNoWhere the customer goes after paying
descriptionYesShown to the customer, e.g. "Logo design - invoice 1042"
fee_paid_byNoWho pays the processing fee: 'customer' adds it to the price the customer pays. Omit to use the dashboard setting

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • addedInput schema / properties / fee_paid_by
      Added value: +{
+  "description": "Who pays the processing fee: 'customer' adds it to the price the customer pays. Omit to use the dashboard setting",
+  "enum": [
+    "customer",
+    "merchant"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the description's job is to add context, and it does: the rate is locked for 30 minutes, the customer selects the coin downstream, and the per-payment ceiling is 5,000. It stops short of disclosing what happens on expiry, whether retries create duplicate payments, or how notifications are delivered beyond the schema note on notify_url.

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?

Three sentences, front-loaded with the action and return value, followed by the two constraints an agent most needs before calling. No redundant restatement of the name or title and nothing that could be cut.

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

Completeness4/5

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

For an open-world, non-idempotent money-creating tool with no output schema, the description usefully explains what comes back (a checkout link) and the rate-lock window. The notable remaining gap is retry/idempotency guidance, since a repeated call creates a second payment; failure behavior and link expiry are also unmentioned.

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?

Schema description coverage is 88%, so the schema already carries the parameter semantics (currency enum, amount maximum, fee_paid_by meaning, URL formats). The description only echoes the currency restriction and the 5,000 cap, and adds no guidance on order_id reuse or when to set fee_paid_by versus relying on the dashboard default.

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?

States a specific verb and resource ('Create a payment') plus the concrete return value ('the CigalPay checkout link'), scoped to USD/EUR. Creation is plainly distinct from the read-oriented siblings (get_payment, list_active_payments, list_refunds), so an agent can select it without opening the schema.

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

Usage Guidelines3/5

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

Usage is only implied: the agent can infer this is the tool for starting a new payment rather than inspecting one. There is no explicit when-to-use versus when-not, no prerequisite about the customer needing to pick a coin on the hosted page, and no pointer to get_payment for checking the resulting state.

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

Deploy Server

Other Tools