New US liquor license filings: coverage, business lookup, county activity, timing.
Scored across 6 tools
Each tool has a distinct role: state coverage, pricing, single-business lookup, county-level aggregate stats, timing metrics, and a sample dump. The only mild overlap is that county_activity, find_license, and sample_filings all surface filing data, but their granularities (aggregate vs. single record vs. demo sample) are stated clearly enough to disambiguate.
All names are consistently snake_case and readable. The pattern is not strictly verb_noun (find_license and list_states are, but county_activity, license_timing, sample_filings are noun phrases and plans is a bare noun), though the deviation is minor and uniform in style.
Six tools is well within the ideal band and each earns its place: discovery, sampling, lookup, aggregate research, timing, and pricing are all distinct capabilities. Nothing appears redundant or padded.
The surface covers the buy/browse lifecycle of a data feed: state discovery, sample data, per-business lookup, county aggregates, timing benchmarks, and plans. Gaps exist (no way to retrieve full records/addresses/contacts or query by license type or date range), but these are largely gated behind the paid feed and agents can work around them for evaluation.
New liquor license filings in one county in the last 30 days, with its most common license types and cities, and how many were changes of ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. TX | |
| county | Yes | County or parish name, e.g. Harris |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavioral context: the fixed 30-day window and the fact that results are aggregated into top-N license types, top cities, and an ownership-change count rather than raw records. It does not say what happens for a county with zero filings or whether aggregates are truncated.
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?
A single sentence with no filler, front-loading the resource and the time window. It is slightly overstuffed with the trailing list of aggregate outputs, but every clause carries 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?
With no output schema, the description carries the burden of describing returns and does so adequately by naming the summarized fields. For a two-parameter, read-only, closed-world aggregate tool this is close to sufficient; only edge-case behavior (empty results, top-N limits) is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both state and county documented including examples, so the baseline is 3. The description adds only the mild implication that a single county is targeted and that no date parameters exist because the window is fixed; it contributes no formatting or matching guidance 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 names a specific resource (new liquor license filings) with a precise scope (one county, last 30 days) and enumerates what the response summarizes: top license types, top cities, and change-of-ownership counts. It is clearly distinct from siblings like find_license or list_states, though it never explicitly names those alternatives to sharpen the contrast.
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 only implied: an agent can infer this is the aggregate/overview tool for a single county's recent activity, as opposed to a single-record lookup. There is no explicit statement of when to prefer it over sample_filings or find_license, and no note about prerequisites such as the county needing to exist in the dataset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one business by name in a state's liquor license filings: its license type, status, place and date. Sorted by name; address and contacts are on the paid feed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Business or trade name, at least three letters | |
| state | Yes | Two-letter state code, e.g. TX |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description needn't re-establish safety. It adds real context beyond that: results are sorted by name, and address/contact fields are deliberately excluded from this feed, which tells the agent not to expect them. It doesn't address what happens when a name matches multiple businesses, though the sorting hint implies a list.
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 tight sentences, front-loaded with the core action and return fields, followed by the scoping/coverage caveat. No filler or restatement of the 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 only two fully documented parameters and no output schema, the description usefully names the returned fields and notes the paid-feed boundary. The remaining gap is multi-match behavior — whether one exact result or a name-sorted set is returned — which matters for how the agent interprets output.
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%, with both parameters documented including the 'at least three letters' constraint and the two-letter state format. The description adds no syntax or matching rules (exact vs partial name, case sensitivity) beyond what the schema already states, so 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: look up one business by name within a state's liquor license filings. It also enumerates the returned fields (license type, status, place, date), which no sibling tool (county_activity, license_timing, list_states, plans, sample_filings) offers, so an agent can distinguish it immediately.
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 single-business, by-name lookup framing implies when to use it, but there is no explicit when-to-use or when-not guidance and no sibling is named as an alternative for adjacent needs (e.g., aggregate/timing queries). Usage must be inferred from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How long a liquor license takes in a state, measured from filings followed through to the issued license.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. TX |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile and closed-world scope are covered. The description adds real value by disclosing the measurement methodology (cohort of filings tracked through to issuance), which tells an agent the figure is not a simple average of all filings. However, it does not say whether the returned figure is a median, mean, or range, nor what the units are, which is the main behavioral gap.
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?
A single well-formed sentence that front-loads the metric and qualifies it with the measurement method. Nothing is wasted and nothing is buried.
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 one-parameter lookup tool with annotations and a fully described schema, the description is adequate but leaves an agent unable to predict the response — no units, no indication of whether the result is a scalar, a distribution, or a per-license-type breakdown. Given there is no output schema, the description should have carried that information.
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?
Only one parameter, and the schema fully documents it with a two-letter code example. The description adds nothing beyond the schema for parameters, but with a single fully-described parameter there is little left to compensate for.
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 resource (liquor license processing time) and a specific scope (per state), and the measurement definition ('from filings followed through to the issued license') further pins down what is being reported. It does not explicitly differentiate itself from siblings like county_activity or sample_filings, but the metric named is distinct enough that confusion is unlikely.
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 metric definition: ask this when you need a duration for a given state. There is no explicit when-to-use/when-not, no mention of how it relates to state-level vs. county-level siblings, and no guidance on what to do for states without filings data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
States and cities with a daily liquor license feed, how often each one updates, and each state's page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the substantive behavioral detail that matters here: each entry carries update frequency and a state page reference, which compensates for the absence of an output 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?
A single compact sentence with the most important information (what entities, what fields) front-loaded. It is a fragment rather than a complete sentence, but nothing is padded or redundant.
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 no-param, no-output-schema tool the description covers what is returned, which is the core need. It stops short of tying the result to the rest of the workflow - e.g., that the returned state identifiers are what find_license or county_activity expect - which is the one thing an agent would still need to guess.
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?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and it correctly presents this as an unfiltered reference list.
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 the concrete content of the resource - covered states and cities, feed update frequency, and per-state page links - which lets an agent distinguish it from siblings like find_license or county_activity. It is a noun phrase with no verb, so the 'list/retrieve' action is only inferred from the tool name.
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 call this versus the siblings (find_license, license_timing, county_activity). An agent could reasonably guess it is a coverage/discovery tool, but that is inference, not guidance, and no prerequisites or follow-up use is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liquor License Feed plans, prices and trial terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload covers plans, prices and trial terms, which is useful content disclosure, but says nothing about freshness, caching, or return format.
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?
A single short fragment with no filler; the most important noun (plans/prices) leads. It is under-specified rather than verbose, but structurally clean.
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 zero-parameter, read-only, no-output-schema tool, the description names the data it returns (plans, prices, trial terms), which is the main thing an agent needs. A note on return shape would be nice but is not critical 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?
The tool takes zero parameters, so the schema burden is nil and baseline 4 applies. The description correctly implies no input is needed.
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?
It names the resource contents (plans, prices, trial terms) of a Liquor License Feed, but offers no verb and never distinguishes itself from siblings like list_states or license_timing. An agent can guess it returns pricing/trial data, but the purpose is stated as a noun fragment rather than a clear action.
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 indication of when to call this tool versus the other five siblings, and no prerequisites or exclusions. The agent is left to infer that this is the tool for pricing questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Up to 25 filings from one state, from a full week at least a week back, without phones or owners, to show what the feed contains.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. TX |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the result cap of 25, the one-state constraint, the recency window, and the exclusion of phones and owners.
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 definition is a single tightly packed sentence with no wasted clauses. The cap, source scope, recency, omitted fields, and preview purpose are all front-loaded and each clause contributes useful 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?
For a simple read-only sample tool with one required parameter and no output schema, the description gives enough context to call it correctly: result size, state scope, recency, and omitted fields. It does not describe exact returned fields or error behavior, but nothing critical is missing for this tool's purpose.
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 state parameter is already documented as a two-letter state code. The description reinforces that filings come from one state, but adds no syntax, format, or validation detail 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 clearly states what the tool returns: up to 25 filings from one state, drawn from a complete week at least one week old, with phones and owners omitted. It is specific about the resource and scope, but it does not explicitly differentiate this preview/sample tool from siblings such as county_activity or find_license.
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 phrase 'to show what the feed contains' implies the tool is for previewing or sampling feed content. However, the description gives no explicit when-to-use guidance, no exclusions, and does not name alternatives like county_activity or find_license.
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.
county_activityfind_licenselicense_timinglist_statesplanssample_filingsPublic-records leads: trucking insurance signals, liquor licenses, new nonprofits, LLCs, carriers.
Pre-opening US restaurant and bar leads, scored from liquor, permit and business filings.
Restaurants and bars about to open in 22 US metros, from new liquor license filings. No key needed.
Search US TTB alcohol label approvals, permittees and processing times. Read-only; account required.
Add one secure layer between your agents and this server.