Skip to main content
Glama

Hundo

propose_asset_trade

Propose a buy or sell trade for an asset. 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). To buy an asset the user does not hold yet, pass newAsset instead of assetId: confirming creates the asset and records the buy together. For sells, validates the user holds enough quantity. The cash account currency must match priceCurrency. Always include a short user-supplied description; optionally include a categoryId.

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": {
      "action": "<action>",
      "quantity": "<quantity>",
      "pricePerUnit": "<pricePerUnit>",
      "priceCurrency": "<priceCurrency>",
      "date": "<date>",
      "description": "<description>"
    },
    "name": "propose_asset_trade"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesYYYY-MM-DD.
feesNoTransaction fees in MAJOR units (e.g. 1.99 for $1.99, 5000 for Rp 5,000). Pass 0 if none.
actionYes
assetIdNoId of the asset being traded, from getAssets. Omit it only for a buy of an asset the user does not hold yet, and pass newAsset instead.
newAssetNoPass this INSTEAD of an asset id, only when getAssets shows the user does not hold the asset yet. Confirming the proposal creates the asset and records the trade together.
quantityYesNumber of units to buy or sell.
categoryIdNoOptional category id to attach to the cash transaction.
descriptionYesShort description taken from the user's message, e.g. 'DCA into AAPL'.
pricePerUnitYesPer-unit price in MAJOR units (the displayed amount, e.g. 180.25 for $180.25, 3123.98 for Rp 3,123.98). Fractional values are allowed (e.g. 0.000001 for high-supply crypto). The server scales to storage units; never pre-multiply by 100.
cashAccountIdNoId of the cash account funding or receiving this trade. Omit only in the email-import pipeline when the source email doesn't make it clear which cash account is involved - 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.
priceCurrencyYes3-letter currency code for the trade price.
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. 'DCA into AAPL'."New value: +"Short description taken from the user's message, e.g. 'DCA into AAPL'."
  2. Changed4 schema fields changed
    • changedInput schema / properties / assetId / description
      Previous value: -"Id of the asset being traded."New value: +"Id of the asset being traded, from getAssets. Omit it only for a buy of an asset the user does not hold yet, and pass newAsset instead."
    • addedInput schema / properties / assetId / minLength
      Added value: +1
    • addedInput schema / properties / newAsset
      Added value: +{
      +  "description": "Pass this INSTEAD of an asset id, only when getAssets shows the user does not hold the asset yet. Confirming the proposal creates the asset and records the trade together.",
      +  "properties": {
      +    "symbol": {
      +      "description": "For crypto and stock: the ticker, e.g. \"SOL\" or \"AAPL\" (use the exchange suffix for a non-US listing, e.g. \"BBCA.JK\"). For commodity: \"gold\", \"silver\", \"platinum\" or \"palladium\". For every other type: a short name the user will recognize, e.g. \"Honda Civic 2021\".",
      +      "maxLength": 100,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "type": {
      +      "description": "crypto, stock (shares, ETFs and funds), commodity (gold, silver, platinum, palladium), real_estate, vehicle, bond or other.",
      +      "enum": [
      +        "crypto",
      +        "stock",
      +        "commodity",
      +        "real_estate",
      +        "vehicle",
      +        "bond",
      +        "other"
      +      ],
      +      "type": "string"
      +    },
      +    "unit": {
      +      "description": "Commodity only, and then required: the unit the quantity is in - toz (troy ounce), g or kg. The price per unit must be in the same unit.",
      +      "enum": [
      +        "toz",
      +        "g",
      +        "kg"
      +      ],
      +      "type": "string"
      +    },
      +    "valuationMode": {
      +      "description": "Omit it. \"auto\" (the default for crypto, stock and commodity) follows the market price. Pass \"manual\" only when the user says the asset has no market price, e.g. shares in a private company; its value is then the price paid until the user updates it.",
      +      "enum": [
      +        "auto",
      +        "manual"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "type",
      +    "symbol"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "action",
      -  "assetId",
      -  "quantity",
      -  "pricePerUnit",
      -  "priceCurrency",
      -  "date",
      -  "description"
      -]New value: +[
      +  "action",
      +  "quantity",
      +  "pricePerUnit",
      +  "priceCurrency",
      +  "date",
      +  "description"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / cashAccountId / description
      Previous value: -"Id of the cash account funding or receiving this trade. Omit only in the email-import pipeline when the source email doesn't make it clear which cash account is involved — 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 cash account funding or receiving this trade. Omit only in the email-import pipeline when the source email doesn't make it clear which cash account is involved - 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.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=false; the description adds real behavioral context beyond that: nothing is persisted until confirmation, confirming a newAsset creates the asset and the trade together, sells validate sufficient quantity, and cash account currency must match priceCurrency. It does not cover validation failure behavior or what the proposal contents look like, so it falls short of a 5.

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 confirm step, then conditional guidance in order of importance. The final MCP note restates the pending-proposal point already made in the first sentence, which is a minor redundancy but a deliberate safety reminder.

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 a 12-parameter mutation tool with no output schema, the description covers the critical multi-step workflow, the two asset-identification paths, validation constraints, and the required description field. It omits expected failure modes and output details beyond the proposalId, but the schema carries the rest at 92% coverage.

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

Parameters5/5

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

With 92% schema coverage the baseline is 3, but the description adds decision-level meaning: newAsset vs assetId selection, and always including a short user-supplied description with optional categoryId. It reinforces constraints (currency match, sell quantity validation) that the schema alone cannot express as conditions.

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 buy or sell trade for an asset") and immediately scopes it: it only creates a pending proposal, nothing is recorded until confirm_proposal is called. That distinguishes it cleanly from confirm_proposal, propose_transaction, and propose_asset_convert.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: call confirm_proposal with the returned proposalId after user approval, and notes there is no UI button in this context. It also names alternatives by condition (use newAsset instead of assetId for buys of unheld assets, editsProposalId for modifications), which is exactly the when-to-use guidance an agent needs.

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