DatoQA

convert_currency_batch

Read-onlyIdempotent

Free pilot: convert dated decimal-string amounts to a target_currency chosen from 30 supported currencies, including EUR (default), USD, JPY, CNY, GBP, CHF, INR and KRW. Use exact-date ECB historical references; derived cross conversions use amount * target units per EUR / source units per EUR without intermediate rounding. Up to 500 rows, eight currency/year snapshots including target rates, 48,000 UTF-8 argument bytes; start small. Unique id per row. Half-even rounding by default, ISO 4217 minor-unit rounding per line: zero decimals for JPY/KRW/ISK, two for other supported targets; target_decimal_places reports precision; total_target sums rounded lines. amount_target is the result; legacy amount_eur/total_eur are null for non-EUR targets. Same-currency rows use identity without an external quote. Preserve originals and evidence for both currencies from the same source edition. Missing, stale or mismatched rates block complete export and total; never replace dates. JSON default; output_format=both includes CSV. ECB originals are free; indicative calculations are not executable prices or accounting/tax certification. No transfers, independent factual verification, customer-content retention or content logging.

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": {
      "rows": "<rows>"
    },
    "name": "convert_currency_batch"
  }
}

Input Schema

Name	Required	Description	Default
`rows`	Yes
`rounding`	No		half_even
`output_format`	No	json keeps the response smaller. both includes the CSV in the same free result; no separate export purchase.	json
`target_currency`	No		EUR

Output Schema

Name	Required	Description	Default
`rows`	Yes
`status`	Yes
`billing`	Yes
`sources`	Yes
`total_eur`	Yes
`blocked_rows`	Yes
`total_target`	Yes
`target_currency`	Yes
`target_decimal_places`	Yes
`complete_artifact_available`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 29, 2026

changedInput schema / properties / target_currency / enum

Previous value: -[
-  "EUR",
-  "USD",
-  "GBP",
-  "CHF",
-  "CAD",
-  "AUD"
-]New value: +[
+  "EUR",
+  "USD",
+  "JPY",
+  "CZK",
+  "DKK",
+  "GBP",
+  "HUF",
+  "PLN",
+  "RON",
+  "SEK",
+  "CHF",
+  "ISK",
+  "NOK",
+  "TRY",
+  "AUD",
+  "BRL",
+  "CAD",
+  "CNY",
+  "HKD",
+  "IDR",
+  "ILS",
+  "INR",
+  "KRW",
+  "MXN",
+  "MYR",
+  "NZD",
+  "PHP",
+  "SGD",
+  "THB",
+  "ZAR"
+]

changedOutput schema / properties / target_currency / enum

Previous value: -[
-  "EUR",
-  "USD",
-  "GBP",
-  "CHF",
-  "CAD",
-  "AUD"
-]New value: +[
+  "EUR",
+  "USD",
+  "JPY",
+  "CZK",
+  "DKK",
+  "GBP",
+  "HUF",
+  "PLN",
+  "RON",
+  "SEK",
+  "CHF",
+  "ISK",
+  "NOK",
+  "TRY",
+  "AUD",
+  "BRL",
+  "CAD",
+  "CNY",
+  "HKD",
+  "IDR",
+  "ILS",
+  "INR",
+  "KRW",
+  "MXN",
+  "MYR",
+  "NZD",
+  "PHP",
+  "SGD",
+  "THB",
+  "ZAR"
+]

addedOutput schema / properties / target_decimal_places

Added value: +{
+  "anyOf": [
+    {
+      "const": 0,
+      "type": "number"
+    },
+    {
+      "const": 2,
+      "type": "number"
+    }
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "status",
-  "target_currency",
-  "rows",
-  "sources",
-  "blocked_rows",
-  "total_eur",
-  "total_target",
-  "complete_artifact_available",
-  "billing"
-]New value: +[
+  "status",
+  "target_currency",
+  "target_decimal_places",
+  "rows",
+  "sources",
+  "blocked_rows",
+  "total_eur",
+  "total_target",
+  "complete_artifact_available",
+  "billing"
+]

Changed5 schema fields changedSep 29, 2026

addedInput schema / properties / target_currency

Added value: +{
+  "default": "EUR",
+  "enum": [
+    "EUR",
+    "USD",
+    "GBP",
+    "CHF",
+    "CAD",
+    "AUD"
+  ],
+  "type": "string"
+}

removedOutput schema / properties / target_currency / const
```
Removed value: -"EUR"
```

addedOutput schema / properties / target_currency / enum

Added value: +[
+  "EUR",
+  "USD",
+  "GBP",
+  "CHF",
+  "CAD",
+  "AUD"
+]

addedOutput schema / properties / total_target

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "status",
-  "target_currency",
-  "rows",
-  "sources",
-  "blocked_rows",
-  "total_eur",
-  "complete_artifact_available",
-  "billing"
-]New value: +[
+  "status",
+  "target_currency",
+  "rows",
+  "sources",
+  "blocked_rows",
+  "total_eur",
+  "total_target",
+  "complete_artifact_available",
+  "billing"
+]

AddedSep 29, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds substantial behavioral depth beyond them: half-even default plus per-currency ISO 4217 minor-unit rounding, no intermediate rounding in cross conversion, same-currency identity without external quote, and stale/missing/mismatched rates blocking export and total. It also discloses hard limits (500 rows, 48,000 argument bytes) and result guarantees.

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 purpose is front-loaded, but the body is a dense, run-on block that mixes rounding, limits, output shape, pricing, and disclaimers without clear grouping. Every sentence carries content, yet the wall-of-text structure makes it hard to parse, so it is only adequately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the complex batch/rounding semantics and low schema coverage, the description covers limits, rounding, output format, error behavior, and source integrity. An output schema exists, yet the description still names key result fields (amount_target, total_target, target_decimal_places), which is helpful rather than strictly required.

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 only 25%, so the description carries weight and delivers: it defines the 30-currency target_currency set with EUR default, explains rounding modes and per-line minor-unit behavior, and clarifies output_format ('json keeps the response smaller', 'both includes the CSV'). It adds real meaning beyond the schema, though the rows item fields (id, date, amount) get only incidental coverage.

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 first sentence states a specific verb and resource: convert dated decimal-string amounts to a target_currency from 30 supported currencies. No sibling (catalog, get_exchange_rates, get_exchange_rate_history, get_evidence, get_record) performs conversion, so the tool's role is unambiguous even without naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied ('start small', 'Preserve originals and evidence', 'never replace dates', 'No transfers'), which gives operational posture but not selection guidance. It never states when to choose this over get_exchange_rates or get_exchange_rate_history for raw rate lookups, leaving the routing to inference.

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

All DatoQA 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.

Resources

Need Help?