ECB FX rates, cloud GPU and LLM API prices, World Bank country macro data; pay per call via x402
Scored across 9 tools
The rates trio (latest/historical/timeseries) is cleanly separated, but `convert` largely duplicates what `rates_latest`/`rates_historical` plus arithmetic already do, and `macro_country` vs `macro_indicator` have a fuzzy boundary (one country × 21 indicators vs 1 indicator × 20 countries) that an agent could easily misselect. `macro_rank` and the two ai_*_prices tools are distinct.
All snake_case, but the namespace prefixes are ad hoc (ai_, macro_, rates_, and a bare `convert`), and the dominant pattern is noun_topic rather than a verb_noun convention. Readable, yet no single predictable scheme an agent can rely on.
Nine tools is a reasonable, well-scoped count, and each tool has a distinct purpose. The only concern is that the count is spread across three unrelated domains (FX, macro data, AI hardware/LLM pricing), which feels like bundled products rather than one coherent service.
FX coverage is solid (latest, historical, timeseries, convert), but there is no tool to list supported currencies, no tool to discover macro indicator keys (the description defers to a free endpoint), and the AI price tools lack model/GPU catalog listing or historical pricing — several dead ends for an agent.
Cloud GPU price comparison: hourly list prices of GPU / AI accelerator instances (H100, H200, A100, L40S, L4, A10G, T4, B200, MI300X, Trainium, Inferentia ...) on AWS and Azure in US, EU and Asia regions, on-demand and Azure Spot, ranked by USD per GPU-hour. Filter by gpu model, cloud, region, pricing. Official provider price APIs, refreshed daily. Costs $0.005 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | GPU/accelerator model or instance substring, e.g. H100, A100, L4, trainium | |
| cloud | No | aws or azure | |
| limit | No | 1-100, default 20 | |
| region | No | e.g. us-east-1, eastus, japaneast | |
| pricing | No | on_demand or spot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantive behavior beyond the annotations: results are ranked by USD per GPU-hour, data comes from official provider price APIs refreshed daily, and the call costs $0.005 USDC on Base via x402 — a critical billing fact an agent must know before invoking. It stops short of describing pagination or exact response shape.
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?
A single dense sentence, front-loaded with the capability and coverage before filters, data provenance, and payment terms. Every clause carries information, though the model enumeration could be trimmed.
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 no output schema, the description does convey the essential return semantics (a ranked list priced in USD per GPU-hour) plus data freshness and cost. Details like page size behavior or record fields are left implicit, which is a minor gap for a read-only lookup tool.
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% with per-field examples, so the schema carries most of the load. The description still adds meaning: the gpu filter matches accelerator models or instance substrings, pricing covers on-demand plus Azure Spot only, and results are ordered by USD per GPU-hour.
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 (cloud GPU price comparison, hourly list prices of GPU/AI accelerator instances) and enumerates concrete coverage (H100/H200/A100/B200/MI300X/Trainium, AWS and Azure, US/EU/Asia). It is clearly separable from the nearest sibling, ai_llm_prices, by resource type.
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 context for use: filter by gpu model, cloud, region, pricing, and results are ranked by USD per GPU-hour. It does not explicitly say when to prefer ai_llm_prices instead, but the GPU-vs-LLM split is implied strongly enough that an agent will route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LLM API pricing lookup: USD per 1M input, output and cached-input tokens plus context window for ~3,300 models (OpenAI GPT, Anthropic Claude, Google Gemini, DeepSeek, Llama, Mistral, Qwen, xAI ...) across providers (direct, Azure, Bedrock, Vertex, Together, Fireworks ...). Filter by model and provider; sorted by input price. Costs $0.005 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1-100, default 25 | |
| model | Yes | Model name substring, e.g. gpt-5, claude-sonnet, gemini-2.5 | |
| provider | No | Provider substring, e.g. openai, anthropic, bedrock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds useful behavioral context: the tool costs $0.005 USDC on Base via x402, covers roughly 3,300 models, and sorts results by input price. It does not discuss pagination or error behavior, but the payment and data-scope details are meaningful additions.
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 definition is front-loaded and appropriately compact, leading with the core lookup purpose and return values. The long parenthetical model/provider lists are slightly dense but still serve to communicate coverage rather than adding fluff.
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 no output schema, the description carries the return-value burden and does so clearly by naming the token price fields and context window. For a three-parameter read-only lookup, it supplies enough context about coverage, sorting, filtering, and cost.
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%, so all three parameters are already documented in the schema. The description mentions filtering by model and provider and sorting by input price, but it adds little parameter-level syntax or meaning beyond the schema and does not explain the limit parameter.
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 states a specific verb/resource combination ('LLM API pricing lookup') and names the exact returned fields: USD per 1M input, output, cached-input tokens, and context window. It also distinguishes the domain from sibling tools like ai_gpu_prices by making clear this is LLM API pricing, not GPU pricing.
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 description says to filter by model and provider and mentions the x402 cost, but it does not explicitly say when to use this tool instead of ai_gpu_prices or other sibling tools. Usage is implied by the purpose rather than stated with alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Currency converter: convert an amount between any two of ~30 currencies (e.g. 100 USD to JPY) at the latest ECB reference rate or as of a past date. Returns rate, result and as_of date. Costs $0.001 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ISO 4217 | |
| date | No | Optional YYYY-MM-DD | |
| from | Yes | ISO 4217 | |
| amount | Yes | Number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds important behavioral context beyond them: the $0.001 USDC x402 payment cost, ECB reference-rate source, support for historical dates, and returned fields ('rate, result and as_of date'). There is no contradiction with the 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?
The description is one compact, front-loaded sentence group with zero filler. It moves efficiently from purpose to example to historical-date support to return values and payment cost.
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?
Given four parameters, no output schema, and existing read-only annotations, the description is complete enough for correct invocation. It covers the input example, data source, historical date option, return fields, and payment requirement.
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%, so the baseline is 3. The description adds useful semantic context with the example '100 USD to JPY' and the note that a past date can be used, clarifying how 'from', 'to', 'amount', and 'date' work beyond the minimal schema descriptions.
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 uses a specific verb and resource: 'Currency converter: convert an amount between any two of ~30 currencies.' It includes a concrete example ('100 USD to JPY') and clearly distinguishes conversion behavior from the sibling rates tools by focusing on converting an amount rather than returning raw 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?
It clearly states the primary use case: converting an amount at the latest ECB reference rate or as of a past date. The sibling tools imply alternatives for raw rates, but the description does not explicitly name rates_latest, rates_historical, or rates_timeseries or state when to prefer them over convert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Country economic profile: latest value and year plus annual history (2005 onward) for 21 World Bank World Development Indicators: GDP (USD), real GDP growth, GDP per capita, GNI per capita PPP, CPI inflation, unemployment, population, exports/imports % GDP, current account % GDP, central government debt % GDP, tax revenue % GDP, real and lending interest rates, FDI inflows % GDP, total reserves, official exchange rate, remittances % GDP, Gini, life expectancy, internet users. Country by ISO3/ISO2 code or name. CC BY 4.0. Costs $0.02 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | history years to include, 0-25, default 10 | |
| country | Yes | ISO 3166 alpha-3 or alpha-2 code or country name, e.g. JPN, US, Brazil |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only and closed-world safety, so the description carries useful extra weight: it discloses the 2005-onward coverage window, the 21-indicator scope, CC BY 4.0 licensing, and a concrete price of $0.02 USDC on Base via x402. That cost/auth context is exactly the kind of thing annotations cannot convey. It stops short of describing error behavior or result shape beyond the value/year framing.
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 dense sentences with the core purpose front-loaded; the long indicator enumeration is bulky but each item is load-bearing for the agent's decision. Pricing and licensing are appended compactly at the end with no 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?
With no output schema, the description does the work of explaining returns ('latest value and year plus annual history'), which is sufficient for an agent to anticipate the response shape. Coverage window, indicator list, country input formats, and cost are all present; only failure modes and pagination/size limits are 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?
Schema description coverage is 100%, so both parameters are already documented and baseline is 3. The description adds only indirect context for 'years' by stating history begins in 2005, which helps bound the valid range but does not explain the parameter itself.
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: a country economic profile drawing 21 named World Bank WDI series, each with a latest value and annual history from 2005. The enumerated indicator list makes the scope unmistakable, though it never explicitly contrasts itself with siblings like macro_indicator or macro_rank, so differentiation is inferred rather than stated.
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 description implies usage (fetch a broad multi-indicator profile for one country) but never says when to prefer this over macro_indicator (single series) or macro_rank (cross-country ranking). An agent must infer the boundary from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Macroeconomic time series: one World Development Indicator (e.g. inflation_cpi_pct, gdp_growth_pct, central_govt_debt_pct_gdp) for up to 20 countries over a year range, annual values. See free /macro/indicators for keys. CC BY 4.0. Costs $0.01 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | last year, default latest | |
| start | No | first year, default 2015 | |
| countries | Yes | comma-separated ISO3/ISO2 codes, max 20 | |
| indicator | Yes | indicator key from /macro/indicators, e.g. inflation_cpi_pct |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's main job is to add non-obvious traits — and it does: a $0.01 USDC payment on Base via x402, CC BY 4.0 licensing, annual granularity, and a hard 20-country cap. Return structure (field names, missing-data handling) is not disclosed, but the paid-call constraint is the critical operational fact and it is front-and-center.
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?
A single dense sentence front-loads what is returned, then the key-discovery pointer, then license and cost. No filler; the metadata about payment and licensing each carry operational weight.
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 4-parameter read-only fetch with full schema coverage and no output schema, the description covers scope, granularity, limits, discovery of keys, and the payment model. Only the shape of returned data and behavior on sparse/missing country-year values is left unstated, which is a minor gap.
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 are already documented in the schema, including defaults and the ISO3/ISO2 max-20 constraint. The description reinforces the indicator examples and country cap but adds essentially no semantics beyond the schema text; baseline 3 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-resource pair: fetch one World Development Indicator across up to 20 countries over a year range, with annual values. The explicit 'one indicator' scope cleanly separates it from macro_rank (ranking) and macro_country (country profile) without needing to name 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?
Prerequisite to obtain a valid indicator key is given ('See free /macro/indicators for keys'), which implies the usage flow. However, there is no explicit guidance on when to pick this tool over macro_country, macro_rank, or the rates_* siblings, so the agent must infer the boundary from scope alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Country ranking: sort all economies by one World Development Indicator for a year (default: each country's latest value), highest first or lowest first, optionally filtered by World Bank region or income group. Aggregates (World, regions) excluded unless requested. CC BY 4.0. Costs $0.02 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | year; default latest available per country | |
| limit | No | 1-300, default 50 | |
| order | No | desc (default) or asc | |
| income | No | income group substring, e.g. High income, Lower middle | |
| region | No | World Bank region substring, e.g. Latin America, Sub-Saharan | |
| indicator | Yes | indicator key from /macro/indicators | |
| aggregates | No | true to include regional/income aggregates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious context: the default year resolution and sort direction, aggregate exclusion, and especially the paid x402/$0.02 USDC cost on Base, which the agent must know before invoking.
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 core behavior is front-loaded in a single dense sentence, followed by a compact licensing/cost line. Nearly every clause carries information; the 'CC BY 4.0' clause is the only marginal element.
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 ranking tool with full schema coverage and no output schema, the description covers defaults, filtering, aggregate handling, and payment. Return shape and pagination behavior are left implicit, a minor gap given the parameters already imply limits.
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%, so all seven parameters are already documented, and the description largely restates those defaults (latest year, desc, aggregates excluded). It adds the interpretation of 'order' as highest/lowest first and confirms filter targeting, but does not go beyond the schema in any material way.
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 gives a concrete verb and resource ('Country ranking: sort all economies by one World Development Indicator for a year') and specifies scope (all economies, one indicator, one year). It is clearly distinguishable from the sibling macro_indicator (indicator lookup) and macro_country (single-country profile).
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 states the default behavior (each country's latest value, descending order) and when aggregates appear ('excluded unless requested'), plus optional region/income filtering. It stops short of explicitly naming alternatives for the single-country or indicator-lookup cases, which is the only gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ECB reference rates on a given date in any base; non-publication days fall back to the previous publication day (as_of). Costs $0.002 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency (default EUR) | |
| date | Yes | YYYY-MM-DD | |
| symbols | No | Comma-separated currencies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-open-world, so the bar is lower. The description adds material behavior not in annotations: non-publication-day fallback and a $0.002 USDC x402 payment cost. It does not describe response format or error behavior, but for a read-only rates call this is substantial.
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 one compact sentence with three useful clauses: date/base scope, non-publication fallback, and payment cost. It is front-loaded and contains no 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 a simple read-only rates lookup with full schema coverage and no output schema, the description covers scope, fallback behavior, and payment. It stops short of describing the returned structure or error behavior, but the essentials are present.
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%, so the base, date, and symbols parameters are already documented. The description reinforces 'any base' and date semantics but does not add syntax, defaults, or formatting details beyond the schema, making the baseline 3 appropriate.
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 as ECB reference rates for a specific date and any base, which implicitly separates it from rates_latest and rates_timeseries. However, it does not explicitly name or contrast those siblings, so it falls 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?
The date-specific framing implies this tool is for single historical dates, and the fallback note gives useful context. But it never states when to use rates_latest or rates_timeseries instead, nor does it give explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's exchange rates (forex reference rates, most recent ECB publication) for ~30 currencies in any base currency, e.g. USD to JPY, CNY, EUR, GBP, HKD, SGD, KRW, INR. Filter with symbols. Returns as_of date and source attribution. Costs $0.001 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency (default EUR) | |
| symbols | No | Comma-separated currencies (default all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes meaningfully beyond the annotations: it discloses the data provenance (ECB reference publication), the returned fields (as_of date, source attribution), and critically that the call costs $0.001 USDC on Base via x402 — payment requirements are not derivable from readOnlyHint/openWorldHint. It does not cover rate limits, caching, or behavior on unsupported currency codes.
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?
Four dense sentences, front-loaded with what the tool returns, then filtering, return fields, and cost. No filler; each sentence contributes distinct information.
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 2-parameter, zero-required, read-only tool with no output schema, the description covers purpose, filtering, return fields, provenance, and cost — essentially everything needed to invoke it. Minor gaps remain around invalid currency codes and whether the ~30-currency list is discoverable.
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% and already documents base (default EUR) and symbols (default all), so the schema carries most of the load. The description adds the 'any base currency' scoping and the USD→JPY example that clarifies the direction of conversion, which is a modest but real supplement.
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 resource ('Today's exchange rates, most recent ECB publication') with scope (~30 currencies, any base currency) and example pairs. The 'Today's/latest' framing implicitly separates it from rates_historical and rates_timeseries, though it never names those siblings.
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?
'Filter with symbols' hints at the filtering use case, and 'e.g. USD to JPY' shows a typical call, but there is no explicit when-to-use-this-vs-alternatives guidance despite three closely related sibling tools (convert, rates_historical, rates_timeseries). The agent must infer that this is the spot/latest path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily reference rate series for base/symbol between start and end (max 366 days), with min/max/mean and change. Costs $0.003 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | YYYY-MM-DD | |
| base | Yes | ISO 4217 | |
| start | Yes | YYYY-MM-DD | |
| symbol | Yes | ISO 4217 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-open-world operation. The description adds meaningful behavioral context beyond annotations by disclosing the $0.003 USDC x402 cost and the 366-day maximum range.
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 a single front-loaded sentence with no wasted wording. It packs the resource, constraints, output summary, and cost into a compact form.
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 rate-series tool with a fully described schema and annotations covering safety, the description is largely complete. It discloses the output statistics and payment cost, though it could be slightly more explicit about base/symbol ordering or error conditions.
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%, so the schema already documents all four parameters and their date formats. The description adds the useful max 366-day constraint on start and end, but does not clarify the distinction between base and symbol beyond restating them together.
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 names a specific resource (daily reference rate series), the pair of currencies, the date interval, and the aggregate outputs. It implicitly distinguishes the tool from rates_latest and convert by emphasizing a ranged daily series, though it does not explicitly call out when to use the sibling tools instead.
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 is implied by the stated range and max 366-day limit, but there are no explicit when-to-use or when-not-to-use instructions and no named alternatives. An agent can infer that this is for ranged daily series, but must compare against siblings on its own.
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.
ai_gpu_pricesai_llm_pricesmacro_countrymacro_indicatormacro_rankconvertrates_historicalrates_latestrates_timeseriesLive and historical FX rates (ECB via Frankfurter) — paid per call (x402/credits), 2 tools
FRED macro data, Treasury yields, FX rates & macro indicators for AI agents. Pay-per-query via x402.
Live financial data MCP: FX, crypto, stocks, news, URL reader. x402 on Base: $0.001/call.
Official ECB euro reference rates for invoices and tax returns. $0.004/call via x402.
Add one secure layer between your agents and this server.
