Skip to main content
Glama
Sign In
Yolfi

Yolfi

Official
by yolfinance
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Create Yolfi Public Payment

yolfi_payments_create

Creates a public payment invoice from an existing paylink or Checkout Session to support checkout integration, testing, or customer flow setup.

Instructions

Create a public payment invoice from an existing paylink or Checkout Session for checkout integration, testing, or customer flow setup.

Input Schema

NameRequiredDescriptionDefault
symbolYesPayment token symbol supported on the selected network, for example USDC on ARB or LTC on LTC.
networkYesChoose a network enabled in the organization or paylink supported-token catalog. Litecoin uses LTC.
languageNoOptional checkout language code supported by Yolfi.
metadataNoSafe non-secret metadata for the target app payment flow.
paylinkIdNoExisting paylink ID, required unless checkoutSessionId supplies the checkout context.
customerNameNoOptional customer name.
customerEmailNoCustomer email, required unless already present in the referenced Checkout Session. Do not invent an email.
customerPhoneNoOptional customer phone number.
subscriptionIdNoOptional existing subscription ID to associate the payment with.
customerAddressNoOptional customer address.
checkoutSessionIdNoCheckout Session public ID. The session supplies trusted amount, currency, and optional customer email.
clientReferenceIdNoOptional merchant reference for the customer or order; returned as customer.clientReferenceId in webhook payloads.
customerDateOfBirthNoOptional customer date of birth.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv0.2.1
    • addedInput schema / properties / checkoutSessionId
      Added value: +{
+  "description": "Checkout Session public ID. The session supplies trusted amount, currency, and optional customer email.",
+  "pattern": "^ycs_[a-f0-9]{32}$",
+  "type": "string"
+}
    • addedInput schema / properties / clientReferenceId
      Added value: +{
+  "description": "Optional merchant reference for the customer or order; returned as customer.clientReferenceId in webhook payloads.",
+  "type": "string"
+}
    • addedInput schema / properties / customerAddress
      Added value: +{
+  "description": "Optional customer address.",
+  "type": "string"
+}
    • addedInput schema / properties / customerDateOfBirth
      Added value: +{
+  "description": "Optional customer date of birth.",
+  "type": "string"
+}
    • changedInput schema / properties / customerEmail / description
      Previous value: -"Optional customer email for checkout or receipts."New value: +"Customer email, required unless already present in the referenced Checkout Session. Do not invent an email."
    • addedInput schema / properties / customerName
      Added value: +{
+  "description": "Optional customer name.",
+  "type": "string"
+}
    • addedInput schema / properties / customerPhone
      Added value: +{
+  "description": "Optional customer phone number.",
+  "type": "string"
+}
    • addedInput schema / properties / language
      Added value: +{
+  "description": "Optional checkout language code supported by Yolfi.",
+  "type": "string"
+}
    • changedInput schema / properties / network / description
      Previous value: -"Blockchain network identifier supported by the Yolfi organization, for example ARB."New value: +"Choose a network enabled in the organization or paylink supported-token catalog. Litecoin uses LTC."
    • addedInput schema / properties / network / enum
      Added value: +[
+  "ETH",
+  "ARB",
+  "OP",
+  "BASE",
+  "BNB",
+  "SOL",
+  "TRON",
+  "LTC"
+]
    • changedInput schema / properties / paylinkId / description
      Previous value: -"Yolfi paylink ID used to create the customer payment."New value: +"Existing paylink ID, required unless checkoutSessionId supplies the checkout context."
    • addedInput schema / properties / subscriptionId
      Added value: +{
+  "description": "Optional existing subscription ID to associate the payment with.",
+  "type": "string"
+}
    • changedInput schema / properties / symbol / description
      Previous value: -"Payment token symbol supported on the selected network, for example USDC."New value: +"Payment token symbol supported on the selected network, for example USDC on ARB or LTC on LTC."
    • changedInput schema / required
      Previous value: -[
-  "paylinkId",
-  "network",
-  "symbol"
-]New value: +[
+  "network",
+  "symbol"
+]
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the agent knows this is an open-world, non-idempotent write. The description adds only that the resulting invoice is 'public' and is derived from a paylink or session; it says nothing about duplicate-creation risk on retry, whether webhooks fire, or what happens to the referenced paylink.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the verb and resource first. The trailing use-case list ('checkout integration, testing, or customer flow setup') is somewhat loose but does not bloat the definition.

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?

For a 13-parameter, non-idempotent creation tool with no output schema, the description leaves the agent guessing what is returned (payment ID, checkout URL, status?) and whether org-level payment-token enablement is a precondition. The schema is thorough, but the absence of an output schema means the description should carry more of that burden.

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 100%, with all 13 parameters documented including the paylinkId/checkoutSessionId dependency and the ycs_ pattern for checkoutSessionId. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

Purpose4/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 public payment invoice') and names its input source ('from an existing paylink or Checkout Session'), which implicitly distinguishes it from the sibling yolfi_paylinks_create and yolfi_checkout_sessions_create tools that make those objects. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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?

Offers loose usage contexts ('checkout integration, testing, or customer flow setup') but gives no explicit when-to-use vs when-to-use-an-alternative guidance, no prerequisites, and no exclusions. An agent must infer from the schema that paylinkId or checkoutSessionId is the entry point.

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