CurrencyCore

Exchange rates (USD base)

get_rates

Read-onlyIdempotent

Return the full USD-based exchange-rate snapshot for one date: rates maps every supported currency to units per 1 USD. Use when the user wants a multi-currency table in USD (for example "today's rates"). Use get_rates_by_base for a non-USD base, convert for one pair or amount, and get_history for a time series. Omitting date returns the latest available snapshot, which is not necessarily today. Returns { base: "USD", date, rates }; a date with no snapshot is a 404. Requires a signed-in connection; each successful call bills 1 API request.

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

Input Schema

Name	Required	Description	Default
`date`	No	YYYY-MM-DD. Defaults to the latest available date.

Output Schema

Name	Required	Description	Default
`asOf`	No
`base`	Yes
`date`	Yes
`rates`	Yes
`requestedDate`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "asOf": {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "base": {
+      "const": "USD",
+      "type": "string"
+    },
+    "date": {
+      "type": "string"
+    },
+    "rates": {
+      "additionalProperties": {
+        "type": "number"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "requestedDate": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "date",
+    "base",
+    "rates"
+  ],
+  "type": "object"
+}

First observedNov 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations, which only declare read-only/idempotent safety. The description adds the auth prerequisite ("signed-in connection"), the billing cost (1 API request per successful call), the semantics of omitting `date` (latest available, not necessarily today), and the 404 failure mode for missing snapshots.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences, each carrying a distinct piece of information: purpose, sibling routing, default behavior, return shape/errors, and auth/cost. Front-loaded with the purpose and tightly packed with no filler.

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 single-optional-parameter read tool, the definition covers selection guidance, default behavior, return shape, error case, auth, and cost. With an output schema present, the description need not expand further on return values.

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 format (YYYY-MM-DD) and default are already documented, putting the baseline at 3. The description adds real value with the caveat that the default snapshot is "not necessarily today," which the schema does not convey, but it offers no further detail on date bounds or supported range.

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?

States a specific verb and resource: "Return the full USD-based exchange-rate snapshot for one date," and clarifies the shape of `rates` (units per 1 USD). This distinguishes it immediately from `get_rates_by_base`, `convert`, and `get_history`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ("multi-currency table in USD, for example today's rates") plus explicit routing for three alternatives: non-USD base, single pair/amount, and time series. Nothing is left to inference about tool selection.

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

All CurrencyCore 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?