DatoQA — Historical Exchange Rates

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuine new context that annotations cannot express: the catalog is static and does not guarantee current availability, so the agent should inspect response status and freshness.

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?

Four sentences, front-loaded with what is returned before the usage rules, and every sentence carries actionable content. Slightly dense with compound clauses, but no wasted text.

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?

Awareness/discovery tool with an output schema that carries return details, so the description need not document fields. It covers purpose, call/skip conditions, and the static-vs-available caveat; only explicit pagination or size expectations are absent, which is minor for a catalog.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% for the empty object, and the description correctly signals it is called with no arguments.

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?

It names a specific resource and enumerates exactly what the catalog returns (scope, allowed tool names, source IDs, endpoint, access policy), which distinguishes it from the data-retrieval siblings. The phrase 'this thematic MCP' is mild jargon but does not obscure the purpose.

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?

Explicitly states when to call it (no arguments, when setting up the connection), when to skip it (when the desired tool and inputs are already known), and the narrow secondary use (resolving missing identifiers or coverage). This is a complete usage policy.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description adds genuinely new context: the digest attests snapshot integrity only, not factual truth, and the record must be 'currently available' (i.e. still retained).

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?

Two compact sentences with zero filler; the retrieval scope leads and the important integrity caveat is attached immediately afterward.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The only meaningful omission is disambiguation from get_record, which would help an agent choose between two similarly named retrieval tools.

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?

Only one parameter with 100% schema description coverage, which already explains that the id comes from a DatoQA data response and returns the retained snapshot. The description adds little beyond that baseline, though 'currently available' reinforces the retention precondition.

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?

States a specific verb and a precise resource: the retained source JSON snapshot plus its SHA-256 digest. It does not, however, contrast itself with the sibling get_record, so an agent cannot tell from the description alone which of the two to call.

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?

Usage is implied rather than stated: 'for a currently available record' signals that the record must still be retained, and the integrity-vs-truth caveat hints at provenance use cases. There is no explicit when-to-use / when-not-to-use rule and no alternative (e.g. get_record) is named.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral context: at most one year returned, original decimals preserved, gaps left unfilled, missing values reported, and no carry-forward or interpolation. That is exactly the kind of data-quality disclosure an agent needs for a historical series and it goes well past the 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?

Front-loaded with the core purpose, then constraints, all in three dense sentences with no filler. The trailing exclusion list ('missing values and evidence') is slightly telegraphic, but nothing is padded.

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?

With an output schema present, the description does not need to explain return structure and instead covers scope, constraints and data-quality caveats. For a 3-parameter, single-year retrieval tool this is complete enough to call correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description reinforces the critical mutual-exclusivity of year and date and states the default year and the EUR-denomination convention. These details largely mirror the schema, so it earns only a modest lift over baseline.

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 gives a specific source and resource: 'ECB historical daily reference rates for one currency against EUR', which names provider, granularity and quote convention beyond the bare tool name. It implicitly separates itself from a current-quote tool by stating it does not supply current quotes, cross rates or executable prices, though it never names a sibling outright.

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 concrete selection rules for the input modes: 'Provide year (1999 onward) or an exact date, not both. Default: current year.' It also rules out adjacent use cases (no interpolation, no weekend carry-forward, no cross rates), but it never explicitly says when to prefer get_exchange_rates or list_exchange_rate_history over this tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds genuinely useful behavioral context beyond them: rates are indicative not executable, freshness must be checked via observation_date, and the data is freely available at the cited source.

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?

Three compact sentences, no filler, with the core purpose front-loaded and the freshness/executability caveats following immediately. Every sentence carries distinct 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?

An output schema exists, so return-value detail is not needed, and annotations cover the safety profile. The description covers source, freshness, and executability caveats, but omits routing to the history sibling, which is the one remaining gap for correct selection.

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?

Schema description coverage is 100%, and the schema itself explains the optional currency code, the 'units per one EUR' convention, and the omit-for-all default. The description adds no parameter-level meaning beyond that, so the baseline 3 is correct.

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?

States a specific resource (ECB indicative daily currency reference rates) and scope (against EUR), which is more precise than a bare verb+noun. However, it never names the obvious sibling get_exchange_rate_history or otherwise distinguishes this current-rate tool from the historical one, so the agent must infer the boundary.

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 signals when this is appropriate via the caveat that these are not real-time or executable prices, which implies a reference/informational use case. But it gives no explicit when-to-use vs when-not-to-use, and no routing to get_exchange_rate_history for time series, leaving usage to inference.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context: only unexpired records are returned, provenance and a verification level accompany them, and source/schema validation must not be read as independent factual verification. That epistemic caveat is exactly the kind of trait annotations cannot express.

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?

Two short sentences, purpose first and caveat second, with no filler. The second sentence is slightly terse given it introduces a nuanced distinction, but it earns its place.

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?

An output schema exists, so return shape need not be restated, and annotations cover safety. The description still supplies the unexpired-only constraint and the verification caveat, leaving only tool-selection guidance missing. It is sufficient for correct invocation, marginally short of complete.

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?

Schema description coverage is 100% with a single well-documented id parameter (opaque, exact reuse, no invention), so the schema already carries full semantics. The description adds nothing about the id's format or origin, making the baseline 3 correct.

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?

States a specific verb and resource ('Get an unexpired record') and adds what comes with it (provenance, explicit verification level). It does not differentiate itself from adjacent siblings like get_evidence, get_indicators, or catalog, and 'record' stays abstract, so an agent cannot fully tell it apart from those without opening the schemas.

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 never says when to reach for this tool versus alternatives, nor gives a precondition (e.g., it needs an id previously returned by a data response). The second sentence is an interpretive caveat about verification, not usage guidance. No alternatives among the many sibling get_* tools are named.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is covered. The description adds genuinely non-obvious data context on top: values are units per EUR, history starts at 1999, discontinued currencies exist, and there are explicit gaps in the daily series. These caveats materially affect how an agent should interpret results.

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?

Two tight sentences with no filler, front-loaded with the listing scope before the caveats. The punctuation is a little dense (semicolon and comma fragments) but every clause carries 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?

With no input parameters, a present output schema, and annotations covering the safety profile, the description only needs to convey scope and data caveats — and it does both. Nothing required to call or interpret this tool is missing.

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 tool takes zero parameters, so there is nothing for the schema or description to disambiguate. Baseline 4 applies; the description correctly avoids inventing parameters that do not exist.

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 names the resource scope precisely: available currencies, annual snapshots since 1999, and explicit gaps in ECB daily reference FX history. An agent can tell this is a metadata/discovery tool rather than a data fetcher. However, it never names the obvious sibling (get_exchange_rate_history) to sharpen the list-vs-get distinction.

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?

There is no when-to-use or when-not-to-use guidance. Given siblings like get_exchange_rate_history and get_exchange_rates, the agent must guess whether this tool returns the actual rates or only coverage metadata. The ECB provenance note ('original data freely available at ECB') is background, not routing guidance.

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