Skip to main content
Glama
Sign In
Yolfi

Yolfi

Official
by yolfinance
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Create Yolfi Account For User

yolfi_agent_register

Starts Yolfi account signup from a user-confirmed email: send a confirmation link, then call again after confirmation to store the one-time credential without exposing it.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
refNoOptional source tag such as mcp, glama, npm, docs, codex, claude-code, or cursor.
emailYesNew Yolfi account email explicitly confirmed by the user. Existing Yolfi account emails are rejected and must use OAuth or browser setup.
languageNoOptional preferred language code for agent-facing responses.
metadataNoOptional safe non-secret metadata. Do not include API keys, wallet private keys, tokens, or personal secrets.
agentNameYesName of the coding agent or MCP host, for example Codex, Claude Code, Cursor, or OpenClaw.
projectUrlNoOptional public or local URL of the target product, if known.
projectNameYesUser-approved product or project name for the Yolfi workspace.
idempotencyKeyNoOptional retry key. Reuse the same value when calling this tool after email confirmation; a UUID is generated and persisted when omitted.
integrationIntentNoUser-approved reason for the integration. Defaults to accept_payments when omitted.accept_payments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.1
    • addedInput schema / properties / email
      Added value: +{
+  "description": "New Yolfi account email explicitly confirmed by the user. Existing Yolfi account emails are rejected and must use OAuth or browser setup.",
+  "format": "email",
+  "type": "string"
+}
    • addedInput schema / properties / idempotencyKey
      Added value: +{
+  "description": "Optional retry key. Reuse the same value when calling this tool after email confirmation; a UUID is generated and persisted when omitted.",
+  "maxLength": 200,
+  "minLength": 16,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "agentName",
-  "projectName"
-]New value: +[
+  "email",
+  "agentName",
+  "projectName"
+]
  2. Changed2 schema fields changedv0.1.4
    • addedInput schema / properties / integrationIntent / default
      Added value: +"accept_payments"
    • changedInput schema / properties / integrationIntent / description
      Previous value: -"User-approved reason for the integration, for example accept_payments, subscription, donation, or sell_digital_product."New value: +"User-approved reason for the integration. Defaults to accept_payments when omitted."
  3. Addedv0.1.1

TDQS

A4/5.0
Behavior4/5

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

Annotations cover the safety profile (mutation, open-world, non-idempotent, non-destructive), and the description adds genuinely new behavior: an outbound confirmation email is sent, protected check-in state is persisted, and a one-time credential is stored without exposure. It stops short of describing failure/retry behavior or what a repeat first-phase call does, so it is strong but not complete.

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?

Two tightly packed sentences with no filler; the core action and the two-phase protocol are front-loaded before any detail. Every clause carries information.

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 a nine-parameter, nested-object, no-output-schema tool, the description covers the essential lifecycle and the credential-handling constraint. What is missing is what the first call actually returns to the caller (link vs. state token) and how errors or partial signups are handled.

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%, so every one of the nine parameters (including idempotencyKey, metadata, integrationIntent) is already documented in the schema. The description adds only the 'user-confirmed email' framing and nothing about the individual parameters, 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?

The description states a specific verb and resource ('Start signup for a new Yolfi user') and scopes the input ('from a user-confirmed email'). It is clear on its own, but never names or distinguishes itself from similarly-named siblings such as yolfi_agent_setup_start and yolfi_agent_checkin, which it partially overlaps with by 'storing protected check-in state'.

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

Usage Guidelines4/5

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

It gives concrete usage sequencing: the first call sends a confirmation link, and the same tool is called again after confirmation to store the credential. The prerequisite of a user-confirmed email is stated. It lacks explicit exclusions (e.g., existing accounts must use OAuth/browser setup is only in the schema, not the description) and does not route to alternatives.

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