Frankfurter — List Supported Currencies

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat these. It adds useful context beyond annotations by stating the exact count of currencies (33) and the public domain nature of the data, which clarifies the tool's behavior and provenance. It does not contradict any annotation, and the added detail is valuable for an agent assessing suitability.

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 a compact three-sentence structure with the core function (what it returns) front-loaded, followed by usage guidance and essential operational notes. Every sentence earns its place; there is no redundancy or filler, and the most critical information appears first.

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 read-only list tool, the description covers the essential context: what is returned, the exact number of items, the intended use case, and the fact that no parameters or authentication are needed. An output schema exists to describe the return structure, and the annotations cover safety traits. An agent has everything required to select and invoke this tool correctly without further investigation.

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?

The only parameter, locale, is fully described in the schema with 100% coverage, including its optionality and that any value is accepted. The description adds 'No parameters required,' which reinforces what the schema already indicates. Since the schema provides complete parameter semantics, the description adds no new meaning beyond restating that it is optional, warranting the baseline score of 3.

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 states precisely what the tool returns: 'all 33 currencies supported by the Frankfurter.dev ECB exchange rate API with their full English names.' It also explicitly distinguishes its role as the discovery tool by naming the three sibling rate tools it supports, leaving no ambiguity about its purpose versus alternatives.

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?

It gives explicit usage guidance: 'Use this to discover valid currency codes before calling frankfurter.currency.latest, frankfurter.currency.historical, or frankfurter.currency.series.' This directly instructs when to invoke it relative to siblings, and also clarifies 'No parameters required' and 'No auth,' covering operational prerequisites.

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