Forever Works MCP servers

Convert to or from RON

convert

Read-onlyIdempotent

Calculate amounts from or to RON using BNR reference rates with exact single rounding and selectable rate rules for invoices or payments.

Instructions

An amount converted to or from RON at BNR's reference rate, computed exactly and rounded once: to RON is amount x rate / multiplier, from RON amount x multiplier / rate. rate_rule picks the fixing: in_force (the day's, or the last banking day's before it, as rate answers) or last_before (the last one strictly before the day, the rule for an invoice in a foreign currency). Answers the result with the rate, its multiplier and the date BNR published it, so the conversion can be stated. One side must be RON; for two other currencies, convert twice.

Input Schema

Name	Required	Description	Default
`to`	Yes	The currency wanted: RON, or the currency to convert RON to. ISO 4217; case ignored.
`date`	No	The day of the conversion, YYYY-MM-DD in Bucharest (an invoice's date, a payment's); default today.
`from`	Yes	The amount's currency: RON, or the currency to convert to RON. ISO 4217; case ignored.
`amount`	Yes	The amount, as a decimal string: "1250.50", "-75". Never a number.
`places`	No	Digits after the point in the result.
`rounding`	No	How the result is rounded, once: half-up (halves away from zero, as invoices round) or half-even (banker's).	half-up
`rate_rule`	No	in_force: the rate in force on the day; last_before: the last rate published before the day.	in_force

Output Schema

Name	Required	Description
`ok`	Yes
`to`	Yes
`date`	Yes
`from`	Yes
`note`	No
`rate`	Yes	BNR's exact text, RON per `multiplier` units
`amount`	Yes	The amount converted, as given
`places`	Yes
`result`	Yes	The converted amount, computed exactly and rounded once
`source`	Yes
`meaning`	Yes
`rounding`	Yes
`rate_rule`	Yes
`multiplier`	Yes
`published_on`	Yes	The date of the fixing the conversion used

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond readOnlyHint/idempotentHint it discloses that rounding happens exactly once and that the response carries the rate, its multiplier and the publication date, so the conversion is auditable. The one-side-must-be-RON constraint is a behavioral rule no annotation conveys. It does not discuss rate-availability failures or how dates without a published fixing are handled.

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?

Front-loads the purpose and the formulas, then the rule selection, then the return shape. Dense but every clause carries information; the parenthetical about `rate` answers could be trimmed slightly.

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 7-parameter conversion tool with an output schema, the definition still covers the formula, direction constraint, both enum behaviors and the returned provenance fields. Nothing an agent needs to call it correctly 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 baseline is 3, and the description earns above that by introducing the 'multiplier' factor that appears nowhere in the schema and by spelling out the direction-dependent formulas showing how amount, rate and multiplier combine.

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 ('An amount converted to or from RON at BNR's reference rate') plus the exact computation, which clearly separates it from the sibling tools rate, rates and annual_average that only surface fixings.

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?

Gives concrete when-to-use routing for the rate_rule choice: in_force for the day's rate as `rate` answers it, last_before 'the rule for an invoice in a foreign currency'. Also states the hard precondition that one side must be RON and that other pairs require two calls. It stops short of naming a sibling to use instead when only a quoted rate is wanted.

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

This server cannot be deployed