Daily ECB reference rates over a date range for one or more currencies. 0.002 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date YYYY-MM-DD | |
| base | No | Base currency | EUR |
| from | Yes | Start date YYYY-MM-DD | |
| symbols | No | Targets, e.g. USD,GBP | |
| paymentProof | No | Payment proof: USDC tx hash on Polygon or Base (0x...) or Solana tx signature. Omit on the first call to receive the 402 payment instructions, pay, then call again with the proof. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must carry the burden of behavioral details. It includes crucial operational data regarding cost ('0.002 USDC per call') and payment flow ('via x402'), which are essential behaviors for an agent to know before invocation.
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 extremely brief, front-loading the most critical information—the data type, scope, and cost—in a single, efficient sentence with no extraneous language.
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?
The description is complete regarding the data request itself, defining what data and how it is scoped (ECB, date range). While the complex multi-step payment process for the 'paymentProof' parameter is detailed in the schema, the description is fully sufficient for the agent to understand the tool's function.
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 schema provides 100% coverage of parameter definitions and types. The description does not offer additional semantic context or constraints that are not already present in the structured input schema.
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 is highly specific, stating that it retrieves 'Daily ECB reference rates' over a 'date range.' This clearly defines the resource, the specific scope (ECB), and the nature of the data (daily historical rates).
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?
By mentioning 'Daily ECB reference rates over a date range,' it strongly implies the operational boundary, distinguishing it from real-time rate tools (like fx_rates) or daily summary tools. The specificity of the data set is a strong usage constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.