Verified facts for AI agents: rates, exams, recalls, holidays, and what changed since your cutoff.
Scored across 11 tools
The descriptions do a lot of work to separate the tools (call for the long tail, get_fact for exact keys, resolve_fact for discovery), but boundaries still blur: uk_rates_lookup, take_home_pay and exam_topic_paper are exposed directly while also being reachable through call, and catalogue vs coverage both answer 'what is available?' get_fact, resolve_fact and uk_rates_lookup can all surface the same UK rate, so an agent must read carefully to pick.
All names are snake_case, which is consistent at the character level, but the conventions are mixed: verb_noun (get_fact, resolve_fact, take_home_pay, what_changed_since), noun-only (catalogue, coverage, call), and noun_phrase (uk_rates_lookup, domain_provenance, exam_topic_paper). Readable, but not a single predictable pattern an agent can extrapolate from.
Eleven front-door tools is a sensible scope for a verified-facts service. The caveat is that call is an escape hatch to dozens of inner tools (stats, vehicles, rates, calendar, etc.), so the effective surface is much larger than the front door suggests, mitigated by catalogue and coverage for discovery.
For a read-only verified-data server the lifecycle is well covered: discovery (catalogue, coverage), key resolution (resolve_fact), retrieval (get_fact) and shortcuts (uk_rates_lookup, take_home_pay, exam_topic_paper), freshness (what_changed_since), provenance (domain/package), and a dispatcher for the tail. Minor gaps: not every advertised dataset has a directly callable tool at the front door, and there is no bulk/namespace-listing retrieval beyond resolve_fact.
Run any Data Butler tool by name — the long tail not listed here: exam_spec_lookup, exam_paper_index; exact statistics (distribution, hypothesis_test, confidence_interval, bayes_update, linear_regression, descriptive_stats); the vehicles hub (uk_mot_reliability, uk_recalls_for_model, uk_recalls_search, fr_recalls_for_model, fr_recalls_search, jp_recalls_for_model, jp_complaints_summary); software end-of-life (support_status {product, version}, support_timeline {product} for nodejs, python, ubuntu, debian, android, ios, macos, windows, oracle-jdk, go, ruby, php, postgresql, react); policy_rate (Bank of England Bank Rate, Fed federal funds target range, ECB key rates — committed data verified against the banks' own pages); us_rates_lookup (US federal rates and thresholds for the current tax year: income-tax, social-security, medicare, retirement, hsa, estate-gift); de_rates_lookup (German tax and social-insurance figures for the current Veranlagungszeitraum: income-tax, social-insurance, minimum-wage, minijob, kindergeld, kinderfreibetrag, sparer-pauschbetrag, arbeitnehmer-pauschbetrag, entfernungspauschale); uk_vehicle_rules_lookup (UK car tax: first-year CO2 bands, standard rate, expensive car supplement, 2001–2017 bands, pre-2001 rates, electric cars, historic vehicles; MOT due dates, fees, retests, penalties — verified against gov.uk); UK exam dates (uk_exam_dates {kind: results|timetable|deadlines|spec-changes, board?, qualification?}); calendar facts (calendar_facts {country, kind: holidays|tax-year|dst, year?, region?} and next_holiday {country, from?} — holidays for uk, us, de, fr; tax years and DST for uk, us, de, fr, au, in, ca, br, pl; 2026–2028); uk_gov_process (UK government services — passport and ETA fees, driving licence renewal, SORN, register to vote, birth/death registration, Self Assessment deadlines, NI number, Universal Credit, EU Settlement Scheme, eVisa — fees, processing times, start URLs, dated changes, verified against gov.uk); jp_vehicle_costs_lookup (Japan 車検 statutory costs and car taxes: weight-tax, weight-tax-eco, cali, inspection-fee, auto-tax, kei-tax — verified against MLIT, FSA, NALTEC and local-government pages); jp_living_costs_lookup (Japan minimum wage by prefecture, 協会けんぽ rates, pensions, employment insurance, benefits, 2027 holidays, consumption tax, income-tax deductions, resident tax — verified against MHLW, NTA, 総務省, 内閣府, こども家庭庁, 日本年金機構 and 協会けんぽ pages). uk_rates_lookup, domain_provenance, package_provenance and take_home_pay are listed directly. See catalogue for schemas. The result carries the inner tool's freshness and cite.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | tool name from catalogue | |
| arguments | No | that tool's arguments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value annotations cannot: 'The result carries the inner tool's freshness and cite', telling the agent the proxy forwards metadata from the inner tool. It stops short of disclosing error propagation or argument-validation behavior.
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 essential routing rule is front-loaded in the first clause, which is good. But the body is a single enormous paragraph enumerating dozens of tools and their fields, largely duplicating what the sibling `catalogue` tool exists to provide — useful at selection time, yet far from tight.
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 proxy/dispatcher with a nested arguments object and no output schema, the definition covers what an agent needs: which names are valid, which tools bypass it, where schemas live, and that freshness/citation metadata rides along. It lacks only failure-mode behavior for inner-tool errors.
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 'tool' and 'arguments' are already documented — that alone would be a baseline 3. The description earns the extra point by enumerating concrete valid tool names and their key arguments (e.g., support_status {product, version}, calendar_facts {country, kind, year?, region?}), which is exactly the information the bare schema lacks.
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 — 'Run any Data Butler tool by name' — and explicitly scopes itself to 'the long tail not listed here', naming uk_rates_lookup, domain_provenance, package_provenance and take_home_pay as tools that are listed directly. That differentiation lets an agent decide between this dispatcher and its siblings without opening a schema.
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 implies the when-to-use rule clearly: reach for `call` only for tools not exposed directly, and it points to `catalogue` for schemas. What's missing is explicit guidance on when a listed sibling like get_fact or resolve_fact should be preferred over routing the same intent through `call`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool across all Data Butler servers (UK rates; UK exams; provenance; exact statistics; vehicles: UK MOT, UK, French and Japanese recalls; take-home pay for ten countries; software support status and end-of-life timelines for 14 runtimes and operating systems; central-bank policy rates: Bank of England, Fed, ECB; US federal rates and thresholds (us_rates_lookup: income tax, Social Security, Medicare, retirement, HSA, estate and gift); German tax and social-insurance figures (de_rates_lookup: Einkommensteuertarif, Sozialversicherung, Mindestlohn, Minijob, Kindergeld, Kinderfreibetrag, Pauschbeträge, Entfernungspauschale); UK vehicle tax (VED) and MOT rules; UK exam dates and spec changes: results days, the summer 2027 timetable, entry deadlines, new specifications; calendar facts: public holidays, tax-year starts and daylight-saving switches for 2026–2028; UK government services: passport, driving licence, vehicle tax/SORN, voting, birth/death registration, Blue Badge, Self Assessment, NI number, Universal Credit, EU Settlement Scheme, eVisa, ETA; Japan vehicle statutory costs (jp_vehicle_costs_lookup: 自動車重量税, エコカー減税, 自賠責保険, 検査手数料, 自動車税, 軽自動車税); Japan daily-life official figures (jp_living_costs_lookup: 最低賃金, 健康保険料率, 年金, 雇用保険, 児童手当, 高額療養費, 祝日, 消費税, 基礎控除, 住民税)), with input schemas — including tools not listed at this front door. Optional query filters by keyword. Run any of them with call, or connect to serverUrl directly.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | keyword filter, e.g. regression, exam, npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description usefully adds that the catalogue includes 'tools not listed at this front door' and that filtering is optional, but says nothing about the shape or size of the returned listing beyond 'with input schemas'.
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 bulk of the description is a multi-hundred-word enumeration of every server's datasets and figures, front-loaded before any statement of what the tool actually does. The core instructions ('filters by keyword', 'run with call') are buried at the end, and most listed figures are irrelevant to selecting this single-parameter tool.
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 discovery tool with a single optional parameter, no output schema, and full annotation coverage, the description gives enough domain breadth to know what topics are reachable and how to execute a found tool via `call`. Only the precise return structure is left implicit, which is a minor gap here.
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% and the schema itself gives a keyword example ('regression, exam, npm'). The description only restates 'Optional query filters by keyword', adding no semantics about matching behavior (e.g. substring vs. topic labels) beyond what the schema provides. Baseline 3 applies.
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 makes clear this is a front-door catalogue exposing every tool across the Data Butler servers 'with input schemas', and it explicitly routes execution to the sibling `call` tool. However, the purpose is delivered through a sprawling enumeration rather than a direct verb-first statement, so the agent must infer 'lists/discover tools' from context.
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 states the follow-up action ('Run any of them with call, or connect to serverUrl directly') and that the query parameter optionally filters by keyword, which implies when to use it for discovery. But there is no explicit 'use this when you don't know the tool name' guidance or exclusion against calling domain tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exactly what Data Butler covers and does not, per area, including figures it does not serve yet. Areas: uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process, jp-vehicle-costs, jp-living-costs (omit for all). Returns rate categories and tax years, boards/subjects, package ecosystems, stats operations, vehicle datasets, take-home-pay countries, the 14 software products with end-of-life data, central-bank policy rates (boe, fed, ecb), US federal rate categories and tax year, German rate categories and Veranlagungszeitraum, UK vehicle tax (VED) and MOT rule categories, UK exam dates (results, timetable, deadlines, spec-changes for jcq, aqa, pearson, ocr, wjec-eduqas; sqa results day), calendar facts: public holidays (uk, us, de, fr), tax years and daylight saving (uk, us, de, fr, au, in, ca, br, pl) for 2026–2028, UK government services (passports, DVLA, voting, registrations, Self Assessment, benefits, eVisa, ETA), Japanese vehicle statutory cost categories (weight tax, 自賠責, inspection fees, car taxes), Japanese daily-life figure categories (minimum wage, health insurance, pension, employment insurance, benefits, holidays, consumption tax, income tax, resident tax), and an explicit notCovered list.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process, jp-vehicle-costs, jp-living-costs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the response: per-area coverage plus an explicit notCovered list, which is important for a tool whose output has no schema.
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 purpose is front-loaded, but the second sentence is a ~150-word run-on that re-enumerates nearly every dataset the tool itself will report back. That content duplicates the return payload rather than guiding invocation, making the definition hard to scan.
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 single-optional-param, no-output-schema tool with full annotation coverage, the description is close to complete: it names the areas, the default behavior, and the notCovered guarantee. Only the sibling-comparison gap keeps it from a 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% and the single param already lists valid area values, so baseline would be 3. The description earns an extra point by clarifying the omit-for-all default behavior, which the schema description does not state, though it adds no further area-specific semantics.
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 intent: an introspection tool reporting what Data Butler covers and does not, per area, plus a notCovered list. The verb/resource pair is clear, but it never distinguishes itself from siblings like catalogue or domain_provenance, which could plausibly serve overlapping discovery needs.
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 parenthetical '(omit for all)' is a genuine usage instruction, and 'including figures it does not serve yet' hints at the pre-call check use case. However, there is no explicit statement of when to call this versus catalogue or domain_provenance, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who runs this domain? Live RDAP lookup: registration date and age, registrar, nameservers, status, whether the registrant is redacted, plus a typosquat check (edit-distance / brand-substring) against high-value brands. A very recently registered domain resembling a bank or big brand is a classic phishing signal — but report it as a signal, not a conclusion.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent and open-world behavior, so the description is not carrying the safety burden. It adds real value beyond them by disclosing the returned data set (registration age, registrar, nameservers, status, registrant redaction) and the edit-distance/brand-substring typosquat logic, plus an interpretation caveat. It omits failure behavior (e.g. no RDAP record, rate limiting).
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 question, then mechanism, then outputs, then the interpretive caveat. Three sentences, each carrying distinct information with no repetition of the name or title.
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 compensates by enumerating what the lookup returns, and the single parameter is trivial. For a one-argument read-only lookup, an agent has everything needed to call it and interpret the result.
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?
Single required 'domain' parameter with 100% schema description coverage, so the schema already documents the input. The description adds no format or normalization guidance beyond the schema's 'example.com' example — baseline 3 applies.
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 question ('Who runs this domain?') and a concrete mechanism ('Live RDAP lookup'), then enumerates the resource attributes returned (registration date/age, registrar, nameservers, status, redaction) plus a typosquat check. The domain-vs-package distinction from the sibling package_provenance is obvious from the resource itself.
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?
Gives clear usage context — recently registered domains resembling banks or big brands as a phishing signal — and instructs how to report the result ('as a signal, not a conclusion'). It does not name alternatives or state exclusions, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which exam paper is a topic on? The canonical student revision question ("is electricity paper 2 AQA?" — answer: no, Paper 1). Input a topic plus optional board/subject/level; returns the paper, sibling topics on that paper, spec code, and the official spec URL. Knows quirks like AQA Combined Science Trilogy Physics Paper 2 having no Space physics. Coverage: AQA GCSE Physics (8463); AQA GCSE Biology (8461); AQA GCSE Chemistry (8462); AQA GCSE Combined Science: Trilogy (8464); AQA GCSE Mathematics (8300).
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | e.g. aqa | |
| level | No | e.g. gcse | |
| topic | Yes | e.g. electricity, forces, ecology, organic chemistry | |
| subject | No | e.g. physics, combined science |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuine value beyond that: it discloses known data quirks (AQA Combined Science Trilogy Physics Paper 2 has no Space physics) and an explicit board/subject coverage boundary, which an agent needs to avoid over-trusting 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?
The core answer is front-loaded as a one-line question, then the return shape, then the coverage list. Every sentence earns its place except the coverage enumeration, which is dense but genuinely useful for scoping. Slightly long, 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 compensates by naming exactly what is returned (paper, sibling topics, spec code, official spec URL) and disclosing board/subject coverage limits. For a 4-parameter lookup tool with full schema coverage and read-only annotations, this is nearly complete; only ambiguity handling (e.g. unknown topics, wrong-board inputs) is unaddressed.
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 all four parameters carry their own examples in the schema, so the baseline is 3. The description restates the same fields ("topic plus optional board/subject/level") without adding syntax, casing normalization, or matching behavior (e.g. whether 'aqa' vs 'AQA' matters), so it adds no meaning beyond the schema.
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 opens with a concrete question-answer framing ("Which exam paper is a topic on?") and enumerates the returned fields (paper, sibling topics, spec code, spec URL), so the resource and output are unambiguous. It does not explicitly distinguish itself from siblings exam_paper_index or exam_spec_lookup, whose names suggest overlapping territory (spec codes/URLs), so it stops short of a 5.
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 gives a canonical call example ("is electricity paper 2 AQA?" → no, Paper 1) and states the input shape (topic plus optional board/subject/level), which makes the usage context clear. The explicit coverage list also tells the agent when the tool applies and when it will not. No alternative tool or exclusion condition is named, but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 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 establish read-only, idempotent, non-destructive, closed-world behavior, and the description goes well beyond them: it discloses the response shape (verified date, source URL, applicable period, signature), the `stale` flagging behavior driven by max_age, batch semantics, candidate-key fallback on ambiguity, and the coverage boundary. That is substantive behavioral context not present in the 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?
Purpose is front-loaded, then key format, then modifiers, then coverage — a sensible order with no wasted framing. It is dense and example-heavy (seven worked keys, including a deep path), which is mildly redundant but defensible for demonstrating the key grammar; a little trimming would tighten it further.
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 four parameters, no output schema, and no enum guidance, the description carries the load well by describing return contents, staleness behavior, and multi-key batching. The one loose thread is the closing '`coverage` lists the rest', which references something not exposed as a parameter and is ambiguous without further context.
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 schema already documents all four parameters; the baseline would be 3. The description still adds meaning the schema lacks — that comma-separated keys produce a batch return, and that max_age marks the answer `stale` rather than filtering or erroring — which is genuine semantic value beyond the field definitions.
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 a specific verb (get) and an exhaustively enumerated resource — 'one official figure by key — a tax threshold, rate, allowance, fee, deadline, limit or policy rate' — plus what comes back with it. An agent can tell this is a single-key fact lookup rather than a search or history tool without opening the schema.
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 explains batch usage (comma-separated keys) and the ambiguity/degradation path ('a loose key is resolved when unambiguous; otherwise the answer lists candidate keys'), which implies when a resolve step is needed but never routes to the resolve_fact sibling explicitly. No statement of when to prefer this over resolve_fact or what_changed_since, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who publishes this package, and is it a typosquat? Live npm or PyPI lookup: first-publish date and age, release count, latest version, maintainers/author, linked repo, plus a typosquat check against popular package names. Use when an agent is about to install or recommend an unfamiliar dependency.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | package name, e.g. express or requests | |
| ecosystem | Yes | npm or pypi |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: this is a live network lookup (freshness/latency implication) and it enumerates the fields returned, including a typosquat heuristic. It does not mention failure modes for unknown packages.
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 two questions an agent actually has, then the data returned, then the usage condition. Dense but every clause carries information; the interrogative opener is slightly less efficient than a declarative verb phrase.
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 compensates by enumerating the returned fields (first-publish date/age, release count, latest version, maintainers, linked repo, typosquat result) and the scenario that warrants a call. Nothing an agent needs to decide or invoke 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 description coverage is 100% with only two parameters, so the schema already documents name and the npm/pypi enum. The description reinforces the ecosystem scope but adds no syntax, format, or edge-case detail beyond it; baseline 3 applies.
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 (publishers of a package, typosquat status) plus the exact lookup source (live npm or PyPI). It is clearly distinguishable from the sibling domain_provenance because it names the artifact type it operates on.
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?
"Use when an agent is about to install or recommend an unfamiliar dependency" gives a concrete triggering condition. There are no explicit exclusions or alternatives named, but the context is unambiguous.
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.
Net salary after income tax and social contributions for an employee in one of ten countries (uk, us, ca, au, in, br, pl, fr, de, es), computed live by the LifeByNumbers salary calculators (same operator). Takes a gross salary in local currency (annual by default, or monthly with period) and a country code, plus optional state and filingStatus for the US, province for Canada, region (england|scotland) for the UK and region (madrid|cataluna) for Spain. Returns gross, net and total deductions (each annual and monthly), a line-by-line breakdown typed as tax / social / contribution / repayment, effectiveRate, the tax year the figures apply to, currency, the assumptions behind the estimate and the upstream calculator page as source.
| Name | Required | Description | Default |
|---|---|---|---|
| gross | Yes | gross salary in local currency, annual unless period is monthly, e.g. 50000 | |
| state | No | US only: two-letter state code, e.g. TX (default CA) | |
| period | No | period of gross (default annual); results always give both annual and monthly | |
| region | No | UK: england | scotland | wales | northern-ireland (scotland applies Scottish income tax bands; default england). Spain: madrid | cataluna, the autonomous community whose IRPF scale applies (default madrid) | |
| country | Yes | ISO 3166-1 alpha-2, lower case: uk, us, ca, au, in, br, pl, fr, de, es | |
| province | No | Canada only: two-letter province/territory code, e.g. BC (default ON) | |
| filingStatus | No | US only (default single) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description goes further by disclosing that figures are computed live upstream, that results include the tax year, currency, underlying assumptions and a source page, which tells the agent how much to trust and cite the output. It stops short of noting edge cases such as unsupported gross ranges or failure behavior.
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 dense but well-ordered sentences: purpose first, then inputs, then return shape. Every clause carries information, though the return-value enumeration is long enough that it verges on a wall of text for a single paragraph.
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 must describe return values and does so thoroughly (gross/net/deductions annual and monthly, typed breakdown, effectiveRate, tax year, currency, assumptions, source). Combined with full schema coverage and annotations covering safety, an agent has everything needed to call and interpret it.
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 largely carried by the schema and baseline is 3. The description adds country-to-parameter mapping but is slightly narrower than the schema (it lists only england|scotland and madrid|cataluna while the enum also includes wales and northern-ireland), so it does not meaningfully exceed the schema's own documentation.
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 ('net salary after income tax and social contributions') with an explicit scope (ten named countries) and provenance (LifeByNumbers calculators). An agent can distinguish it from rate-lookup siblings like uk_rates_lookup or get_fact without opening the schema.
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?
Implicitly tells the agent this is the tool for take-home pay questions and clarifies which optional parameters apply per country (US state/filingStatus, CA province, UK region, ES region). However, it never says when to prefer this over siblings such as uk_rates_lookup, nor states exclusions or preconditions, so selection remains partly inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current UK (2026-27) rates and thresholds, verified against gov.uk with source URLs and verification dates. Categories: income-tax, national-insurance, minimum-wage, student-loans, vat, isa, state-pension, state-pension-age, stamp-duty, capital-gains, pensions, dividends, savings, marriage-allowance, statutory-sick-pay, statutory-parental-pay, child-benefit. Covers UK income tax, National Insurance, minimum wage, student loans, VAT, ISAs, pensions, stamp duty, capital gains, dividends, savings, the State Pension and State Pension age, statutory sick/maternity/paternity pay and Child Benefit.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | one of: income-tax, national-insurance, minimum-wage, student-loans, vat, isa, state-pension, state-pension-age, stamp-duty, capital-gains, pensions, dividends, savings, marriage-allowance, statutory-sick-pay, statutory-parental-pay, child-benefit (omit to list all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a closed-world scope, so safety is covered for free. The description adds genuine value beyond that: data is verified against gov.uk, accompanied by source URLs and verification dates, and pinned to the 2026-27 tax year. That provenance and freshness context 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?
The verification claim is front-loaded and useful, but the category list is written out twice — once as slugs and once as prose ('Covers UK income tax, National Insurance, minimum wage...'). That second sentence largely restates the first and consumes most of the description without adding new 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?
This is a low-complexity, read-only, single-optional-parameter tool with full schema coverage, so little is required. The description covers data scope, provenance, and tax year, but with no output schema it never sketches the return shape (keys, per-category structure, how sources/dates are presented), leaving the agent to discover the payload blind.
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 single category parameter already enumerates its legal values. The description's category list duplicates the schema rather than adding syntax, defaults, or error behavior. With the schema fully carrying parameter meaning, baseline 3 is appropriate.
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 a specific resource (current UK 2026-27 rates and thresholds) and frames it as a verified lookup against gov.uk. It covers 17 named categories, so an agent knows exactly what domain content it returns. It stops short of distinguishing itself from siblings like get_fact, resolve_fact, or take_home_pay, which is the only thing keeping it from a 5.
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 statement of when to use this tool versus alternatives. Siblings such as get_fact, resolve_fact, and take_home_pay overlap in the 'answer a UK factual question' space, and the description gives no routing guidance. The only usage hint ('omit to list all') lives in the schema, not the description.
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), 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) and Japanese minimum wages by prefecture, 協会けんぽ health insurance rates, 雇用保険料率 and income-tax deductions 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, 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?
With readOnly/idempotent annotations already covering the safety profile, the description still adds real behavior: a hard coverage floor of 2026-08-31, the entry shape (from → to, effectiveFrom, source, verifiedDate, maintainer note), and the Verified Changes protocol doc plus human-facing URL/feeds. It does not state what an out-of-range `since` returns, but the substantive additions are well above the annotation baseline.
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 purpose is front-loaded and the tail (coverage start, output protocol, sibling linkage) earns its place, but the middle is a single ~200-word run-on enumeration of dozens of dataset names and jurisdictions. That list helps coverage assessment yet is far denser than needed and would be better grouped or left largely to the area enum.
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 read-only changelog tool with no output schema, the description covers return shape (entry fields, protocol, factKey), coverage boundaries, and downstream tool routing. The only gap is undefined behavior for dates before the coverage floor or an invalid/earlier-than-supported `since`.
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% and the `area` enum is fully documented in the schema, so the description's repetition of the area list is redundant rather than additive. The one genuine addition is guidance that `since` should be your training cutoff, which clarifies intent beyond the schema's 'ISO date YYYY-MM-DD' — baseline 3 with a small bump, still not more.
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 ('what has changed ... since a date') and immediately scopes it to Data Butler's verified datasets, then enumerates exactly which dataset families are covered. An agent can decide coverage without opening the schema, and the closing mention of get_fact for factKey lookups separates it from its siblings.
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?
'Pass your training-cutoff date to learn which ... changed after your knowledge ends' gives a concrete usage trigger and even the intended value for `since`. It also signals the handoff to get_fact for individual facts, but it never says when NOT to call it (e.g. a date before the 2026-08-31 coverage floor, or use get_fact/resolve_fact for a single known figure).
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.
take_home_pay2 fields changedInput schema / properties / region / descriptionPrevious value: -"UK only: scotland applies Scottish income tax bands (default england)"New value: +"UK: england | scotland | wales | northern-ireland (scotland applies Scottish income tax bands; default england). Spain: madrid | cataluna, the autonomous community whose IRPF scale applies (default madrid)"Input schema / properties / region / enumPrevious value: -[
- "england",
- "scotland",
- "wales",
- "northern-ireland"
-]New value: +[
+ "england",
+ "scotland",
+ "wales",
+ "northern-ireland",
+ "madrid",
+ "cataluna"
+]coverage1 field changedInput schema / properties / area / descriptionPrevious value: -"one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process, jp-vehicle-costs"New value: +"one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process, jp-vehicle-costs, jp-living-costs"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"
+]coverage1 field changedInput schema / properties / area / descriptionPrevious value: -"one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process"New value: +"one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process, jp-vehicle-costs"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_factcoverage1 field changedInput schema / properties / area / descriptionPrevious value: -"one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar"New value: +"one of uk-rates, uk-exams, provenance, stats, vehicles, tax, software-eol, policy-rates, us-rates, de-rates, uk-vehicle-rules, uk-exam-dates, calendar, uk-gov-process"uk_rates_lookup1 field changedInput schema / properties / category / descriptionPrevious value: -"one of: income-tax, national-insurance, minimum-wage, student-loans, vat, isa, state-pension, stamp-duty, capital-gains, pensions (omit to list all)"New value: +"one of: income-tax, national-insurance, minimum-wage, student-loans, vat, isa, state-pension, state-pension-age, stamp-duty, capital-gains, pensions, dividends, savings, marriage-allowance, statutory-sick-pay, statutory-parental-pay, child-benefit (omit to list 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",
- "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",
+ "all"
+]callcataloguecoveragedomain_provenanceexam_topic_paperpackage_provenancetake_home_payuk_rates_lookupwhat_changed_sinceCited US recall lookup for AI agents: CPSC and FDA data, nothing invented.
Official data for AI assistants: medicines, recalls, cosmetics, money, travel, places, prices.
A knowledge base of verified, dated facts your LLM would otherwise get wrong.
Macroeconomic and market data for AI agents: rates, credit, volatility, calendars and screeners.
Add one secure layer between your agents and this server.
