Skip to main content
Glama
Sign In

IFSO

by io.github.ifsodev
OverviewDiscussionsAdmin

Prepare an IFSO payment (unsigned)

ifso_prepare_payment
Read-only

Turns a command like "/ifso 0x... 20 on 2026-12-01" into a plain preview and the UNSIGNED data to create that if-so payment from the sender's own wallet: two transactions (USDG approve, then create) or one gasless authorization to sign. This server never signs, never holds a key and never sends anything; the sender reviews and signs in their own wallet. Same checks as the site's build step.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>",
      "sender": "<sender>"
    },
    "name": "ifso_prepare_payment"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesThe command, e.g. "/ifso 0x... 20 on 2026-12-01" or "/challenge 0x... 10 if nvda closes above 200 by friday". See ifso_list_conditions.
senderYesThe wallet that sends the USDG and signs.
linkKeyNoFor a claim link: the address derived from the link secret. Keep the secret yourself; never send it.
refereeNoReferee wallet for a referee condition, when not typed in the command.
recipientNoRecipient, when the command says link and you want a fixed recipient instead.
altRefundToNoSecond refund address, used if the sender cannot receive USDG.
cancellableNoLet the sender cancel before anything happens (default false).
tzOffsetMinNoThe person's UTC offset in minutes for dates (e.g. 240 for UTC+4). Stock deadlines always use New York time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description meaningfully reinforces this in a context where it would otherwise be surprising: producing transaction calldata sounds like a write, yet 'This server never signs, never holds a key and never sends anything' makes clear no on-chain effect occurs. 'Same checks as the site's build step' hints that validation can reject a command, but failure modes, what the preview contains, and any rate limits are left unstated.

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?

The key fact (unsigned, never signs, sender signs in own wallet) is front-loaded and the output forms appear before the safety statement. The first sentence is long and clause-heavy, but every clause carries information and there is no filler.

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?

With eight parameters and no output schema, the description does the necessary work of describing what comes back (a preview plus unsigned approve/create transactions or a gasless authorization to sign), which an agent needs in order to act. Gaps remain around rejection/validation behavior and the fee or cost information an agent might need before calling, which a sibling like ifso_quote_fees presumably covers but which is never pointed at.

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 parameter is already documented in the schema, and the description adds little beyond that. It does contextualize the text parameter via an example command and implicitly ties the 'gasless authorization' path to claim-link inputs, but the optional parameters (linkKey, recipient, altRefundTo, tzOffsetMin) get no further meaning from the description. Baseline 3 is appropriate.

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 concrete transformation (a slash-style command becomes a plain preview plus UNSIGNED transaction data) and specifies the two possible output shapes: approve+create, or one gasless authorization. It does not name or contrast any of the sibling tools (e.g. ifso_quote_fees or ifso_explain_payment), so an agent must infer the boundary itself, but the verb+resource is otherwise unambiguous.

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?

Usage is implied rather than stated: 'Turns a command like ... into ... the UNSIGNED data to create that if-so payment' tells an agent this is the build step, and 'the sender reviews and signs in their own wallet' implies the handoff point. There is no explicit 'use this when / use X instead' routing against ifso_quote_fees, ifso_explain_payment, or ifso_get_payment, and no stated prerequisites such as requiring a valid parsed command or sufficient USDG balance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All IFSO toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources