Skip to main content
Glama

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

Forex PnL

workflow.run_forex_pnl
Read-only

Profit or loss for a closed or hypothetical forex trade, in pips and in the pair's own quote currency, long or short. Precious-metal pairs (XAU, XAG, XPT, XPD) are refused with an error, because their pip and lot size differ by broker. Edge cases: entryPrice, exitPrice and units above zero; The pair is BASE/QUOTE with two different ISO 4217 currency codes, in any letter case; crypto tickers and precious metals (XAU, XAG, XPT, XPD) are refused. A pip is 0.01 for a pair quoted in JPY and 0.0001 for every other pair, and a standard lot is 100,000 units. The result is in the quote currency; a short position gains when the price falls. Not covered: spread, commission, swap, slippage and account-currency conversion. Use when user asks "what did I make/lose on this trade?" or "what would X pips be worth on Y lots?". Returns: pips (signed, positive favors the position taken), pnlQuote.

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": {
      "pair": "<pair>",
      "side": "<side>",
      "entryPrice": "<entryPrice>",
      "exitPrice": "<exitPrice>",
      "units": "<units>"
    },
    "name": "workflow.run_forex_pnl"
  }
}

Input Schema

NameRequiredDescriptionDefault
pairYesCurrency pair in BASE/QUOTE format, e.g. "EUR/USD"
sideYesTrade direction: "long" or "short"
unitsYesPosition size in base-currency units
exitPriceYesExit price, same quote convention as the entry price
entryPriceYesEntry price in the pair's own quote terms, e.g. 1.0850 for EUR/USD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / entryPrice / description
      Added value: +"Entry price in the pair's own quote terms, e.g. 1.0850 for EUR/USD"
    • addedInput schema / properties / exitPrice / description
      Added value: +"Exit price, same quote convention as the entry price"
    • addedInput schema / properties / side / description
      Added value: +"Trade direction: \"long\" or \"short\""
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavior: refusals with an error plus the reason (broker-dependent pip/lot size), pip size rules (0.01 JPY vs 0.0001 otherwise), standard lot of 100,000 units, and an explicit 'not covered' list of spread, commission, swap, slippage and account-currency conversion. The only gap is that it never states the refusal error shape beyond 'an error'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded and the 'Returns' and 'Not covered' clauses are efficient. However, the precious-metal refusal (XAU, XAG, XPT, XPD) is stated twice in nearly identical wording, and the mid-description 'Edge cases:' fragment is awkwardly punctuated, so trimming is warranted.

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?

With no output schema, the description supplies the return fields (signed pips and pnlQuote) and sign convention, plus input preconditions, domain rules and out-of-scope cost components. Nothing material is missing for an agent to call this correctly on a supported pair.

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 adding validation semantics the schema lacks — entry/exit/units must be above zero, the pair must be BASE/QUOTE with two distinct ISO 4217 codes in any letter case, and entry price is in the pair's own quote terms. It does not explicitly explain what 'units' means vs. lots beyond the 100,000-unit lot definition.

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+resource: profit or loss for a closed or hypothetical forex trade, expressed in pips and in the quote currency, long or short. It also scopes itself against nearby siblings by refusing crypto tickers and precious metals, which separates it from run_crypto_profit and the XAU-style tools.

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?

Provides concrete trigger phrases ("what did I make/lose on this trade?", "what would X pips be worth on Y lots?") and clear exclusion conditions for metals and crypto. It does not name the alternative sibling an agent should switch to when a pair is refused, which keeps it below a 5.

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.