PAID ($0.005). Historical values of a reference series with effective date ranges, optionally filtered by from/to (YYYY-MM-DD). Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest effective date, YYYY-MM-DD | |
| from | No | Earliest effective date, YYYY-MM-DD | |
| series | Yes | Series id | |
| api_key | No | API key | |
| country | Yes | ISO country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the cost ($0.005), the optional api_key behavior, and the fallback payment via x402. It does not cover error handling or response structure, but key behavioral traits are present, adding significant value beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the cost and core function, no filler. Every sentence earns its place, covering cost, purpose, filters, and auth/payment.
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?
The description covers the essential aspects: purpose, payment, optional filters, and the api_key fallback. It does not detail response structure (no output schema exists), but for a moderate-complexity tool with 5 parameters, it is adequately complete, though a bit more on return format would help.
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 baseline is 3. The description adds meaning by clarifying that from/to are optional filters with YYYY-MM-DD format and that api_key is optional with a specific fallback behavior. This adds context beyond the schema descriptions.
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 retrieves 'Historical values of a reference series with effective date ranges', specifying the resource (reference series) and the action (get history). It distinguishes itself from sibling tools like get_snapshot and list_series by focusing on historical data with date ranges.
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 historical series data with optional filters, but does not explicitly state when to use this tool versus alternatives like get_series or get_snapshot. The paid nature hints at cost-conscious usage, but no alternatives or exclusions are mentioned.
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.
Each tool targets a distinct domain: wage compliance, income tax, VAT, working days, holidays, series data (current, history, snapshot, catalog), and settlement dates. Even the financial computations (check_minimum_wage, compute_income_tax, compute_vat) have clearly different inputs and purposes, so no two tools are confusable.
Most tools follow a clear verb_noun snake_case pattern (check_, compute_, count_, get_, list_). The only exception is `settlement_date`, which is a noun phrase rather than verb-first, but it remains consistent in style and readability. This minor deviation prevents a perfect score.
With 10 tools, the server is well-scoped for a reference-data provider. It balances specific computations (minimum wage, tax, VAT) with general data access (series, holidays, settlements), and each tool serves a clear purpose without overlap or unnecessary bulk.
The tool surface comprehensively covers reference data for financial and calendar domains: statutory rates and compliance, holiday and working-day calendars, settlement conventions, and a generic series system with current, historical, snapshot, and catalog access. No obvious gaps impede an agent from accomplishing typical reference-data tasks, and the free list_series enables discovery.
