SiteCheck

Currency exchange rates from the European Central Bank

fx

Read-only

Currency exchange rates from the European Central Bank (about 30 currencies, back to 1999): latest or a given date, amount conversion, or a daily time series between two dates. Source: ECB reference rates via Frankfurter. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": "fx"
  }
}

Input Schema

Name	Required	Description
`to`	No	Target currencies, comma-separated (default: all)
`end`	No	YYYY-MM-DD: time series end (default today)
`date`	No	YYYY-MM-DD for a past day
`from`	No	Base currency, default USD
`start`	No	YYYY-MM-DD: time series start
`amount`	No	Amount to convert, default 1

Output Schema

Name	Required	Description	Default
`base`	No
`date`	No
`rates`	No
`amount`	No
`source`	No
`converted`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "amount": {},
+    "base": {},
+    "converted": {},
+    "date": {},
+    "rates": {},
+    "source": {}
+  },
+  "type": "object"
+}

First observedOct 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the data provenance (ECB reference rates via Frankfurter), the historical depth (back to 1999), and, critically, the payment requirement: $0.002 USDC per successful call via x402 on Base, Solana or Arc, with failed calls free. Cost and settlement-chain information is behavior an agent cannot get from annotations or schema, and it materially affects whether to call at all.

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-loaded with what the tool is and what it returns, followed by coverage, source and price. The pricing sentence is dense but each clause (per-call cost, asset, chains, failure policy) carries distinct operational weight; no filler sentences are present.

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 six-parameter, fully documented, output-schema-bearing read tool, the description supplies everything else an agent needs: data source and trust level, historical range, available query shapes, and the paid-call model. Nothing required to decide or invoke correctly is omitted.

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 goes further by mapping parameter groups to distinct operations: omitting date means latest, supplying date means a past day, start/end selects a daily series, and amount triggers conversion. That relational meaning is not expressed by the individual field descriptions in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely (ECB currency exchange rates), states its scope (about 30 currencies, back to 1999), and enumerates the three operations: latest, a specific date, amount conversion, or a time series. It implicitly separates itself from crypto/price siblings by naming the ECB fiat source, but it never explicitly points to an alternative tool.

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?

The three usage modes ('latest or a given date, amount conversion, or a daily time series between two dates') imply how to invoke it, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. crypto_convert for non-fiat pairs, units for non-currency conversion). The agent must infer routing from the source name alone.

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

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