FortFi Treasury MCP

propose_transfer

Transfer USDC to an allowlisted recipient, OR pay a FortFi invoice by public pid (paymentRequestPid + fromWalletId — amount optional for partial pay). Recipient path requires allowlist approval. Invoice path binds settlement to the pid (Delegated Access / agent accounts execute server-side when configured).

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": {
      "fromWalletId": "<fromWalletId>"
    },
    "name": "propose_transfer"
  }
}

Input Schema

Name	Required	Description
`memo`	No	Optional transfer note (max 256 chars)
`amountUsdc`	No	Amount in USDC as a decimal string, e.g. '5.00'. Required for recipient sends; optional for invoice pay (defaults to remaining balance).
`recipientId`	No	Allowlisted recipient id (omit when using paymentRequestPid)
`fromWalletId`	Yes	Source wallet id from list_wallets
`networkChainId`	No	Optional. Send from the same EVM address on another supported mainnet (e.g. 'arbitrum-mainnet' for USDC withdrawn from Hyperliquid). Recipient must be allowlisted on that network. Omit to use the wallet's home network. Not allowed with paymentRequestPid.
`paymentRequestPid`	No	Public invoice pid from checkout URL — pays merchant vault with pid-bound settlement

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description provides some behavioral context: recipient sends require allowlist approval, invoice settlement is pid-bound, and Delegated Access or agent accounts may execute server-side. However, it does not disclose whether the tool creates a pending proposal requiring confirmation, execution timing, or authorization requirements.

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 description is short, front-loaded, and covers the two main paths without filler. Some density in the parenthetical clauses slightly reduces readability but does not make it verbose.

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?

It covers the two transfer modes and key constraints such as allowlist approval and pid-bound settlement. Given the absence of annotations and output schema, it is incomplete about proposal lifecycle, confirmation flow, and what happens after invocation.

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 the baseline is 3. The description adds useful path-level meaning, such as pairing paymentRequestPid with fromWalletId and allowing optional amounts for partial invoice payments, but most parameter semantics are already fully documented in 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?

The description states specific actions and resources: transfer USDC to an allowlisted recipient or pay a FortFi invoice by public pid. It clearly distinguishes the two internal paths but does not name or differentiate from sibling tools such as pay_payment_request_x402 or propose_payout_manifest.

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 clear conditions for choosing the recipient path versus the invoice path, including the allowlist requirement and that amount is optional for invoice partial pay. It does not explicitly state when to use this tool instead of related sibling tools or when not to use it.

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

All FortFi Treasury MCP tools Inspect

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

Need Help?