Skip to main content
Glama
Sign In
Yolfi

Yolfi

Official
by yolfinance
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Create Yolfi Paylink

yolfi_paylinks_create

Create a Yolfi payment link after approval of product, amount, currency, and one-time or recurring billing.

Instructions

Create a Yolfi payment link only after the user approves product name, amount, currency, and one-time or recurring payment type.

Input Schema

NameRequiredDescriptionDefault
nameYesUser-approved product, plan, donation, or access name shown on checkout.
typeNoPayment link type: ONE_TIME or RECURRING.
priceYesUser-approved decimal price, represented as a string to avoid numeric rounding.
currencyNoAccount currency code. Supported values are USD, EUR, and CNY.
imageUrlNoOptional public product image URL shown on checkout.
metadataNoSafe non-secret metadata such as source, productSlug, planId, or environment.
collectNameNoWhether checkout should collect the customer name.
descriptionNoOptional user-approved customer-facing description.
collectEmailNoWhether checkout should collect customer email.
collectAddressNoWhether checkout should collect the customer address.
paymentMetadataNoDefault payment metadata as a flat map of strings, finite numbers, or booleans; do not use customer-controlled metadata as authorization.
recurringIntervalNoRecurring billing interval when type is RECURRING.
collectDateOfBirthNoWhether checkout should collect the customer date of birth.
collectPhoneNumberNoWhether checkout should collect the customer phone number.
recurringIntervalCountNoMultiplier for the recurring interval; the backend applies the interval-specific maximum.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv0.2.1
    • addedInput schema / properties / collectAddress
      Added value: +{
+  "description": "Whether checkout should collect the customer address.",
+  "type": "boolean"
+}
    • addedInput schema / properties / collectDateOfBirth
      Added value: +{
+  "description": "Whether checkout should collect the customer date of birth.",
+  "type": "boolean"
+}
    • addedInput schema / properties / collectName
      Added value: +{
+  "description": "Whether checkout should collect the customer name.",
+  "type": "boolean"
+}
    • addedInput schema / properties / collectPhoneNumber
      Added value: +{
+  "description": "Whether checkout should collect the customer phone number.",
+  "type": "boolean"
+}
    • changedInput schema / properties / currency / description
      Previous value: -"Fiat or account currency code approved by the user, for example USD."New value: +"Account currency code. Supported values are USD, EUR, and CNY."
    • addedInput schema / properties / currency / enum
      Added value: +[
+  "USD",
+  "EUR",
+  "CNY"
+]
    • addedInput schema / properties / imageUrl
      Added value: +{
+  "description": "Optional public product image URL shown on checkout.",
+  "type": "string"
+}
    • addedInput schema / properties / paymentMetadata
      Added value: +{
+  "description": "Default payment metadata as a flat map of strings, finite numbers, or booleans; do not use customer-controlled metadata as authorization.",
+  "type": "object"
+}
    • changedInput schema / properties / recurringInterval / description
      Previous value: -"Recurring interval when creating a recurring payment link."New value: +"Recurring billing interval when type is RECURRING."
    • addedInput schema / properties / recurringInterval / enum
      Added value: +[
+  "WEEK",
+  "BIWEEK",
+  "TWO_DAYS",
+  "MONTH",
+  "BIMONTH",
+  "QUARTER",
+  "BIANNUAL",
+  "YEARLY"
+]
    • addedInput schema / properties / recurringIntervalCount
      Added value: +{
+  "description": "Multiplier for the recurring interval; the backend applies the interval-specific maximum.",
+  "maximum": 183,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / type / description
      Previous value: -"Payment link type approved by the user, for example ONE_TIME or RECURRING."New value: +"Payment link type: ONE_TIME or RECURRING."
    • addedInput schema / properties / type / enum
      Added value: +[
+  "ONE_TIME",
+  "RECURRING"
+]
    • changedInput schema / required
      Previous value: -[
-  "name",
-  "price",
-  "currency",
-  "type"
-]New value: +[
+  "name",
+  "price"
+]
  2. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral constraint — the mandatory user-approval gate before invocation — but says nothing about non-idempotency (repeated calls create duplicate links), whether the link goes live immediately, or failure modes.

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?

A single front-loaded sentence containing the verb, the resource, and the one non-obvious constraint. No filler, no repetition of the title.

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 15-parameter, non-idempotent creation tool with no output schema, the description should at least indicate what comes back (a link URL/slug) and note duplicate-creation risk. It covers the approval contract well but leaves those gaps, relying entirely on the rich schema for field-level correctness.

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%, including enum values and the recurringInterval/type dependency, so the schema carries the parameter burden and the baseline of 3 applies. The description reinforces which four fields must be user-confirmed but adds no syntax, format, or defaulting detail beyond the schema.

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?

Opens with a specific verb+resource ("Create a Yolfi payment link"), which cleanly separates it from the read/disable siblings like yolfi_paylinks_get, yolfi_paylinks_list, and yolfi_paylinks_disable. It does not, however, contrast itself with yolfi_checkout_sessions_create, the closest ambiguous alternative.

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?

Gives a real precondition ("only after the user approves product name, amount, currency, and one-time or recurring payment type"), which is actionable usage guidance. But there is no statement of when to pick this over yolfi_checkout_sessions_create or yolfi_payments_create, so direction toward the right sibling is left implicit.

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