Pre-computed answers with sources and confidence, paid per call over x402 (USDC on Base).
Scored across 7 tools
The two domains (hospital_* vs tax_*) are clearly separated, and tax_sales_rate_batch is obviously the batch form of tax_sales_rate. However hospital_compare and hospital_prices both return statistics over hospitals for a code, and hospital_payers overlaps with hospital_prices' payer detail, so the boundaries require careful reading.
All names use consistent snake_case with a predictable domain prefix (hospital_, tax_), which is easy to parse. Minor deviation in that the segment after the prefix mixes actions and nouns (changes, compare, payers, prices), but the convention is still coherent.
Seven tools is well-scoped for a server covering two sub-domains (4 hospital, 3 tax) with no redundant or filler tools. Each tool serves a distinct query shape (changes, compare, payers, prices, single rate, batch rate).
Core read workflows for both hospital pricing and sales tax are covered, including a batch variant and change feeds. There is no explicit discovery tool for hospital ids or tax jurisdictions, though hospital_prices and the SST state list partly compensate, so this is a minor gap rather than a dead end.
Change records from diffing consecutive weekly builds: a hospital republishing its file (source raw_sha256), items and payer rates that appear, disappear or change price, a hospital’s status or file date changing, and the canonical payer of a payer/plan name changing. Keys: source <source_id>; hospital <hospital id>; item <source_id>|<type>|<code>|<setting>|<billing_class>|<modifiers>; rate <item key>|<payer name>|<plan name>|<methodology> (names as the hospital writes them; one rate per methodology, empty when none is given); plan <payer name>|<plan name>. Money is integer micro-USD (unit usd_micro). Each record cites the sha256 of the file versions it came from. Pages of up to 100, oldest first; pass next_cursor back as cursor. Price: $0.05 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: Change records are diffs of consecutive serving DBs, computed deterministically; confidence is the feed’s freshness only: 1 within 14 days of the newest build, then halving every 30 days. Posted standard charges from hospital machine-readable files (45 CFR 180): posted rates, not a quote; not medical or financial advice. What you pay depends on your plan, your care and the hospital. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records per page (default 100). | |
| since | No | Only records detected at or after this time (ISO 8601). | |
| cursor | No | next_cursor from the previous page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavioral context beyond that: pagination behavior, oldest-first ordering, per-call pricing, free-tier conditions, confidence decay tied to build freshness, and legal caveats about posted rates. It also clarifies that records are deterministic diffs rather than advisory or quote data, which meaningfully informs agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose and then organizes the remaining information into keys, money units, pagination, pricing/free-tier rules, confidence, and legal notes. It is dense but mostly earns its space, though the long single block of text could be structured more easily for an agent 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?
With no output schema, the description carries the return-shape burden and does so well: it defines record categories, composite keys, the usd_micro money unit, sha256 provenance, pagination limits, cursor handling, and confidence semantics. Given the tool's complexity and lack of an output schema, this is complete enough for correct invocation.
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%, so the schema already documents limit, since, and cursor. The description adds relevant pagination semantics by specifying pages of up to 100 are returned oldest first and that next_cursor should be passed back as cursor, which supplements the cursor parameter beyond its schema text.
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 and scope: change records derived from diffing consecutive weekly hospital builds, with enumerated record types such as republished files, item/rate additions/removals/price changes, status changes, and payer-name changes. It is clearly not a current-price or payer-list tool, but it does not explicitly name or differentiate itself from sibling tools like hospital_prices or hospital_payers.
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 by the paged-feed framing and operational notes about cursor reuse, oldest-first ordering, free-tier limits, and row caps. However, the description does not explicitly say when to choose this tool over alternatives such as hospital_prices or hospital_compare, nor does it give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For each named hospital: whether it posts the code, and over its items for the code (only those without modifiers when it posts any, so a professional -26 or bilateral -50 line does not skew the row) nearest-rank statistics of its gross charges, discounted cash prices and negotiated dollar amounts across payers and plans, the range of negotiated percentages, the de-identified minimum and maximum, and the number of payers. The same filters as hospital.prices. Hospital ids come from hospital.prices (or pass a CMS certification number). Not charged when none of the hospitals is known. Price: $0.02 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: Mean over the returned rows (each rate; an item with no rate counts once) of normalize × quality × freshness. Normalize: the stored per-rate normalize confidence (payer canonicalization: rule 1, model 0.9, fallback 0.6; rate basis for rates with no dollar amount: rule 1, model 0.9, fallback 0.75; 1 for an item with no rate). Quality of the MRF: 1 valid against the v3.0 schema, 0.85 parsed with conformance errors, 0.7 parsed only after header repair. Freshness: 1 while the MRF’s last_updated_on is at most 365 days old, then halving every 180 days (0.5 with no date), times 1 within 14 days of our fetch, then halving every 30 days. Rows are each hospital’s items for the code as compared. Posted standard charges from hospital machine-readable files (45 CFR 180): posted rates, not a quote; not medical or financial advice. What you pay depends on your plan, your care and the hospital. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The billing code: CPT (5 characters, e.g. 99213), HCPCS Level II (a letter and 4 digits, e.g. J1885) or MS-DRG (3 digits, e.g. 470). | |
| plan | No | Optional: text the plan name (or payer name) contains as the hospital writes it, case-insensitive, e.g. "PPO" or "Medicare Advantage". | |
| payer | No | Optional: a canonical payer_id (e.g. aetna, cigna, unitedhealthcare, anthem, medicare, medicaid). hospital.payers lists the payers with prices for a code. | |
| setting | No | Optional: inpatient or outpatient (items posted for both always match). | |
| code_type | No | Optional: the code type. Inferred from the code’s shape when omitted. | |
| hospitals | Yes | One to ten hospital ids (e.g. co-060001) or CMS certification numbers, comma-separated. | |
| plan_type | No | Optional: the canonical plan type. | |
| billing_class | No | Optional: facility or professional (items posted for both always match). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/openWorldHint already covering the safety profile, the description adds substantial behavioral context beyond annotations: $0.02 per-call cost, free-tier terms (3 calls/day/IP, max 3 rows, skip meta flag), a full confidence formula with normalize/quality/freshness weights, and the data provenance/disclaimer. This is far richer than the annotations alone.
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 sentence front-loads the core output, but the body is extremely dense, packing the confidence formula, pricing, free-tier rules, and legal disclaimer into one unbroken block. Much of it earns its place behaviorally, yet the formatting is hard to parse and would benefit from structure.
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 an 8-parameter, output-schema-less tool, the description is comprehensive: it explains the returned rows, the statistics computed, filter inheritance, id sourcing, cost, and confidence interpretation. An agent has everything needed to invoke it 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 schema already documents all 8 parameters including enums and patterns, making 3 the baseline. The description adds marginal meaning only, e.g. modifier handling ('only those without modifiers when it posts any') and the hospital.prices filter reuse, but does not extend the individual parameter 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+resource and the exact output: for each named hospital, whether it posts the code plus nearest-rank statistics of gross charges, discounted cash prices, negotiated amounts, the negotiated percentage range, de-identified min/max, and payer count. The scope ('across up to 10 named hospitals, one normalized row each' in the title) clearly distinguishes it from the single-hospital sibling hospital.prices.
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 says 'The same filters as hospital.prices' and that hospital ids come from hospital.prices (or a CMS certification number), which gives useful origin guidance. However, it never explicitly states when to choose this multi-hospital comparison over hospital.prices, and the 'Not charged when none of the hospitals is known' clause is a billing note rather than usage routing. Differentiation is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every payer’s negotiated dollar amounts for the code at the hospitals within the radius, grouped by canonical payer_id (the stable id behind the many ways hospitals write a payer’s name), plan type and methodology (a per diem and a case rate are never pooled): how many hospitals and rates, and nearest-rank statistics. Payers with the most hospitals first. Percentage-only rates are left out (they have no dollar amount; hospital.prices shows them). The payer_ids here are what the payer filter of hospital.prices and hospital.compare takes. Price: $0.02 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: Mean over every rate in the payer rows returned of normalize × quality × freshness, with the same factors as hospital.prices (normalize: the stored per-rate payer canonicalization confidence, rule 1, model 0.9, fallback 0.6; quality: 1 valid v3.0, 0.85 with conformance errors, 0.7 after header repair; freshness: 1 while last_updated_on is at most 365 days old, then halving every 180 days, times 1 within 14 days of our fetch, then halving every 30 days). Posted standard charges from hospital machine-readable files (45 CFR 180): posted rates, not a quote; not medical or financial advice. What you pay depends on your plan, your care and the hospital. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the point (with lon). | |
| lon | No | Longitude of the point (with lat). | |
| zip | No | A 5-digit ZIP code (its Census ZCTA point). Give a zip, or lat and lon. | |
| code | Yes | The billing code: CPT (5 characters, e.g. 99213), HCPCS Level II (a letter and 4 digits, e.g. J1885) or MS-DRG (3 digits, e.g. 470). | |
| setting | No | Optional: inpatient or outpatient (items posted for both always match). | |
| code_type | No | Optional: the code type. Inferred from the code’s shape when omitted. | |
| plan_type | No | Optional: the canonical plan type. | |
| radius_miles | No | Search radius in miles (default 25, at most 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint, yet the description discloses far more: cost ($0.02/call), a free-tier cap (3 calls/day, 3 rows max, consumed unless _meta marks skip), a full confidence formula, the data source and legal framing (45 CFR 180 posted standard charges, not a quote), and the sort order. This is exactly the extra context 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 purpose and payer_ids linkage are correctly front-loaded, but the confidence sentence is a single sprawling parenthetical that packs six nested factors and their weights, which is hard to parse. The pricing/free-tier/legal content is useful but the overall length and density exceed what the task 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?
With no output schema, the description steps in and describes the return shape (per-payer rows with hospital and rate counts plus nearest-rank statistics, sorted by hospital count), the free-tier row cap, and the exclusion of percentage-only rates. It covers what an agent needs to call and interpret the tool, though 'nearest-rank statistics' remains loosely specified.
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 enums on setting, code_type, and plan_type, so the schema already documents every parameter. The description adds only light framing (the code is the subject, radius bounds the search, plan_type is a grouping key) and no format or default details beyond the schema. 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 states a specific verb and resource (negotiated dollar amounts per payer for one billing code within a radius) and names the exact grouping keys: canonical payer_id, plan type, and methodology. It also distinguishes itself from siblings by name, noting that percentage-only rates live in hospital.prices, so an agent can tell the three hospital tools apart 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 gives clear context for selection: use this for the payer/plan-type breakdown, and it explicitly routes percentage-only rates to hospital.prices. It also explains that the returned payer_ids are the ones the hospital.prices and hospital.compare payer filters accept, which is actionable linkage. It stops short of an explicit 'use this instead of X when Y' exclusion, so it is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
From the machine-readable standard-charge files hospitals must publish (45 CFR 180), parsed and normalized: for each hospital within the radius that posts the code, nearest first, the gross charge, the discounted cash price, the de-identified minimum and maximum, and every payer and plan’s negotiated dollar amount or percentage (with the v3.0 median, 10th and 90th percentile allowed amounts), payers canonicalized to a stable payer_id. Filters: payer, plan type, plan name text, setting, billing class. A summary gives nearest-rank statistics over the hospitals returned. Served states: Colorado. An area with no hospital posting the code answers 404 and is not charged. Price: $0.02 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: Mean over the returned rows (each rate; an item with no rate counts once) of normalize × quality × freshness. Normalize: the stored per-rate normalize confidence (payer canonicalization: rule 1, model 0.9, fallback 0.6; rate basis for rates with no dollar amount: rule 1, model 0.9, fallback 0.75; 1 for an item with no rate). Quality of the MRF: 1 valid against the v3.0 schema, 0.85 parsed with conformance errors, 0.7 parsed only after header repair. Freshness: 1 while the MRF’s last_updated_on is at most 365 days old, then halving every 180 days (0.5 with no date), times 1 within 14 days of our fetch, then halving every 30 days. Posted standard charges from hospital machine-readable files (45 CFR 180): posted rates, not a quote; not medical or financial advice. What you pay depends on your plan, your care and the hospital. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the point (with lon). | |
| lon | No | Longitude of the point (with lat). | |
| zip | No | A 5-digit ZIP code (its Census ZCTA point). Give a zip, or lat and lon. | |
| code | Yes | The billing code: CPT (5 characters, e.g. 99213), HCPCS Level II (a letter and 4 digits, e.g. J1885) or MS-DRG (3 digits, e.g. 470). | |
| plan | No | Optional: text the plan name (or payer name) contains as the hospital writes it, case-insensitive, e.g. "PPO" or "Medicare Advantage". | |
| limit | No | How many hospitals to return, nearest first (default 10, at most 50). | |
| payer | No | Optional: a canonical payer_id (e.g. aetna, cigna, unitedhealthcare, anthem, medicare, medicaid). hospital.payers lists the payers with prices for a code. | |
| setting | No | Optional: inpatient or outpatient (items posted for both always match). | |
| code_type | No | Optional: the code type. Inferred from the code’s shape when omitted. | |
| plan_type | No | Optional: the canonical plan type. | |
| radius_miles | No | Search radius in miles (default 25, at most 100). | |
| billing_class | No | Optional: facility or professional (items posted for both always match). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint=false; the description adds substantial context the annotations cannot: $0.02 per call pricing, the 3-free-calls-per-day IP tier, the 'skip' meta flag, 404 semantics, and a full confidence model (normalize × quality × freshness). This is far beyond what structured fields convey and is consistent with 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?
The description is one dense paragraph carrying high-value operational facts (pricing, free tier, 404) that are buried after the return-field list and before a very granular freshness-halving formula. The confidence math (halving every 180/30 days) is arguably documentation-grade detail rather than selection-critical text, hurting front-loading.
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, and the description compensates by enumerating the returned fields (gross charge, discounted cash, min/max, negotiated amounts, v3.0 median/percentiles) and the summary statistics. For a 12-parameter, pay-per-call tool, an agent has everything needed to call it 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 description coverage is 100%, so the schema already documents all 12 parameters with patterns, enums and examples. The description restates the filter set (payer, plan type, plan name, setting, billing class) without adding format or default detail beyond the schema. 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?
States a specific verb and resource up front: returns posted hospital standard charges for one billing code near a ZIP or point, nearest first. The scope (one code, geographic radius, MRF-sourced charges) is precise enough to separate it from hospital_compare and hospital_payers without opening any 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?
Gives clear context (one code near a location, with filters) and explicitly routes to a sibling: 'hospital.payers lists the payers with prices for a code.' It also states the 404/no-charge behavior and free-tier limits, which guide invocation. It stops short of an explicit when-to-use-this-vs-hospital_compare statement, so it is strong but not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change records read from the states’ rate and boundary files: rates that change, begin or end; ZIP+4 and 5-digit ZIP ranges whose jurisdictions change; new files posted. Each record cites the sha256 of the files it came from. Pages of up to 100, oldest first; pass next_cursor back as cursor. Price: $0.05 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: Freshness only (change records are read from the state files deterministically): 1 until the next SST posting deadline (the 1st of Mar, Jun, Sep or Dec) after the files were last checked, then halving every 30 days. Not tax advice. Rates as published by the state in its Streamlined Sales Tax rate and boundary files for the stated effective period; verify with the state. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | Only records detected after this time (ISO 8601). | |
| state | No | Two-letter state code, e.g. WA. | |
| cursor | No | ||
| entity | No | ||
| effective_from | No | Only changes effective on or after this day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses pricing ($0.05 per call), a free-tier quota (3 calls/day per IP, 3 rows, with the _meta skip escape), deterministic read provenance via sha256, and a detailed freshness/confidence decay model. These are exactly the operational traits an agent cannot get from 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?
It is one dense paragraph, but it is front-loaded with the core purpose and every subsequent clause (pagination, price, free tier, confidence, disclaimer) carries real information. The confidence-decay sentence is verbose but not wasteful given no output schema.
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 does the work of describing return content (record fields, sha256 citation) and pagination, plus operational constraints, so an agent can call it correctly. The remaining gap is the entity enum's precise meaning and how since interacts with effective_from.
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 only 50%, so limit, cursor and entity carry no schema docs. The description compensates partially (page size up to 100, oldest-first ordering, cursor round-trip) and loosely maps entity values via 'rates that change' and 'new files posted', but leaves the enum and the since/effective_from distinction under-explained.
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 opening sentence names a specific resource (change records from the states' rate and boundary files) and enumerates exactly what changes are captured (rate begin/end, jurisdiction shifts, new files). This clearly separates it from the current-rate siblings like tax_sales_rate, since it is a change-history feed rather than a rate lookup.
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: the change-record framing tells an agent it is for tracking what changed, and pagination instructions ('pass next_cursor back as cursor') are given. However, it never explicitly says when to prefer this over tax_sales_rate or tax_sales_rate_batch, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
From the state’s own Streamlined Sales Tax rate and boundary files (24 states: AR, GA, IA, IN, KS, KY, MI, MN, NC, ND, NE, NJ, NV, OH, OK, RI, SD, TN, UT, VT, WA, WI, WV, WY). Matches an address when the state publishes address records, else the ZIP+4 record, else the 5-digit record (the lowest rate in the ZIP, per SSUTA 305). Returns each jurisdiction’s rate, the combined rate, and the period it holds. Locations outside these states answer 404 and are not charged. Price: $0.005 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: agreement × freshness. Agreement: for a 5-digit ZIP answer, the share of that ZIP’s ZIP+4 records with the same combined rate; for a ZIP+4 answer, the share of address records inside it with the same rate; 1 for an address match or when the state publishes nothing finer. Freshness: 1 until the next SST posting deadline (the 1st of Mar, Jun, Sep or Dec) after the files were last checked, then halving every 30 days. Not tax advice. Rates as published by the state in its Streamlined Sales Tax rate and boundary files for the stated effective period; verify with the state. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | A 5-digit ZIP code or a ZIP+4 (98101-3143 or 981013143). | |
| date | No | The sale date, YYYY-MM-DD (default: today, UTC). From the first day of the previous quarter onward. | |
| address | No | Optional street address line with house number, e.g. "1010 E Alder St" or "PO Box 12"; matched against the state address records when it publishes them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint, and the description adds substantial operational context: $0.005 per-call pricing, a 3-free-calls/day per-IP tier with a 3-row cap and an opt-out via _meta, 404 behavior for out-of-scope states, the confidence formula (agreement × freshness) with its decay rule, and data-freshness semantics tied to SST posting deadlines. This is exactly the beyond-annotations disclosure the dimension rewards.
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?
Scope and matching precedence are front-loaded, which is good, but the block is dense and run-on, and the closing legal boilerplate ('Not tax advice… verify with the state. See /terms.') plus the full confidence derivation consume space without helping an agent select or invoke the 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?
There is no output schema, so the description carries the return-value burden and does so: each jurisdiction's rate, the combined rate, the effective period, and how to read the confidence score. Coverage limits, pricing, and out-of-scope behavior are all present, so nothing needed for a correct call 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 already 100%, so the baseline is 3, but the description adds real semantics the schema lacks: why an address is preferred (address records when published, else ZIP+4, else the 5-digit record at the lowest rate in the ZIP per SSUTA 305) and what the date parameter's lower bound implies. That goes beyond restating 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?
States a specific verb and resource — the sales-tax rate at a ZIP+4, ZIP, or street address — and enumerates the 24 covered states, so the agent knows exactly what domain it answers for. It does not, however, name or contrast itself with the sibling tax_sales_rate_batch, leaving the single-vs-batch distinction 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?
Gives a clear usage boundary: the tool applies to the 24 listed SST states, and locations outside them return 404 and are not charged, which is an explicit exclusion. The address/ZIP+4/5-digit matching precedence further tells the agent how to frame a query, though no alternative tool is named for cases this tool can't serve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same answer as tax.sales_rate for each location, in order. A location that fails (outside the SST states, a bad date) carries its own error; the call is still one price. Price: $0.1 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Confidence: The lowest per-location confidence in the batch; each is agreement × freshness. Agreement: for a 5-digit ZIP answer, the share of that ZIP’s ZIP+4 records with the same combined rate; for a ZIP+4 answer, the share of address records inside it with the same rate; 1 for an address match or when the state publishes nothing finer. Freshness: 1 until the next SST posting deadline (the 1st of Mar, Jun, Sep or Dec) after the files were last checked, then halving every 30 days. Not tax advice. Rates as published by the state in its Streamlined Sales Tax rate and boundary files for the stated effective period; verify with the state. See /terms.
| Name | Required | Description | Default |
|---|---|---|---|
| locations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: per-call pricing, free-tier rules, per-location error isolation without failing the whole call, confidence aggregation, agreement and freshness formulas, and data-source caveats. These are exactly the operational details an agent needs before invoking a paid batch lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the batch purpose and pricing, and most sentences carry useful operational information. It is dense and semicolon-heavy rather than cleanly structured, especially around confidence and free-tier mechanics, but there is little pure 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?
For a paid batch tool with no output schema, the description explains ordering, per-location errors, aggregate confidence, and billing/free-tier behavior. It still relies on the sibling tax.sales_rate for the exact returned fields, but the invocation-relevant context is largely covered.
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 reported as 0%, so the description must carry parameter meaning. It partially clarifies that locations can be ZIP/ZIP+4/address matches and that bad dates fail per location, but it does not fully explain the required zip, optional date default/range, address field, or the 100-item limit in parameter terms.
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 precise batch behavior: the same answer as tax.sales_rate for each location, returned in order, with per-location errors. This clearly distinguishes it from the sibling single-location tax_sales_rate tool and the other tax/hospital 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?
It implies batch use for multiple locations and notes failure conditions such as locations outside SST states or bad dates. However, it does not explicitly say to use tax_sales_rate instead for a single location, so the alternative routing is only implicit.
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.
hospital_changeshospital_comparehospital_payershospital_pricestax_changestax_sales_ratetax_sales_rate_batchPay-per-call onchain reads (Base, Ethereum, Gnosis), token verdicts and LLM chat over x402 USDC
Pay-per-call onchain reads (Base, Ethereum, Gnosis), token verdicts and LLM chat over x402 USDC
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
Market and on-chain crypto data for AI agents. Pay per call in USDC on Base (x402).
Add one secure layer between your agents and this server.
