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

Average Buy Price

workflow.run_average_buy_price

Read-only

Real entry price of a spot coin bought and sold in several trades: moving average cost, trades in the order they happened, each with its own fee (no leverage, no funding). The buy fee is part of the cost basis; a sale removes coins at the current average and never changes the average of what is left, only a later buy does; selling everything resets it. Selling more than is held at that point is an error naming the trade. Each fee is a fraction of that trade's value (0.001 = 0.1%, at most 0.05). Edge cases: 1 to 1000 trades; price and quantity above zero; a sale before any buy, or above the holding, is an error; a sale within 1e-12 of the largest holding since the position was last flat counts as selling everything (float noise) and leaves exactly zero, never a residual; when nothing is held the average, before-fee average and break-even are null and costBasis is 0; realizedProfit can be negative. Not covered: taxes, FIFO/LIFO lots (moving average cost only), slippage, withdrawal or network fees, currency conversion, leverage and funding. Prices may be in any currency; results are in the same one. sellFeePct is the fee expected when the remaining coins are sold, used for the break-even sell price. For equal cash buys at a list of prices use workflow.run_spot_dca; for the average entry of a perpetual futures position use primitive.average_entry. Use when user asks "I bought and sold this coin several times, what is my average buy price and break-even now?". Returns: remainingQuantity, averageBuyPrice (fees in) and averageBuyPriceBeforeFees (null when nothing is held), costBasis, totalBought, totalSold, totalInvested, totalSellProceeds, realizedProfit, totalFees, breakevenSellPrice (null when nothing is held).

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": {
      "trades": "<trades>"
    },
    "name": "workflow.run_average_buy_price"
  }
}

Input Schema

Name	Required	Description	Default
`trades`	Yes	Trades in the order they happened (1 to 1000)
`sellFeePct`	No	Fee expected when the remaining coins are sold, 0 to 0.05, for the break-even sell price. Default 0

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. Beyond that, the description explains moving-average sale handling, fee treatment, float-noise tolerance near full liquidation, null outputs when flat, negative realizedProfit, and named validation errors, which is unusually rich behavioral context with no contradictions.

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?

The content is front-loaded and most sentences carry necessary semantics for a multi-trade cost-basis calculation. It is a dense paragraph with some repetition of schema constraints (fee cap, 1–1000 trades, positive price/quantity) and duplicated error cases, so bullet formatting would improve scanability.

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 computational tool with no output schema, the description explicitly lists the return fields and their null behavior when nothing is held. It also covers edge cases, error naming, scope exclusions, and currency handling, leaving an agent with enough information to call and interpret it 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 description coverage is 100%, so the schema already documents trades, feePct, and sellFeePct. The description adds useful meaning by explaining that buy fees are part of cost basis, that each fee is a fraction of trade value, and specifically that sellFeePct is the expected exit fee used for breakevenSellPrice.

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 description states exactly what is computed: the real entry price of a spot coin under moving-average cost across ordered trades, with fees included in cost basis. It explicitly distinguishes the tool from workflow.run_spot_dca (equal cash buys) and primitive.average_entry (perpetual futures), so an agent can tell what this tool is and is not for.

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?

It gives a direct trigger phrase ("I bought and sold this coin several times, what is my average buy price and break-even now?") and names the alternatives for adjacent cases. The "Not covered" list and detailed error conditions further clarify when this tool is and is not appropriate.

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

All TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures 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.