Central Bank Rates MCP Server

Request a trial API key

request_trial_key

Self-issue a 7-day AllRatesToday API key with 100 lifetime calls, no account or email, when a tool needs a key for immediate central-bank rates, history, comparisons, or calendars.

Instructions

Self-issue an AllRatesToday API key with 100 lifetime calls, valid 7 days, with no account and no email. Use it when another tool answered "needs an API key" and the user wants a dated central-bank table, a history series, a cross-bank comparison or a publication calendar right now. The key is adopted by this server for the rest of the session and returned once — tell the user to put it in the MCP config as ALLRATES_API_KEY to keep it. Capped at 3 keys per IP per day. For a lasting key, register at https://allratestoday.com/register (free) or see https://allratestoday.com/pricing.

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

Input Schema

Name	Required	Description	Default
`agent`	No	Optional: the agent or product requesting the key.
`purpose`	No	Optional: one line on what the rates are for.

Output Schema

Name	Required	Description
`key`	No
`note`	Yes
`calls`	No
`adopted`	Yes	True when this server switched to the new key
`expires_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.15Nov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, non-idempotent, open-world call; the description goes well beyond that with quota (3 keys per IP per day), key lifetime (7 days / 100 calls), the side effect that the key is adopted by the server for the session, and the one-time-only return. It also tells the agent what to do with the returned secret (put it in the MCP config as ALLRATES_API_KEY), which is exactly the operational context annotations cannot convey.

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 the entitlement terms, then usage trigger, then key-handling instructions, then limits and the durable alternative — a sensible order with each sentence carrying distinct information. It is dense to the point of being long, and the 'no account and no email' idea is partially echoed by the free-registration line, costing a little tightness.

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?

Despite an output schema existing, the description still covers what the agent most needs to know about the response — the key is returned once and retained only for the session, so the user must copy it out. Quota, validity, side effects, and the paid/registration fallback are all present; nothing material for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (agent, purpose) are optional and fully described in the schema, so the baseline applies. The description adds no additional semantics about these fields — it never mentions them or whether they matter for quota or support — so it neither helps nor misleads here.

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 — 'Self-issue an AllRatesToday API key' — and immediately bounds scope with the exact entitlement (100 lifetime calls, 7-day validity, no account, no email). This is unambiguously distinct from the sibling read tools like get_official_rates or compare_official_rates.

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?

Gives an explicit trigger condition ('when another tool answered "needs an API key"') plus the concrete data needs it unblocks, and names an alternative path for the different case ('For a lasting key, register at ...'). When-to-use, when-it-is-the-wrong-choice, and the alternative are all spelled out.

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

Deploy Server