Skip to main content
Glama

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

Present Value

workflow.run_present_value
Read-only

Present value of a future lump sum, a level payment stream, or both: what money received later is worth today at a discount rate. annualRate is a fraction (0.05 = 5%) split into periodsPerYear equal periods the nominal way (rate per period = annualRate / periodsPerYear); years x periodsPerYear is the number of periods, which must be whole when a payment is given. Payments are level and arrive at the end of each period, or at the start with paymentTiming "begin" (annuity due). Money received is positive, money paid is negative. A bond priced at its coupon rate comes back at its face value. For a list of uneven cash flows use workflow.run_npv. Edge cases: annualRate from -1 to 100 as a fraction (0.05 is 5%) with the rate per period above -100%; years 0 to 1000; periodsPerYear a whole number 1 to 365 (default 1); paymentTiming end (default) or begin; when a payment is given, years times periodsPerYear must be a whole number. A result too large to represent is an error. Not covered: a rate that changes over time, uneven payments (use workflow.run_npv), growing payments, inflation, taxes and fees, and a discount rate that fits the risk (you choose it). Use when user asks "what is $10,000 in 5 years worth today at 6%?" or "what is a 20-year stream of $500 monthly payments worth today?". Returns: presentValue, pvOfFutureValue, pvOfPayments, discountFactor, ratePerPeriod, periods, totalPayments, effectiveAnnualRate.

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": {
      "annualRate": "<annualRate>",
      "years": "<years>"
    },
    "name": "workflow.run_present_value"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearsYesLength in years, 0 to 1000 (fractions allowed for a lump sum; with payments years x periodsPerYear must be a whole number)
paymentNoLevel payment per period. Default 0
annualRateYesAnnual discount rate as a fraction (0.06 = 6%); may be zero or negative, but the rate per period must stay above -100%
futureValueNoLump sum received at the end, in any currency. Default 0
paymentTimingNo"end" (ordinary annuity, default) or "begin" (annuity due, each payment one period earlier)
periodsPerYearNoCompounding and payment periods per year, 1 to 365. Default 1 (12 = monthly)

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 establish a safe, read-only, closed-world calculation, and the description adds substantial behavioral detail: nominal rate-per-period conversion, end vs. beginning payment timing, sign convention, whole-period constraints, and error behavior for unrepresentable results.

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 description is front-loaded with the core concept and then covers usage, edge cases, exclusions, and returns in a structured way. It is dense and somewhat repetitive about rate formatting and defaults, but most sentences carry useful selection or invocation information.

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 six-parameter financial calculation with no output schema, the description is complete enough to call correctly: it explains inputs, constraints, timing conventions, exclusions, and the returned fields. The annotations handle the safety profile, and nothing critical appears 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, but the description adds meaningful interpretation beyond the schema: annualRate is split nominally into periodsPerYear equal periods, years times periodsPerYear must be whole when a payment is supplied, and paymentTiming controls ordinary annuity vs. annuity due. Much of this overlaps the schema, which keeps it from a 5.

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 names a specific financial operation and scope: present value of a future lump sum, a level payment stream, or both. It explicitly distinguishes this from workflow.run_npv for uneven cash flows, so an agent can select it confidently over the sibling.

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 explicit use cases with example user questions and names the alternative tool for uneven cash flows. It also states what is not covered, including changing rates, growing payments, inflation, taxes, and risk-based discount rate selection.

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.