Yolfi
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| YOLFI_API_KEY | No | Optional at server startup. Required after registration for private MCP tools. Public agent registration works without it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| yolfi_agent_setup_startA | Start the preferred browser-based Yolfi authorization flow. Returns a login URL and stores only a short-lived check-in token in the protected local Yolfi config. |
| yolfi_agent_checkinA | Check whether browser authorization finished. On success, securely stores the returned yolfi_agent_* credential for later local SDK, CLI, and MCP calls. |
| yolfi_agent_registerA | Start signup for a new Yolfi user from a user-confirmed email. The first call sends a confirmation link and stores protected check-in state; call the same tool again after confirmation to store the one-time credential without exposing it. |
| yolfi_auth_statusA | Verify this local MCP connection using its stored agent credential or explicit credential override and return the current organization. No additional API key is needed after browser setup. |
| yolfi_organization_getA | Read the current Yolfi organization settings, including webhook and settlement configuration available to this authenticated connection. |
| yolfi_organization_updateB | Update organization profile fields through the existing Yolfi organization endpoint. Do not invent merchant identity, support email, or settlement settings. |
| yolfi_settlement_configureA | Add or update only the supplied settlement networks, preserving other configured networks. Read current settings first and reuse approved wallet addresses; ask only for missing wallet or token decisions. |
| yolfi_webhooks_configureA | Create a webhook endpoint only after listing and reusing any matching endpoint. Stores its signing secret locally without returning plaintext. Use an existing app URL and verify X-Yolfi-Signature. |
| yolfi_webhooks_listA | List all independent webhook endpoints configured for the current organization. |
| yolfi_webhooks_updateB | Update the name, URL, adapter, or enabled state of one independent Yolfi webhook endpoint. |
| yolfi_webhooks_rotate_secretA | Rotate an endpoint-specific webhook signing secret and store it in the protected local Yolfi config without returning the plaintext secret. |
| yolfi_webhooks_deleteA | Delete an unused webhook endpoint or disable it when existing delivery history must be retained. |
| yolfi_paylinks_createA | Create a Yolfi payment link only after the user approves product name, amount, currency, and one-time or recurring payment type. |
| yolfi_paylinks_listA | List existing Yolfi paylinks before creating new ones so agents can avoid duplicates after retries or timeouts. |
| yolfi_paylinks_getA | Get private paylink details by ID for verification, checkout wiring, or duplicate detection. |
| yolfi_paylinks_disableA | Disable a paylink. This is destructive and must only run after explicit user confirmation. |
| yolfi_checkout_sessions_createA | Create hosted checkout for an existing paylink or a server-approved standalone amount and currency. Reuse the same idempotencyKey for the same order on retries. |
| yolfi_checkout_sessions_getA | Read a Checkout Session belonging to the authenticated organization and inspect its payment state. |
| yolfi_payments_createB | Create a public payment invoice from an existing paylink or Checkout Session for checkout integration, testing, or customer flow setup. |
| yolfi_payments_statusA | Get public payment status by ID. Do not treat a frontend redirect as proof of payment. |
| yolfi_webhooks_verifyA | Verify an X-Yolfi-Signature HMAC over the raw JSON webhook payload before trusting payment events. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| integrate_yolfi_payments | Inspect an app and add Yolfi checkout plus webhook handling. |
| create_yolfi_paylink | Create a Yolfi paylink after collecting product and pricing decisions. |
| add_yolfi_webhook_handler | Add a webhook handler with X-Yolfi-Signature verification. |
| verify_yolfi_payment_flow | Verify checkout, public payment status, and webhook handling. |
| migrate_existing_stripe_webhook_to_yolfi_adapter | Reuse an existing Stripe-style webhook path with Yolfi adapter output. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Yolfi LLM Index | |
| Agent Quickstart | |
| Webhook Setup | |
| Paylink API | |
| Codex Integration Prompt | |
| Claude Code Integration Prompt | |
| Cursor Integration Prompt |
TDQS
Scored across 21 tools
Most resource groups are clearly separated, but three creation tools (yolfi_paylinks_create, yolfi_checkout_sessions_create, yolfi_payments_create) have overlapping purposes that require careful reading to choose correctly. The four auth tools (agent_setup_start, agent_register, agent_checkin, auth_status) also have subtle boundaries, especially since checkin is shared across two flows, and webhooks_configure vs webhooks_update blur create/update.
The dominant yolfi_<resource>_<action> snake_case pattern is applied consistently across paylinks, checkout_sessions, webhooks, organization, and payments. Minor deviations exist: yolfi_agent_setup_start puts the verb last, yolfi_agent_checkin has no resource/action split, and yolfi_webhooks_configure is really a create operation named inconsistently with the rest of the CRUD set.
At 21 tools the surface is on the heavy side for a payments server, and the auth group alone consumes four tools that could likely be consolidated. The webhook group (six tools) is defensible given full lifecycle needs, but overall the count sits at the borderline of the 16-25 range.
Webhooks have full CRUD plus rotate and verify, and paylinks cover create/get/list/disable, but there are notable gaps: no paylink update or re-enable, no checkout session list or cancel/expire, and no payment list or refund operation. Agents handling real payment workflows will hit dead ends around refunds and session cleanup.