NBG Rates (National Bank of Georgia)

NBG rates for a date

nbg_get_rates

Read-onlyIdempotent

Official National Bank of Georgia (NBG) exchange rates of the Georgian lari (GEL) in force on one calendar date. Every rate is GEL per ONE unit of the currency (NBG quotes some currencies per 10, 100, 1000 or 10000 units; the raw pair is returned as nbgQuantity and nbgRate). Dates are calendar days in Tbilisi; the default is today. NBG sets a rate on business days around 17:00 Tbilisi time, valid from the next calendar day until the next rate, so after 17:00 tomorrow can be requested by date. Sundays, Mondays and days after a public holiday have no rate of their own: the rate in force was set earlier and is returned with carriedOver true and effectiveDate set to the day it took effect. Quote effectiveDate when carriedOver is true. A date whose rate NBG has not published yet returns an error, never a guess. When nbgQuantity is not 1, state NBG's quoted form first, nbgRate GEL per nbgQuantity units (for example 1.6452 GEL per 100 JPY), and the per-unit rate beside it: that quoted form is what nbg.gov.ge and accounting software show.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	Calendar date YYYY-MM-DD. Defaults to today in Tbilisi. Tomorrow's rate exists after about 17:00 Tbilisi time.
`language`	No	Language of currency names: en (default) or ka (Georgian). Codes, numbers and dates are identical in both.
`currencies`	No	ISO 4217 codes to return, case-insensitive, duplicates ignored (for example ["USD", "EUR"]). Omit for all currencies. GEL has no row, since every rate is in GEL, so it is listed in unknownCodes.

Output Schema

TableJSON Schema

Name	Required	Description
`rates`	Yes
`carriedOver`	Yes	true when the rate in force on requestedDate took effect on an earlier day; it is still the official rate
`unknownCodes`	Yes
`effectiveDate`	Yes	Calendar date the returned rate took effect, as published by NBG
`requestedDate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description layers substantial extra behavior on top: carriedOver/effectiveDate semantics, the guarantee that unpublished dates return an error 'never a guess,' and the nbgQuantity quoting convention. This is real context the agent cannot get from structured fields.

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?

Purpose is front-loaded and nearly every sentence carries operational weight (timing, carried-over handling, error guarantee). It runs long at roughly 200 words, and the final output-formatting instruction partly duplicates what the output schema covers, but there is little true 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 rate-lookup tool with an output schema, it covers everything an agent needs: default date, business-day publication timing, carried-over behavior, error-on-unpublished, and how to present multi-unit quotes. Nothing material 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 coverage is 100%, so date, language and currencies are already fully documented, including the 17:00 timing note that the description repeats. The extra detail about nbgQuantity and GEL landing in unknownCodes concerns output interpretation rather than the input parameters, so baseline 3 applies.

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?

States a specific verb+resource: official NBG GEL exchange rates 'in force on one calendar date.' The single-date framing implicitly separates it from nbg_rate_history, but no sibling is named explicitly, so it stops short of full sibling differentiation.

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?

Offers operational timing guidance (default is today; after 17:00 Tbilisi tomorrow can be requested), which implies when the tool applies. However, it never says when to prefer this over nbg_convert, nbg_convert_many or nbg_rate_history, leaving tool selection to inference.

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

All NBG Rates (National Bank of Georgia) 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.