Hundo

propose_transfer

Propose a transfer between two of the user's accounts. Same-currency transfers move the amount as-is; cross-currency transfers use the user-supplied exchangeRate or fall back to the exchange rate in force on the transfer date (the latest stored rate when the history does not reach back that far). Always include a short user-supplied description; optionally include a fee, recorded as a separate expense on the source account, or on the destination account when feeCurrency is the destination's currency. Returns a proposal id; to record it, call the confirm_proposal tool with the returned proposalId after the user approves (there is no UI button or proposal card to click in this context).

MCP note: this tool only CREATES a pending proposal; nothing is recorded until confirm_proposal is called.

Input Schema

TableJSON Schema

Name	Required	Description
`fee`	No	Optional transfer fee, MAJOR units (e.g. 2.50 for $2.50, 1000 for Rp 1,000), in feeCurrency. Recorded as a separate expense on the account whose currency it is in.
`date`	Yes
`amount`	Yes	Amount to transfer, in fromAccount currency, MAJOR units (the displayed amount, e.g. 100.00 for $100.00, 50000 for Rp 50,000). The server scales to storage units; never pre-multiply by 100.
`toCurrency`	No	3-letter currency for the destination amount. Required when toAccountId is omitted; otherwise inferred from the account.
`description`	Yes	Short user-supplied description, e.g. 'rent to landlord'.
`feeCurrency`	No	3-letter currency of the fee: the source account's (the default, e.g. the sending bank's charge) or the destination account's (e.g. a receiving bank that takes its fee out of what arrives). The fee comes out of the account with that currency. Any other currency is refused: convert the fee into one of the two first.
`toAccountId`	No	Id of the destination account. Omit only in the email-import pipeline when the email is genuinely ambiguous about the destination account. Do not pass an empty string; omit the field entirely instead.
`exchangeRate`	No
`fromCurrency`	No	3-letter currency for the source amount. Required when fromAccountId is omitted; otherwise inferred from the account.
`fromAccountId`	No	Id of the source account. Omit only in the email-import pipeline when the email is genuinely ambiguous about the source account - the user picks one via the Edit button. In chat, always pass a real id. Do not pass an empty string; omit the field entirely instead.
`editsProposalId`	No	Id of an existing pending proposal to update in place. Pass this when the user asks to modify a proposal you previously made (e.g. 'make it $50 instead'). Look up current ids with listPendingProposals if you're unsure. Omit when proposing something new.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 28, 2026

changedInput schema / properties / fee / description

Previous value: -"Optional transfer fee in fromAccount currency, MAJOR units (e.g. 2.50 for $2.50, 1000 for Rp 1,000). Recorded as a separate expense on the source account."New value: +"Optional transfer fee, MAJOR units (e.g. 2.50 for $2.50, 1000 for Rp 1,000), in feeCurrency. Recorded as a separate expense on the account whose currency it is in."

addedInput schema / properties / feeCurrency

Added value: +{
+  "description": "3-letter currency of the fee: the source account's (the default, e.g. the sending bank's charge) or the destination account's (e.g. a receiving bank that takes its fee out of what arrives). The fee comes out of the account with that currency. Any other currency is refused: convert the fee into one of the two first.",
+  "maxLength": 3,
+  "minLength": 3,
+  "type": "string"
+}

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / fromAccountId / description

Previous value: -"Id of the source account. Omit only in the email-import pipeline when the email is genuinely ambiguous about the source account — the user picks one via the Edit button. In chat, always pass a real id. Do not pass an empty string; omit the field entirely instead."New value: +"Id of the source account. Omit only in the email-import pipeline when the email is genuinely ambiguous about the source account - the user picks one via the Edit button. In chat, always pass a real id. Do not pass an empty string; omit the field entirely instead."

First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag this as a non-readonly, non-idempotent write, and the description goes well beyond them: nothing is recorded until confirm_proposal, the return value is a proposalId, the cross-currency rate falls back to the latest stored rate when history is short, and a fee becomes a separate expense on the fee-currency account. That is substantial behavioral context an agent needs.

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 core action, then currency handling, then the confirm handoff. It is dense with a long parenthetical clause, but each sentence carries information (fee placement, rate fallback, no-UI note) and nothing is redundant padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with no output schema, the description supplies the critical missing pieces: the pending-vs-recorded distinction, the returned proposalId, the confirm step, and the currency/rate/fee rules. An agent has everything needed to propose and later confirm correctly.

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 already 82% (baseline 3), yet the description adds real meaning beyond it — the exchangeRate fallback rule and the fee-as-separate-expense recording, plus the workflow framing for editsProposalId ('make it $50 instead'). Not every parameter is elaborated, but the highest-risk ones are.

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 verb and resource ('Propose a transfer between two of the user's accounts') and immediately scopes it apart from the sibling propose_transaction by describing same- vs cross-currency handling. The trailing MCP note reinforces that it only creates a pending proposal, not a recorded transfer.

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?

Explicitly tells the agent to call confirm_proposal with the returned proposalId after user approval, and notes there is no UI button in this context, which is genuine routing guidance. It does not, however, compare itself against the many other propose_* siblings (transaction, asset_trade, budget) in when-to-use terms.

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

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