Official thresholds, rates and fees by key, with source, verified date and signature.
Scored across 3 tools
Each tool occupies a clearly separate role: get_fact retrieves a value by key, resolve_fact maps plain language to keys, and what_changed_since reports diffs since a date. The descriptions even state the handoff explicitly ('The keys feed get_fact'), so an agent can chain them without guessing.
All three names are snake_case and verb-led (get_, resolve_, what_changed_since), which is predictable. what_changed_since breaks the verb_noun shape slightly by using a clause rather than an object, but the convention is still readable and uniform in style.
Three tools is minimal but each earns its place: lookup, discovery, and change-tracking are genuinely distinct operations, and get_fact is a generic key accessor that scales across all covered domains. Nothing is redundant or padded.
The read-only fact domain is well covered: retrieval, key resolution/filtering by namespace, batch fetch, and a changelog with factKey linkage into get_fact. The only gap is that enumerating the full key space relies on resolve_fact or the mentioned `coverage` field rather than a dedicated listing tool.
The current value of one official figure by key — a tax threshold, rate, allowance, fee, deadline, limit or policy rate — with the date it was verified, the official source URL, the period it applies to and a signature. Keys are <country>/<topic>/<fact>, e.g. uk/income-tax/personal-allowance, uk/national-insurance/primary-threshold, us/social-security/wage-base, de/income-tax/grundfreibetrag, uk/bank-rate, eu/ecb/deposit-facility, uk/gov/passport-renewal-adult/fee-online-uk. A loose key is resolved when unambiguous; otherwise the answer lists candidate keys. max_age (e.g. 30d) marks the answer stale when the verification is older than that. nextExpectedChange is the next date the source's calendar allows the value to move; status is stale when that date has passed since verification. Several keys separated by commas return a batch. Covers UK, US and German rates and thresholds, UK vehicle tax and MOT rules, UK government service fees, UK exam dates and central-bank policy rates; coverage lists the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | one key, or several separated by commas (max 50), e.g. uk/income-tax/personal-allowance | |
| as_of | No | optional YYYY-MM-DD: the value in force that day | |
| period | No | optional period label instead of as_of, e.g. 2025-26 | |
| max_age | No | optional freshness bar: 30d, 12w, 6m, 1y or ISO 8601 (P30D) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: what the response contains (verified date, official source URL, applicable period, signature), how max_age flips status to 'stale', how nextExpectedChange interacts with status, and how ambiguous keys degrade to a candidate list. That is exactly the kind of behavioral detail annotations cannot carry.
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 and the key-format convention, with the more specialized behaviors (max_age, nextExpectedChange, status, batching, coverage) following in order. It is one dense paragraph and the seven inline key examples make it run long, but every clause carries information an agent needs.
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?
There is no output schema, so the description must carry the return shape — and it does, listing verified date, source URL, period, signature, status and nextExpectedChange. It stops short of describing the full response envelope for batches or what an unknown key returns besides candidate keys, which keeps it at 4 rather than 5.
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 goes further by explaining the consequence of max_age (the answer is marked `stale` when verification predates the bar) and the batch semantics of comma-separated keys. It adds outcome-level meaning rather than restating the schema's syntax.
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 ('the current value of one official figure by key') and enumerates the concrete fact types (threshold, rate, allowance, fee, deadline, limit, policy rate). It does not name or contrast the sibling tools resolve_fact or what_changed_since, so differentiation is left to inference.
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?
Rich operational guidance is present — key format with five worked examples, loose-key resolution with candidate fallback, comma-separated batch up to the schema's limit, and per-key max_age. However, it never states when to use this instead of resolve_fact or what_changed_since; the relationship to resolve_fact is only hinted at via the loose-key resolution sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked canonical fact keys for a plain-language question or a guessed key — "NI primary threshold", "ECB deposit rate", "passport renewal fee" — each with label, unit, period and verification date, and the full record of the top match when it is unambiguous. The keys feed get_fact. Filter by namespace (uk, us, de, eu).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | question or guessed key | |
| limit | No | default 5 | |
| namespace | No | optional jurisdiction filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value beyond them: results are ranked, each hit carries label/unit/period/verification date, and the full record is returned only when the top match is unambiguous — the last point materially changes how an agent should interpret output. Pagination/truncation behavior is not described.
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, the examples earn their space by disambiguating 'plain-language question' vs 'guessed key', and the `get_fact` linkage is placed as a short closing clause. Slightly dense in the opening sentence but no filler.
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 output schema, the description usefully enumerates returned fields and the conditional full-record behavior, which is exactly what an agent needs to decide whether to call again or proceed. The only gap is what the ranking is based on and how to handle a low-confidence or ambiguous result set.
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 parameter meaning is already documented and the baseline applies. The description only restates the namespace filter and does so incompletely — it lists `uk`, `us`, `de`, `eu` but the enum also includes `jp`, which could mislead an agent into thinking Japan is unfilterable. `limit` is not mentioned in either place beyond the schema default.
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+resource ('ranked canonical fact keys') and shows exactly what input looks like with three concrete example queries. It also distinguishes itself from the sibling by stating 'The keys feed `get_fact`', making the resolve-then-fetch relationship explicit.
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?
Implies the workflow clearly: this tool produces keys that feed `get_fact`, so it is the discovery step before retrieval. It does not state explicit exclusions or when to skip straight to `get_fact` (e.g. if the key is already known), so it falls short of full alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What has changed in Data Butler's verified datasets since a date — pass your training-cutoff date to learn which UK tax/NI/benefit thresholds, exam-spec facts, official vehicle datasets (UK DVSA, French RappelConso and Japanese MLIT recalls), software end-of-life dates (Node.js, Python, Ubuntu, Debian, Android, iOS, macOS, Windows, Java, Go, Ruby, PHP, PostgreSQL, React — cycles that reached end of life or whose dates moved), central-bank policy rates (Bank of England, Fed, ECB), US federal tax thresholds (IRS inflation adjustments, Social Security wage base, retirement and HSA limits), German tax and social-insurance thresholds (Grundfreibetrag, Beitragsbemessungsgrenzen, Zusatzbeitrag, Mindestlohn, Kindergeld, Umsatzsteuer), UK vehicle tax (VED) rates and MOT rules, UK exam dates (results days, summer timetable paper dates, entry deadlines and late-fee dates, announced specification changes), calendar facts (public holidays for the UK, US, Germany and France; tax-year and daylight-saving rules for nine countries — new years published, holidays added or moved), UK government service fees and rules (passports, ETA, Universal Credit, eVisa), Japanese vehicle statutory costs (車検 inspection fees, 自賠責 insurance rates), Japanese minimum wages by prefecture, 協会けんぽ health insurance rates, 雇用保険料率 and income-tax deductions, UK CPI and CPIH inflation rates (ONS, monthly) and US inflation (BLS CPI-U 12-month rate and index, each monthly release) changed after your knowledge ends. Each entry: from → to, effectiveFrom, official source, verifiedDate, and a maintainer note (e.g. which Budget). Areas: uk-rates, uk-exams, vehicles, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process, jp-vehicle-costs, jp-living-costs, uk-inflation, us-inflation, or all. Coverage starts 2026-08-31. The same changelog is published for humans at https://databutler.dev/changes, with feeds at https://databutler.dev/changes.rss and https://databutler.dev/changes.atom. Output is a Verified Changes protocol document (verified-changes/0.1, spec https://databutler.dev/protocol); an entry whose figure is a Verified Fact carries factKey for get_fact.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | default all | |
| since | Yes | ISO date YYYY-MM-DD, e.g. your training cutoff |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the safety profile is settled; the description adds real context beyond that: the output protocol (verified-changes/0.1 with spec URL), per-entry fields, and the coverage boundary starting 2026-08-31. It does not address what happens when 'since' precedes coverage start or how large the response may be.
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 first clause is well front-loaded, but the core sentence is a single sprawling run-on enumerating dozens of datasets and software platforms. The detail genuinely communicates coverage, yet the list is long enough to hurt scannability and could be compressed or summarized.
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 two-parameter read-only tool with no output schema, the description supplies everything needed: purpose, trigger value for 'since', scope options, entry shape, coverage start, and cross-references to get_fact and the public changelog. Nothing an agent needs in order to call it correctly 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?
Schema coverage is 100%, so baseline would be 3; the description earns above that by spelling out what each 'since' value means in practice (your model's training cutoff) and by expanding the area enum into human-readable dataset names so the agent can pick the right scope without guessing.
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: returns what has changed in verified datasets since a given date, enumerating the exact data domains covered. This is clearly distinct from siblings like get_fact (single fact retrieval), uk_rates_lookup (current rate lookup), or coverage (inventory), and the get_fact cross-reference reinforces 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?
Explicitly tells the agent to pass the training-cutoff date 'to learn which ... changed after your knowledge ends', which is a concrete usage trigger. It also routes to get_fact for verifying an individual figure. It stops short of stating when NOT to use it (e.g. use uk_rates_lookup for current values rather than deltas).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
what_changed_since1 field changedInput schema / properties / area / enumPrevious value: -[
- "uk-rates",
- "uk-exams",
- "vehicles",
- "software-eol",
- "policy-rates",
- "us-rates",
- "de-rates",
- "uk-vehicle-rules",
- "uk-exam-dates",
- "calendar",
- "uk-gov-process",
- "jp-vehicle-costs",
- "jp-living-costs",
- "all"
-]New value: +[
+ "uk-rates",
+ "uk-exams",
+ "vehicles",
+ "software-eol",
+ "policy-rates",
+ "us-rates",
+ "de-rates",
+ "uk-vehicle-rules",
+ "uk-exam-dates",
+ "calendar",
+ "uk-gov-process",
+ "jp-vehicle-costs",
+ "jp-living-costs",
+ "uk-inflation",
+ "us-inflation",
+ "all"
+]what_changed_since1 field changedInput schema / properties / area / enumPrevious value: -[
- "uk-rates",
- "uk-exams",
- "vehicles",
- "software-eol",
- "policy-rates",
- "us-rates",
- "de-rates",
- "uk-vehicle-rules",
- "uk-exam-dates",
- "calendar",
- "uk-gov-process",
- "jp-vehicle-costs",
- "all"
-]New value: +[
+ "uk-rates",
+ "uk-exams",
+ "vehicles",
+ "software-eol",
+ "policy-rates",
+ "us-rates",
+ "de-rates",
+ "uk-vehicle-rules",
+ "uk-exam-dates",
+ "calendar",
+ "uk-gov-process",
+ "jp-vehicle-costs",
+ "jp-living-costs",
+ "all"
+]resolve_fact1 field changedInput schema / properties / namespace / enumPrevious value: -[
- "de",
- "eu",
- "uk",
- "us"
-]New value: +[
+ "de",
+ "eu",
+ "jp",
+ "uk",
+ "us"
+]what_changed_since1 field changedInput schema / properties / area / enumPrevious value: -[
- "uk-rates",
- "uk-exams",
- "vehicles",
- "software-eol",
- "policy-rates",
- "us-rates",
- "de-rates",
- "uk-vehicle-rules",
- "uk-exam-dates",
- "calendar",
- "uk-gov-process",
- "all"
-]New value: +[
+ "uk-rates",
+ "uk-exams",
+ "vehicles",
+ "software-eol",
+ "policy-rates",
+ "us-rates",
+ "de-rates",
+ "uk-vehicle-rules",
+ "uk-exam-dates",
+ "calendar",
+ "uk-gov-process",
+ "jp-vehicle-costs",
+ "all"
+]get_factresolve_factwhat_changed_sinceCurrent UK tax-year rates and thresholds, verified against gov.uk with source URLs and dates.
Cited official data: tax, VAT, CPI, policy rates, wages, holidays, FX. 128 countries+EU, 7 regions.
Sourced, date-aware UK tax and payroll rates, deadlines and UK business checks, with GOV.UK sources.
Read-only Canadian GST/HST rates, small-supplier check and CRA allowance rates, with CRA sources.
Add one secure layer between your agents and this server.
