ECB FX Reference Rates

ecb_fx_rates

Get an official, citable euro exchange rate for an invoice, ledger entry or tax return. Returns European Central Bank euro reference rates (about 30 currencies) for the latest business day or any date since 1999, with cross rates via any base currency, amount conversion, the ECB reference date actually used and a source link. Use when the rate must come from an official source rather than a market feed. $0.004 per call, USDC on Base (x402).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ecb_fx_rates"
  }
}

Input Schema

Name	Required	Description
`base`	No	Base currency (default EUR)
`date`	No	YYYY-MM-DD (default latest)
`amount`	No	Amount to convert (default 1)
`symbols`	No	Comma-separated targets
`payment_signature`	No	x402 v2 PAYMENT-SIGNATURE header value. Omit to receive payment requirements.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations at all, the description carries the full burden and does most of it well: it discloses the paid model ($0.004 per call, USDC on Base, x402), the data vintage rule ('latest business day'), the historical depth (since 1999) and that the response includes the ECB reference date actually used plus a source link. It stops short of explaining the payment handshake (omit the signature to receive payment requirements), which is only covered indirectly by the schema.

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?

Three sentences, front-loaded with the purpose and use cases, then capabilities, then pricing. Nearly every clause carries information, though 'official, citable' and the invoice/ledger/tax-return list carry a slightly promotional tone that could be trimmed without loss.

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?

There is no output schema, but the description compensates by naming the key return fields (rate, ECB reference date used, source link). For a 5-parameter, zero-required, payment-gated data tool the description is nearly complete; the only gap is that it leaves the 402 payment challenge flow to the schema.

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 real meaning: it frames 'base' as enabling cross rates via any currency, 'date' as any date since 1999 or the latest business day default, and 'amount' as currency conversion. It does not clarify the payment_signature parameter, which is arguably the trickiest one to use correctly.

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 opens with a specific verb and resource ('Get an official, citable euro exchange rate') and immediately scopes what is returned: ECB euro reference rates, ~30 currencies, latest business day or any date since 1999, with cross rates, conversion, reference date and source link. An agent knows exactly what this tool produces without opening the schema.

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?

It gives an explicit selection condition: 'Use when the rate must come from an official source rather than a market feed,' which contrasts the tool with an unnamed alternative category. What's missing is any negative guidance about when ECB rates are unsuitable (e.g., intraday or non-ECB currencies), so the routing guidance is clear but not complete.

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

All ECB FX Reference Rates 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?