NBG Rates

Convert a list via NBG rates

nbg_convert_many

Read-onlyIdempotent

Convert a list of amounts to or from GEL using the official NBG rate for each date. Use for batch conversions like invoices, with per-item results and optional totals.

Instructions

Converts a list of amounts, each at the official NBG rate in force on its own date: one call for a list of invoices. Items are answered independently; a bad date or code fails only its item, with the error text in that item. total is present when every converted item has the same target currency and covers the converted items only; call it partial when skipped is not 0. Once NBG stops answering, the remaining dates fail with the same error without being asked. Show resultRounded as the amount; result is the unrounded value for further calculation. 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes	1 to 100 conversions, each with the fields of nbg_convert; items are answered independently.

Output Schema

TableJSON Schema

Name	Required	Description
`items`	Yes	One entry per input item, in input order: a conversion, or the item with an error
`total`	No	Present only when at least one item converted, every converted item has the same target currency, and the sum is a finite number. It covers the converted items only: when skipped is not 0, say the total is partial and list the skipped items.
`skipped`	Yes
`converted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The annotations already cover read-only, open-world, idempotent, and non-destructive behavior, but the description adds substantial operational context: per-item error isolation, when total becomes partial via skipped, NBG outage fallback, resultRounded vs result semantics, Tbilisi calendar rules, rate publication timing, and carriedOver/effectiveDate behavior. It also states that unpublished rates return an error rather than a guess.

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?

Despite its length, the description is front-loaded with purpose and then proceeds through item independence, aggregation, rate timing, and output-field guidance. Each sentence carries necessary behavioral detail for a complex batch-rate tool.

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?

An output schema exists, but the description still explains crucial return-field semantics like resultRounded, result, total, skipped, carriedOver, and effectiveDate. Combined with detailed failure and rate-publication rules, an agent has enough context to call and interpret this tool correctly.

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%, and the nested item fields are already documented with descriptions and defaults. The description reinforces date semantics ('calendar days in Tbilisi', default today) but adds little beyond what the schema already states for the items parameter.

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 (Converts), the resource (a list of amounts), and the key scoping rule (each at the official NBG rate in force on its own date). The phrase 'one call for a list of invoices' makes the batch purpose distinct from the single-conversion sibling nbg_convert.

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

Usage Guidelines4/5

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

Gives clear context for use: converting a list of invoices in one call, with items answered independently. It does not explicitly name when to use nbg_convert instead or state exclusions, so it falls short of full alternative routing.

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

Deploy Server