Skip to main content
Glama
Sign In

Distill

by com.spencermcw.data
OverviewDiscussionsAdmin

What sales tax applies to each of these orders? Combined and per-jurisdiction rates for up to 100 US addresses, ZIP+4s or ZIPs in one call, 24 Streamlined Sales Tax states, computed by Distill from each state’s SST rate and boundary files

tax_sales_rate_batch

What sales tax applies to each of these orders? Combined and per-jurisdiction rates for up to 100 US addresses, ZIP+4s or ZIPs in one call, 24 Streamlined Sales Tax states, computed by Distill from each state’s SST rate and boundary files. 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. Refreshed quarterly (live freshness: /status). 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". Answers in a summary view of about 3,000 tokens; view: "full" for every row. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "locations": "<locations>"
    },
    "name": "tax_sales_rate_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
viewNosummary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).
locationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / view
      Added value: +{
+  "description": "summary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Beyond the annotations it discloses a lot that matters operationally: $0.1 per call, a 3-call/day free tier capped at 3 rows with an opt-out via _meta['distill/free-tier'] = 'skip', quarterly refresh with a /status freshness check, summary answers budgeted near 3,000 tokens, and per-location error isolation. The only tension is that annotations set readOnlyHint=false for what the text describes as a pure lookup, but the paid-credit consumption arguably justifies that flag, so I do not read it as a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and cost are front-loaded well, but the body buries the actionable parts under long confidence and freshness formulas (agreement × freshness, halving every 30 days, SST posting deadlines) plus legal boilerplate. Those formulas belong in a documentation page; an agent calling the tool needs the cap, price, free-tier rule, and error semantics far more than the derivation of the confidence score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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-value burden and largely does: per-location results in input order, per-location errors, confidence semantics, and summary-vs-full views. What is still missing is the shape of an individual rate row (how combined vs. per-jurisdiction breakdowns are keyed), which an agent would want before parsing results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, and the schema already documents zip format, date window, optional address, and the summary/full enum. The description adds real value on the view parameter by quantifying the summary budget (about 3,000 tokens) and noting the free-tier 3-row cap and that lowering to summary is the default, but it adds nothing about the date or address fields beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the operation (sales tax rates) and the resource shape precisely: combined and per-jurisdiction rates for up to 100 US locations in one call, limited to the 24 Streamlined Sales Tax states. It also positions itself against the sibling by stating it returns 'the same answer as tax.sales_rate for each location, in order,' so an agent can tell batch from single-lookup without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the selection context clear (many locations, one call, one price) and documents per-location failure conditions ('outside the SST states, a bad date') so the agent knows partial failure is not a call failure. It never gives an explicit rule such as 'use tax_sales_rate for a single location,' leaving the batch-vs-single choice to inference from the row cap and per-call price.

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

All Distill toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources