Skip to main content
Glama

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.

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": {
      "amount": "<amount>",
      "date": "<date>",
      "description": "<description>"
    },
    "name": "propose_transfer"
  }
}

Input Schema

NameRequiredDescriptionDefault
feeNoOptional 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.
dateYes
amountYesAmount 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.
toCurrencyNo3-letter currency for the destination amount. Required when toAccountId is omitted; otherwise inferred from the account.
descriptionYesShort description taken from the user's message, e.g. 'rent to landlord'.
feeCurrencyNo3-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.
toAccountIdNoId 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.
exchangeRateNo
fromCurrencyNo3-letter currency for the source amount. Required when fromAccountId is omitted; otherwise inferred from the account.
fromAccountIdNoId 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.
editsProposalIdNoId 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.

  1. Changed1 schema field changed
    • changedInput schema / properties / description / description
      Previous value: -"Short user-supplied description, e.g. 'rent to landlord'."New value: +"Short description taken from the user's message, e.g. 'rent to landlord'."
  2. Changed2 schema fields changed
    • 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"
      +}
  3. Changed1 schema field changed
    • 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."
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare a non-readOnly, non-idempotent, non-destructive write, and the description adds real context beyond that: only a pending proposal is created, nothing is recorded until confirm_proposal, and the proposal id is returned. It also discloses the rate-fallback rule and that a fee becomes a separate expense on the source or destination account. It does not address repeat-call behavior, which matters given idempotentHint=false.

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 and the currency branching, then the return/confirmation workflow. The closing 'MCP note' repeats the confirm_proposal instruction already implied earlier, a small redundancy, but it is short and separated rather than padding the main paragraph.

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 an 11-parameter write tool with no output schema, the description covers the essential unknowns: pending-only semantics, the returned proposalId, cross-currency rate resolution, and fee placement. Date format and the exact shape of the proposal object are left to the schema and confirm_proposal, which is acceptable.

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 82%, so baseline is 3, but two parameters (exchangeRate, date) carry no schema description and the description supplies the semantics: user-supplied rate or the rate in force on the transfer date, falling back to the latest stored rate. It also states the fee attaches to the account whose currency it is in, which is cross-field meaning the schema only partially conveys.

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?

States a specific verb and resource ('Propose a transfer between two of the user's accounts') and immediately qualifies the resource with same-currency vs cross-currency behavior, so the agent knows this is an inter-account transfer, not a spend transaction. It does not explicitly name propose_transaction or propose_asset_convert as the alternatives, so sibling differentiation is only implicit.

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 a clear follow-through workflow: get a proposalId, wait for user approval, then call confirm_proposal, with the context note that no UI card exists. It also steers edits into editsProposalId in the schema. It never says when NOT to use this tool versus propose_transaction (e.g., paying a merchant rather than moving money between own accounts).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources