Get official CZK exchange rates published by ČNB. Returns all currencies from the daily sheet (~31 majors). Optional date parameter (YYYY-MM-DD) for historical rates; otherwise returns latest.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional ISO date (YYYY-MM-DD) for historical rates. Omit for latest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful context: it identifies the data source (ČNB), the exact scope (all currencies from the daily sheet), and the behavior of the date parameter (historical vs. latest). This enriches the agent's understanding without contradicting 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 concise and well-structured: the first sentence states the core purpose, and the second sentence explains the parameter behavior. Every sentence earns its place with no redundant 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 simple tool with one optional parameter and no output schema, the description adequately conveys what the tool returns and how to invoke it. It could mention whether rates are relative to CZK (implied) or the exact return format, but these are minor gaps given the tool's simplicity.
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?
While the schema covers 100% of the sole parameter with a pattern and description, the tool description adds practical semantics: the date is optional, used for historical rates, and omitting it returns the latest rates. This goes beyond the schema's basic syntax explanation.
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 states the tool gets official CZK exchange rates from ČNB and specifically returns all currencies from the daily sheet (~31 majors). It distinguishes itself from sibling tools like get_rate and convert by emphasizing the 'all currencies' scope.
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 for retrieving all daily rates, with an optional historical date, but does not explicitly state when to choose this over get_rate or convert. The absence of explicit alternative guidance makes the usage context clear but not fully differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The three tools are mostly distinct: convert handles cross-currency conversion, get_rate provides a single currency's CZK rate, and get_rates lists all rates. However, get_rate without a code returns all rates, overlapping with get_rates, which could cause confusion if descriptions are not carefully read.
All tools follow a consistent lowercase verb-based naming convention: convert, get_rate, get_rates. The pattern is simple and predictable, with the plural 'rates' clearly distinguishing the bulk operation from the single-rate lookup.
With only 3 tools, the server is tightly scoped for its purpose of accessing ČNB exchange rates. Each tool serves a distinct, necessary function—conversion, single rate lookup, and full rate listing—without redundancy.
The tool surface covers the core domain completely: retrieving all rates, retrieving a single rate, and converting between currencies, including historical dates. No obvious missing operations for a currency exchange rate server of this type.