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_registerA | Register a Yolfi workspace through the public agent registration endpoint when no YOLFI_API_KEY exists yet. This returns an API key once; store it in an ignored env file or secret manager before using private tools. |
| yolfi_auth_statusA | Verify that YOLFI_API_KEY can authenticate and return the current Yolfi organization context before mutating payment settings. |
| yolfi_organization_getA | Read the current Yolfi organization settings, including webhook and settlement configuration visible to this API key. |
| yolfi_organization_updateB | Update organization profile fields through the existing Yolfi organization endpoint. Do not invent merchant identity, support email, webhook URL, or settlement settings. |
| yolfi_settlement_configureA | Configure settlement wallets after the user provides wallet addresses, networks, and enabled tokens. Never invent wallet addresses. |
| yolfi_webhooks_configureA | Configure webhook delivery for the target app. The host must not invent backend URLs and must ensure the app verifies X-Yolfi-Signature. |
| yolfi_paylinks_createB | 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_payments_createA | Create a public payment invoice from an existing paylink 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 13 tools
Each tool targets a distinct resource and action: organization, auth, settlements, webhooks, paylinks, and payments. Even similar-sounding tools like auth_status vs organization_get and webhooks_configure vs webhooks_verify are clearly separated by verification vs configuration intent.
All tools share the yolfi_ prefix and follow a consistent resource_action pattern such as organization_get, paylinks_create, and webhooks_verify. Naming is uniformly snake_case with no camelCase or mixed verb styles, making the action/resource order highly predictable.
13 tools is well inside the ideal range for a payment-adjacent MCP server. Each tool maps to a meaningful workflow step—registration, auth, organization settings, settlements, webhooks, paylinks, and payments—with no obvious redundancy.
Core lifecycles are well covered: paylinks support create/list/get/disable, payments support create/status, and webhooks support configure/verify. Minor gaps like no paylink update/enable, no payment cancellation or refund, and no webhook deletion exist, but agents can work around them by disabling/recreating paylinks or relying on existing coverage.