Convert dated amounts to a supported target currency with traceable ECB reference rates, or retrieve recent and historical EUR reference exchange rates since 1999. Exact source dates, original decimals, citations and explicit gaps.
New practical task: convert_currency_batch accepts rows with a unique id, date, currency and decimal-string amount. It preserves original amounts, source rate decimals and evidence, applies an explicit rounding rule and returns a line-by-line result. Missing, stale or mismatched rates block the complete CSV and total. A weekend date is never silently replaced by a previous working day.
Try: convert 125.50 USD dated 2025-09-26 to EUR and explain the rate and rounding. Up to 500 rows, 48,000 UTF-8 argument bytes and eight currency/year snapshots per call. Start small. JSON is the default; output_format=both adds CSV in the same free result. EUR rows use identity, not an external rate. DatoQA processes supplied rows in memory without retaining their content; your client or gateway may keep its own logs.
Existing tools still provide exact-date/year history and latest references. Source availability varies by currency and year; no forward filling or interpolation. Original ECB data is free. References and derived conversions are indicative, not live executable prices, transfers or accounting/tax certification. Source/schema checks are not independent factual verification.
7 focused MCP tools. Free during the pilot; no account, API key or wallet required. Same DatoQA source snapshots as the general server; public pilot without an SLA.
Setup, examples and limits: https://datoqa.bhazarstudio.workers.dev/docs/fx/
Datoka portal and connection guide: https://datoka.dev/qa.
Scored across 7 tools
Most tools target clearly distinct operations: catalog, batch conversion, evidence lookup, record lookup, rate listing, and rate retrieval. However, get_exchange_rates and get_exchange_rate_history are close in name and both return ECB rates against EUR, so an agent could misselect despite clarifying descriptions.
Names are consistently snake_case and mostly follow a verb_noun pattern (get_*, list_*, convert_*). The noun-only 'catalog' is a minor outlier, and the get_exchange_rates/get_exchange_rate_history singular-plural variation slightly weakens predictability.
Seven tools is well-scoped for a historical exchange-rate and provenance server. Each tool appears to earn its place: rate lookup, historical lookup, currency listing, conversion, evidence, record retrieval, and connection catalog.
The surface covers core needs: current and historical rates, available currencies/gaps, batch conversion, evidence, records, and connection inspection. Minor gaps exist, such as no MCP-native purchase path and no obvious multi-currency historical retrieval beyond conversion, but these are workable or intentionally external.
Inspect this connection’s scope, tools and access policy. With no arguments returns the usual catalog. On the general or economy connection, optionally supply report_countries (1–10 World Bank codes) for a FREE live preview of the optional paid country comparison: population/GDP/inflation by default, or up to six selected historical indicators over ten years, aligned JSON and CSV, definitions and source evidence. Preview reports price, missing cells, availability and the exact HTTP purchase path; it never signs or pays. Existing data tools remain free. Buying requires an authorized x402 HTTP client, not just MCP. Source/schema checks are not independent factual verification.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response metadata language, English by default or French; original source definitions and notes remain preserved. | en |
| report_to | No | Inclusive last observation year, no later than the last completed calendar year. Supply with report_from and report_indicators; missing observations block purchase. | |
| report_from | No | Inclusive first observation year for a custom country preview. Supply with report_to and report_indicators; at most ten years, from 1960 onward. | |
| report_countries | No | Optional free preview for these distinct World Bank country codes, e.g. FRA, DEU, ESP. General/economy connections only. | |
| report_indicators | No | Custom historical comparison: select up to six of the 22 WDI indicators. Supply report_from and report_to together, up to ten years. Missing cells block payment. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| title | No | |
| tools | No | |
| profile | No | |
| version | No | |
| capabilities | No | |
| available_records | No | |
| independently_verified | No | Official-source checks are not independent factual corroboration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, and the description layers on real behavioral context the structured fields can't convey: the preview 'never signs or pays,' missing cells block purchase, reports expose price/availability/HTTP purchase path, and source/schema checks are not independent factual verification. This is valuable disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and keeps every sentence informative, but the second half is a dense run-on covering preview outputs, pricing, purchase path, and caveats. Slightly crowded, yet nothing is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unusual dual-purpose tool (catalog inspection plus paid-data preview) with an output schema already covering return values, the description supplies the needed context: scope, the free-vs-paid boundary, preview contents, payment prerequisites, and an analytical caveat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 cross-parameter semantics the schema doesn't: report_from/report_to must be supplied together with report_indicators, missing observations block purchase, and report_countries triggers a free preview only on general/economy connections. That is meaningful added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('Inspect this connection's scope, tools and access policy') and adds a second, clearly described capability (free country-comparison preview). It implies differentiation from the data siblings by noting 'Existing data tools remain free,' but never names a sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use guidance: call with no arguments for the plain catalog, or supply report_countries on the general/economy connection for a preview, and explicitly states buying needs an authorized x402 HTTP client 'not just MCP.' No explicit when-NOT-to-use beyond that constraint, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Retrieve the source JSON snapshot and SHA-256 digest for a currently available record. The digest proves snapshot integrity, not factual truth.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Record id returned by a DatoQA data response; returns the retained source snapshot for that record. |
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| sha256 | Yes | |
| record_id | Yes | |
| hash_scope | Yes | |
| source_url | Yes | |
| first_observed_at | Yes | |
| source_payload_json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious context the annotations cannot: the digest proves snapshot integrity and not factual truth, and the snapshot is only available for a record that is currently available. That constraint on availability is useful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, and the most important scoping fact (snapshot plus digest for an available record) is front-loaded before the integrity caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be explained; the description nonetheless names the returned artifacts (snapshot, digest). The main remaining omission is what the caller should do when the record is no longer available, but for a one-parameter read tool with rich annotations and an output schema this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single id parameter is already documented in the schema (record id from a DatoQA data response, including the accepted pattern). The description adds no format or sourcing detail beyond that, so the baseline 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource pair: retrieve the source JSON snapshot plus its SHA-256 digest for a record. It is meaningfully distinguishable from the sibling get_record (this returns provenance/evidence, not the record payload), but it never names that sibling, so the differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement and no alternative is named; an agent must infer from the word 'evidence' and 'currently available' that this is the provenance/verification path rather than the normal data-retrieval path. Relative to get_record, which presumably serves the same record space, this is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ECB historical daily reference rates for one currency against EUR. Provide year (1999 onward) or an exact date, not both. Default: current year. Returns one year at most, original decimals, missing values and evidence. No weekend carry-forward, interpolation, current quote for discontinued currencies, cross rates or executable prices.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Exact source date YYYY-MM-DD, for example 2008-09-15; cannot be combined with year. No filling of weekends or gaps. | |
| year | No | One source calendar year since 1999; defaults to the current year. Cannot be combined with date. | |
| format | No | CSV content with null flags, original values, source notes and provenance, alongside JSON. No missing-date filling. | json |
| currency | Yes | Uppercase non-EUR currency code from list_exchange_rate_history, for example USD. Values are currency units per one EUR. |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| items | Yes | |
| notice | No | |
| status | Yes | Read this before using values; a successful transport does not establish data availability. |
| currency | Yes | |
| returned | Yes | Domain-specific result count, not necessarily the number of stored records in items. |
| directory | No | |
| interpretation | No | |
| requested_date | Yes | |
| independently_verified | No | Official-source checks are not independent factual corroboration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, and the description adds substantial data-behavior context: no weekend carry-forward, no interpolation, missing values surfaced, original decimals, one year max, no executable prices. These quirks materially affect how an agent should interpret results, though they describe data rather than invocation mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and the trailing negation list is dense but information-bearing. Slightly run-on, but no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% schema description coverage, the description need not explain return values, yet it still adds the interpretive caveats (missing values, evidence, no filling). Adequate for a 4-parameter lookup; only the lack of alternative routing keeps it from 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters (including format) are already documented at field level. The description usefully consolidates the year/date mutual exclusivity and the 1999 floor, but this largely repeats what the schema descriptions already state. Baseline 3 fits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('ECB historical daily reference rates for one currency against EUR') with clear scope: one currency, quoted per EUR. The 'current quote' exclusion implicitly separates it from a live-rate sibling, but no sibling is named outright, so it stops short of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives operational constraints (provide year OR date, not both; default current year) but never says when to choose this tool over get_exchange_rates or the list_* siblings. The 'no current quote / no cross rates' notes imply alternatives exist but do not route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ECB indicative daily currency reference rates against EUR. Not real-time or executable prices; inspect observation_date. Original rates freely available at the cited ECB source.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Optional uppercase currency code, for example USD; omit for all available ECB reference currencies. Values are currency units per one EUR. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| notice | No | |
| status | Yes | Read this before using values; a successful transport does not establish data availability. |
| returned | Yes | Domain-specific result count, not necessarily the number of stored records in items. |
| directory | No | |
| selected_rate | No | |
| available_currencies | No | |
| independently_verified | No | Official-source checks are not independent factual corroboration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds meaningful context: rates are indicative daily ECB reference rates, not real-time or executable, and observation_date should be checked. It also notes the original source availability, which is useful for provenance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the essential resource definition, then quickly adds the critical caveat and observation_date guidance. Every clause contributes useful information with no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with one optional parameter, full schema coverage, annotations covering safety, and an output schema, the description is complete enough. It states the data nature, usage caveats, and source provenance without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the sole optional currency parameter is fully documented in the schema, including format and unit meaning. The description adds no parameter-specific syntax or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and scope: 'ECB indicative daily currency reference rates against EUR.' It distinguishes this from real-time or executable prices, but does not explicitly differentiate from the closely named sibling get_exchange_rate_history beyond the word 'daily.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context and explicit exclusions: rates are not real-time or executable, and the agent should inspect observation_date. It does not name alternative tools such as get_exchange_rate_history for historical queries, so it stops short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an unexpired record with provenance and its explicit verification level. Source/schema validation is not independent factual verification.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Opaque record id returned by a DatoQA data response. Reuse it exactly; do not invent an id. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| data | Yes | Source-specific payload; inspect units, observation dates, nulls and source notes. |
| domain | Yes | |
| citation | Yes | |
| freshness | Yes | |
| provenance | Yes | |
| display_label | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds two genuinely useful behavioral facts not in the annotations: records returned are unexpired, and source/schema validation must not be mistaken for independent factual verification. It stops short of describing error behavior for a missing/expired id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, the primary purpose front-loaded, with the interpretive caveat placed second. No filler, no restating of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and annotations cover the safety profile. The gap is routing: with 24 siblings an agent is given no cue for choosing this tool, and nothing is said about what happens when the record is expired or absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is exactly one parameter and schema_description_coverage is 100%; the schema already explains the id is opaque, must be reused exactly, and must not be invented. The description adds no parameter guidance at all, so the baseline 3 for fully-covered schemas applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get an unexpired record') plus the returned payload ('provenance and its explicit verification level'). The 'unexpired' qualifier meaningfully narrows scope beyond the bare tool name, though it never distinguishes itself from any of the 24 sibling get_*/list_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus the sibling retrieval tools (get_evidence, catalog, etc.), nor any prerequisite or exclusion. Usage is only implied by the required id parameter. The closing caveat is about interpreting results, not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available currencies, annual snapshots since 1999 and explicit gaps in ECB daily reference FX history. Some currencies have been discontinued. Units per EUR; original data freely available at ECB.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| years | Yes | |
| source | Yes | |
| refresh | Yes | |
| endpoint | Yes | |
| frequency | Yes | |
| currencies | Yes | |
| base_currency | Yes | |
| numeric_values | Yes | |
| original_data_free | Yes | |
| independently_verified | Yes | Official-source checks are not independent factual corroboration. |
| missing_or_expired_years | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond that: currency discontinuations, the 'units per EUR' convention, and ECB as the data source with a 1999 start, which an agent needs to interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource being listed, followed by scope boundaries and a short provenance note. Two sentences plus a fragment; the ECB attribution is marginally useful and does not bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. The description supplies the coverage boundaries (since 1999, gaps, discontinued currencies) an agent needs to decide whether this listing answers its question. Only the routing to sibling tools is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description cannot and need not document inputs, and the schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and precisely what is enumerated: available currencies, annual snapshots since 1999, and explicit gaps in ECB daily FX history. It is distinguishable from the sibling get_exchange_rate_history by verb and by the fact that it returns coverage/catalog information rather than rates, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope of what is listed implies a discovery/coverage-checking use case, but there is no statement of when to call this instead of get_exchange_rate_history or get_exchange_rates, and no prerequisites. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
catalog3 fields changedInput schema / properties / language / descriptionAdded value: +"Response metadata language, English by default or French; original source definitions and notes remain preserved."Input schema / properties / report_from / descriptionAdded value: +"Inclusive first observation year for a custom country preview. Supply with report_to and report_indicators; at most ten years, from 1960 onward."Input schema / properties / report_to / descriptionAdded value: +"Inclusive last observation year, no later than the last completed calendar year. Supply with report_from and report_indicators; missing observations block purchase."convert_currency_batch4 fields changedInput schema / properties / target_currency / enumPrevious 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"
+]Output schema / properties / target_currency / enumPrevious 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"
+]Output schema / properties / target_decimal_placesAdded value: +{
+ "anyOf": [
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+}Output schema / requiredPrevious 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"
+]convert_currency_batch5 fields changedInput schema / properties / target_currencyAdded value: +{
+ "default": "EUR",
+ "enum": [
+ "EUR",
+ "USD",
+ "GBP",
+ "CHF",
+ "CAD",
+ "AUD"
+ ],
+ "type": "string"
+}Output schema / properties / target_currency / constRemoved value: -"EUR"Output schema / properties / target_currency / enumAdded value: +[
+ "EUR",
+ "USD",
+ "GBP",
+ "CHF",
+ "CAD",
+ "AUD"
+]Output schema / properties / total_targetAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / requiredPrevious 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"
+]convert_currency_batchget_exchange_rate_history1 field changedInput schema / properties / formatAdded value: +{
+ "default": "json",
+ "description": "CSV content with null flags, original values, source notes and provenance, alongside JSON. No missing-date filling.",
+ "enum": [
+ "json",
+ "csv"
+ ],
+ "type": "string"
+}catalog3 fields changedInput schema / properties / report_fromAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": 1960,
+ "type": "integer"
+}Input schema / properties / report_indicatorsAdded value: +{
+ "description": "Custom historical comparison: select up to six of the 22 WDI indicators. Supply report_from and report_to together, up to ten years. Missing cells block payment.",
+ "items": {
+ "enum": [
+ "population",
+ "gdp",
+ "gdp_per_capita",
+ "gdp_real",
+ "gdp_growth",
+ "inflation",
+ "life_expectancy",
+ "fertility",
+ "urban_population",
+ "internet_users",
+ "electricity_access",
+ "unemployment",
+ "renewable_energy",
+ "forest_area",
+ "agricultural_land",
+ "trade",
+ "exports",
+ "imports",
+ "infant_mortality",
+ "basic_drinking_water",
+ "basic_sanitation",
+ "primary_completion"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / report_toAdded value: +{
+ "maximum": 2025,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}catalog3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / languageAdded value: +{
+ "default": "en",
+ "enum": [
+ "en",
+ "fr"
+ ],
+ "type": "string"
+}Input schema / properties / report_countriesAdded value: +{
+ "description": "Optional free preview for these distinct World Bank country codes, e.g. FRA, DEU, ESP. General/economy connections only.",
+ "items": {
+ "pattern": "^[A-Z0-9]{3}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+}catalog1 field changedOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_evidence2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_exchange_rate_history2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_exchange_rates2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_record2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_exchange_rate_history1 field changedOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_exchange_rate_history1 field changedOutput schema / properties / items / items / properties / provenance / properties / verification_level / enumPrevious value: -[
- "official_source_and_schema_checked",
- "method_specific"
-]New value: +[
+ "official_source_and_schema_checked",
+ "public_aggregator_and_schema_checked",
+ "method_specific"
+]get_exchange_rates1 field changedOutput schema / properties / items / items / properties / provenance / properties / verification_level / enumPrevious value: -[
- "official_source_and_schema_checked",
- "method_specific"
-]New value: +[
+ "official_source_and_schema_checked",
+ "public_aggregator_and_schema_checked",
+ "method_specific"
+]get_record1 field changedOutput schema / properties / provenance / properties / verification_level / enumPrevious value: -[
- "official_source_and_schema_checked",
- "method_specific"
-]New value: +[
+ "official_source_and_schema_checked",
+ "public_aggregator_and_schema_checked",
+ "method_specific"
+]catalogget_evidenceget_exchange_rate_historyget_exchange_ratesget_recordlist_exchange_rate_historyValidate CSV/JSON tables and convert dated amounts to EUR, alongside sourced historical exchange rates, country economic indicators and international public-holiday calendars. Free MCP pilot; no account, API key or wallet required for these tools. Practical tasks: - validate_table: check explicit column types, required values, date/decimal formats, allowed values and duplicate keys. Preserve original rows and explain requested normalization. No row deletion, guessed dates or independent verification of the contents. - convert_currency_batch: convert decimal-string amounts to EUR using exact-date ECB historical references, with explicit rounding, original amounts and source evidence. A missing, stale or mismatched rate blocks the complete export and total; no silent replacement by another date. Try: validate a table of invoice references, amounts and dates; or convert 125.50 USD dated 2025-09-26 to EUR and explain the source rate and rounding. Start with a small batch. Maximum 500 rows and 48,000 UTF-8 argument bytes; tables allow 20 columns and conversions eight currency/year snapshots. JSON by default; output_format=both adds CSV in the same free result when complete. DatoQA processes supplied rows in memory and does not retain their content. Your client or gateway may keep its own logs. Existing data tools remain available. Holiday coverage combines direct FR/UK/HK government calendars with the international OpenHolidays curated collection. Consult list_holiday_regions for actual countries, years and regional scope; coverage is not exhaustive worldwide and future dates may change. OpenHolidays entries do not have individual government confirmation. Responses preserve citations, observation dates, units, freshness, evidence and explicit gaps. Original public data, including ECB rates, is free from its publishers. ECB references are indicative, not executable prices or accounting/tax certification. Source/schema checks are not independent factual verification. Public pilot without an SLA. The optional paid HTTP country report remains separate and is never purchased by these tools. 26 general MCP tools. Setup, examples and focused editions: https://datoqa.bhazarstudio.workers.dev/docs/start/
Source-attributed data, table validation and file conversion for agents. Free data tools; country reports and reconciliation: 0.002 USDC. Supported file conversions: 0.01–0.02 USDC. Start: https://datoka.dev/qa. Provenance checks are not independent factual verification.
Official ECB euro reference rates for invoices and tax returns. $0.004/call via x402.
Live and historical FX rates (ECB via Frankfurter) — paid per call (x402/credits), 2 tools
Add one secure layer between your agents and this server.
