Skip to main content
Glama

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

Apy Apr Converter

workflow.run_apy_apr_converter
Read-only

Convert an APR (nominal yearly rate) to an APY (effective yearly rate) or back, for a compounding you choose. APY = (1 + APR / m)^m - 1 for m periods a year, e^APR - 1 when continuous. The same APY is a different APR at every compounding frequency, so the frequency is required: give periodsPerYear (365 daily, 12 monthly) or continuous true, not both. Rates are fractions (0.12 = 12%). It converts rate arithmetic only: it does not include fees, token price moves or the risk that a pool rate changes. Edge cases: rate a fraction from -periodsPerYear (APR) or above -1 (APY) up to 1000; give periodsPerYear (1 to 365) or continuous true, never both and never neither; the rate per period must stay above -100%; a continuous APR above 709 (70,900%) is an error. Not covered: fees, token price moves, a pool rate that changes, taxes, and compounding that is not regular. Use when user asks "what APR is an 8% APY compounded daily?" or "what is 12% APR monthly as an APY?". Returns: apr, apy, periodsPerYear, continuous, ratePerPeriod, apyMinusApr, byCompounding (the same APY as an APR at annual, semiannual, quarterly, monthly, weekly, daily and continuous compounding).

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": {
      "direction": "<direction>",
      "rate": "<rate>"
    },
    "name": "workflow.run_apy_apr_converter"
  }
}

Input Schema

NameRequiredDescriptionDefault
rateYesThe rate you have, as a fraction per year (0.12 = 12%), up to 1000. An APY must be above -1; an APR must satisfy APR / periodsPerYear above -1
directionYesapr_to_apy converts the given APR into an APY; apy_to_apr the reverse
continuousNoTrue for continuous compounding; then omit periodsPerYear
periodsPerYearNoCompounding periods a year, 1 to 365 (12 monthly, 365 daily). Omit when continuous is true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish this is a safe, closed-world read, so the description focuses on value-add behavior: the required compounding parameter, the mutual-exclusivity rule for periodsPerYear vs continuous, the fraction convention (0.12 = 12%), and specific error boundaries (rate per period > -100%, continuous APR > 709). That is far more than the readOnlyHint/destructiveHint pair conveys.

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?

Front-loaded and logically ordered (definition, formula, constraints, edge cases, exclusions, examples, returns), but it repeats itself: the 'does not include fees, token price moves, ... pool rate changes' sentence is essentially restated in the 'Not covered:' list, and the rate bounds appear twice. Trimming the duplication would lose nothing.

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?

There is no output schema, and the description compensates by enumerating the return fields (apr, apy, periodsPerYear, continuous, ratePerPeriod, apyMinusApr, byCompounding). Combined with the edge cases and error conditions, an agent has everything needed to call this correctly and interpret the result without guessing.

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 schema already documents direction, rate, continuous and periodsPerYear ranges; the description mostly restates these. It does add genuine meaning the schema only implies: that periodsPerYear and continuous must never both be supplied and never both omitted, and the numeric error thresholds for each direction.

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 ('Convert an APR ... to an APY or back') and immediately bounds the scope with the exact formulas used, including the continuous case. The exclusion clause ('it converts rate arithmetic only: it does not include fees, token price moves...') separates it from the wealth of neighboring run_* analytics tools that mix rates with PnL or risk.

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?

Gives two concrete triggering utterances ('what APR is an 8% APY compounded daily?') plus an explicit when-not list ('Not covered: fees, token price moves, a pool rate that changes, taxes, and compounding that is not regular'). The only shortfall is that no sibling tool is named as the alternative for the out-of-scope cases, but the trigger conditions are unambiguous.

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.