keyfo

Fund agent wallet

fund_agent

Read-onlyIdempotent

Quote moving funds from another network (ethereum, base, arbitrum, optimism, bnb, polygon and others, 15 in all, or a chain ID) to an agent wallet on Robinhood Chain, arriving as ETH. payer is the wallet that already holds the funds on the origin network: if the user did not name it, ask, do not reuse wallet. amount is in the smallest unit (wei for ETH), a number or a string of digits. Returns transactions for the payer to sign. The answer also has sign_url: a keyfo page where the user checks the transaction and signs it in their own wallet. It stays open for 15 minutes and gets a new quote itself when the price is out of date. Show that link to the user, and never ask them to paste the transaction data anywhere.

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": {
      "wallet": "<wallet>",
      "payer": "<payer>",
      "origin_chain": "<origin_chain>",
      "amount": "<amount>"
    },
    "name": "fund_agent"
  }
}

Input Schema

Name	Required	Description
`payer`	Yes	Wallet that pays on the origin network and signs there. It must hold the funds there, so it is usually not the agent wallet: ask the user for it, do not copy `wallet`.
`amount`	Yes	Amount in the smallest unit of what you pay with, like wei for ETH.
`wallet`	Yes	Agent wallet on Robinhood Chain that receives the ETH.
`currency`	No	Token address to pay with on the origin network. Empty pays in its native coin.
`origin_chain`	Yes	Network to pay from: a name, like base, or its chain ID, like 8453.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Goes well beyond the annotations, which only declare readOnly/openWorld/idempotent/non-destructive. It discloses the return shape (transactions for the payer to sign), the sign_url keyfo page, its 15-minute lifetime, automatic re-quoting on stale prices, and a display rule for the link — the kind of behavior an agent cannot infer from structured fields. It stops short of covering failure modes or unsupported-chain errors.

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?

Front-loaded with the action and scope, then the critical payer warning, then the return/signing contract. Dense but every sentence carries operational weight; the parenthetical chain list is slightly verbose but justifies the origin_chain flexibility.

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?

Strong for a complex cross-chain quote with no output schema — returns, signing flow, and link lifetime are all covered. However, nothing is said about fee/slippage expectations, quote expiry boundaries, error behavior for unsupported chains, or how many transactions may come back, leaving some agent-relevant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it enumerates supported origin chains (15 in all, or a chain ID), clarifies `amount` accepts a number or a string of digits in smallest units, and reinforces that `payer` must hold the funds and differs from `wallet`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (quote moving funds) with a precise resource and scope: from 15 named origin networks to an agent wallet on Robinhood Chain, arriving as ETH. An agent can distinguish this from siblings like build_trade or buy_at_price without opening the schema.

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?

Gives clear operational when-to-use context (funding an agent wallet from another network) and explicit pre-call instructions: ask the user for `payer` if unnamed and do not reuse `wallet`. It never names an alternative tool or a when-not-to-use condition, which is the only gap.

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

All keyfo 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?