Skip to main content
Glama

TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures

Spot DCA

workflow.run_spot_dca
Read-only

Dollar-cost averaging on a spot coin: the same cash amount bought at each of a list of prices (no leverage, no funding). Returns the coins held, total invested, the average price paid (below the plain average of the prices, because equal cash buys more coins when the price is low), the average cost per coin with the buy fee in it, the break-even sell price and, when currentPrice is given, the value, profit and ROI of selling everything there after the sell fee. amountPerBuy is the cash that leaves the account for one buy, buy fee included. Each fee is a fraction of that fill's trade value (0.001 = 0.1%, at most 0.05). Prices may be in any currency; results are in the same one. The average price is the harmonic mean of the prices; break-even = averageCostPerCoin / (1 - sellFee). Edge cases: 1 to 1000 prices; every price and amountPerBuy must be above zero; a list of one buy is valid; a non-finite result (huge or tiny inputs) is an error; without currentPrice no profit, ROI or proceeds are returned. Not covered: taxes, FIFO/LIFO lots, slippage, withdrawal or network fees, currency conversion, leverage and funding. For buys of unequal size or with sells in between use workflow.run_average_buy_price; for DCA on a perpetual futures position use workflow.run_dca_entry. Use when user asks "I buy $100 of BTC every week at these prices, what is my average and where am I now?". Returns: buys, totalInvested, totalQuantity, averageBuyPrice, averageCostPerCoin, simpleAveragePrice, lowestPrice, highestPrice, totalBuyFees, breakevenSellPrice, and (with currentPrice) currentValue, sellFee, proceeds, profit, roiPct (a fraction).

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": {
      "prices": "<prices>",
      "amountPerBuy": "<amountPerBuy>"
    },
    "name": "workflow.run_spot_dca"
  }
}

Input Schema

NameRequiredDescriptionDefault
pricesYesPrice paid per coin at each buy, in order (1 to 1000 positive numbers, e.g. [60000, 52000, 48000])
buyFeePctNoBuy fee as a fraction of the trade value, 0 to 0.05 (0.001 = 0.1%). Default 0
sellFeePctNoSell fee for the exit, as a fraction of the trade value, 0 to 0.05. Default 0
amountPerBuyYesCash spent on each buy, buy fee included (e.g. 100)
currentPriceNoOptional: the price to value the whole position at, same currency as prices

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description still adds real substance: fee mechanics (each fee is a fraction of that fill's trade value, capped at 0.05), currency inheritance ('results are in the same one'), and concrete failure modes (non-finite results from huge or tiny inputs are an error; every price and amountPerBuy must exceed zero; 1-1000 prices; a single buy is valid). It also states precisely what is omitted when currentPrice is absent, which is the kind of conditional behavior annotations cannot express.

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?

Purpose is front-loaded and the closing sentence enumerates return fields, which is necessary since there is no output schema. It is a dense single block, though — the formula notes, edge cases and the returns list run together, and the parenthetical explaining why the harmonic average sits below the plain average is explanatory color rather than decision-relevant.

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 a read-only calculator with no output schema, the definition is complete: it spells out the input constraints, fee semantics, currency behavior, the full return field list including the roiPct-is-a-fraction caveat, and the conditional outputs gated on currentPrice. Nothing an agent needs to call it or interpret the result is missing.

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; the description earns above baseline by clarifying that amountPerBuy is the cash leaving the account with the buy fee already inside it (which determines whether the fee is charged on top or deducted), that prices may be in any currency with outputs in that same currency, and that sellFeePct feeds the break-even formula. It does not add much about currentPrice beyond the schema's own text.

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?

The first clause names the exact computation (equal cash amounts bought at a list of prices on a spot coin) and immediately bounds it with 'no leverage, no funding'. It then names the two siblings it is not — run_average_buy_price for unequal buys/sells, run_dca_entry for perpetuals — so an agent can route without opening any schema.

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?

Explicit when-to-use ('I buy $100 of BTC every week at these prices'), explicit when-not-to-use with named alternatives for both the unequal-size case and the futures case, plus a 'Not covered' list (taxes, FIFO/LIFO, slippage, withdrawal/network fees, FX conversion, leverage, funding) that closes off realistic misuses.

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.