Search, preview and buy CSV datasets of US business locations: dealer networks, contractors, chains.
Scored across 8 tools
Each tool has a distinct resource+action (search, metadata, quote, sample, per-row query, full purchase, checkout, order status). The only real fork is buy_dataset (USDC, whole file) vs create_checkout (Stripe card), and the descriptions disambiguate the two payment paths explicitly. An agent could briefly hesitate between the two purchase routes, but boundaries are otherwise clear.
All eight tools follow a strict verb_noun snake_case pattern: buy_dataset, check_order, create_checkout, get_dataset, get_quote, get_sample, query_locations, search_datasets. Verbs are used consistently and predictably across the set.
Eight tools is well-scoped for a dataset marketplace: discovery (search/get/quote/sample), two purchase paths, a payment status check, and per-row querying. No tool appears redundant or bolted on for the domain.
The surface covers the full browse-to-buy-to-query lifecycle, including pricing preview and order confirmation. Minor gaps: no browse/list-all or category enumeration beyond keyword search, and no way to retrieve an order/download link without the original Stripe session id (mitigated by buy_dataset returning a permanent link).
Buy an ENTIRE dataset outright and get a permanent download link for the CSV. Pays once in USDC on Base, at the same list price a human pays by card — no account and no checkout page.\n\nPrefer this over repeated query_locations calls whenever you want most of a file. Metered queries are priced per row and deliberately cost more than the file if you assemble it that way, so past a few hundred rows buying outright is both cheaper and complete. get_dataset (free) gives the price and record count first.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | Dataset slug, e.g. generac-dealers. Use search_datasets first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the payment rail and currency (USDC on Base), that it is a one-time charge at human list price, and that no account or checkout is needed. It also states what the agent receives (permanent CSV download link), which the readOnlyHint=false annotation alone could not convey.
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?
Three sentences, front-loaded with the action and outcome, then the decision rule, then the prerequisite. No filler; every clause carries either routing or behavioral 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 still explains the deliverable (permanent CSV link), pricing model, and payment path, which is everything an agent needs to call a single-parameter purchase tool 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 single 'dataset' parameter is already fully documented with a slug example and the search_datasets prerequisite. The description adds no further parameter detail, so the 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 ('Buy an ENTIRE dataset outright') plus the concrete outcome ('permanent download link for the CSV'). It clearly distinguishes itself from query_locations (metered) and get_dataset (free price lookup) named in the same text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: prefer this over repeated query_locations when you want most of a file, with the cost rationale (per-row metering costs more past a few hundred rows). It also names get_dataset as the free prerequisite step for price and record count.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a Stripe Checkout session id (cs_…), reports whether it is paid and, if so, returns the permanent download link for the CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Checkout session id from create_checkout |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive safety, so the description need not repeat those. It adds valuable context: the tool checks payment status and conditionally returns a permanent download link, which is behavior beyond the annotations. It doesn't mention potential error states (e.g., session not found, unpaid session) or rate limits, preventing a 5.
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?
Single sentence, front-loaded with the prerequisite (session id) and the outcome. No wasted words; every clause contributes.
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 one-parameter read-only tool with rich annotations and no output schema, the description covers the essential behavior (payment check and download link return). It could mention what happens when unpaid (e.g., returns an error or a status) but the core is complete.
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 description already states the parameter is a Stripe Checkout session id from create_checkout with a pattern '^cs_'. The description repeats the 'cs_…' format but adds no syntax or meaning beyond the schema, so the 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 (reports/checks) and resource (Stripe Checkout session), and clarifies the exact conditions: whether it is paid, and if so returning a download link. An agent can distinguish this from create_checkout and buy_dataset without schema inspection.
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 implicitly tells the agent to use it with a session id from create_checkout (schema also says 'from create_checkout'). It doesn't explicitly say when NOT to use it (e.g., before checkout is created) or name alternatives, but the input requirement and purpose are clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a Stripe Checkout session for one dataset and returns the payment URL plus the session id. Give the URL to the user to pay (card, Apple Pay, Google Pay). After payment Stripe emails them a permanent download link; use check_order with the session id to confirm and fetch it. Does not charge anything by itself.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Dataset slug | |
| No | Buyer email, if known — prefills Checkout and is where the download link is sent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true, but the description adds the crucial nuance that the tool 'does not charge anything by itself' and that fulfillment happens asynchronously by email after payment. That side-effect scoping is exactly the context annotations cannot convey.
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?
Three short sentences, no filler, with the core action and return value front-loaded before the payment workflow and follow-up tool. Every sentence carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the return values itself (payment URL and session id), explains the post-payment flow, and names the follow-up tool. Nothing needed to invoke or sequence it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both slug and email are already documented. The description reinforces the email's downstream role ('where the download link is sent') and the single-dataset constraint, but adds nothing new about formats or edge cases, so the 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 ('Opens a Stripe Checkout session for one dataset') and names exactly what it returns (payment URL plus session id), so an agent can distinguish it from get_dataset or buy_dataset at a glance.
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 the full operating context: hand the URL to the user, then use check_order with the session id to confirm and fetch the permanent download link. The only gap is that it never contrasts this with the sibling buy_dataset, so the choice between the two is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record for one dataset: fields with descriptions, record and state counts, coverage, advertised refresh cadence AND the real last-modified date of the file, FAQs, sample URL and the dataset's page on locationlists.com.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Dataset slug from search_datasets, e.g. bobcat-dealers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive/closed-world, so the safety bar is covered. The description adds genuine behavioral value by distinguishing the 'advertised refresh cadence' from 'the real last-modified date of the file', signaling a freshness-discrepancy nuance an agent would otherwise not know.
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 front-loaded sentence with a colon-delimited inventory of return contents. No redundant or filler text; every clause identifies a distinct piece of the returned record.
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 record's components, which is exactly what an agent needs to decide whether this tool answers its question. Only minor gaps remain (error/not-found behavior, pagination is not relevant 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?
Only one parameter, with 100% schema description coverage and an example in the schema ('bobcat-dealers'). The description does not elaborate on the slug beyond 'one dataset', so it neither adds nor detracts; the baseline 3 for high schema coverage 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 resource (one dataset) and enumerates the exact contents of the returned record (fields, counts, coverage, refresh cadence vs. last-modified, FAQs, sample URL, page URL). This clearly separates it from list-style siblings like search_datasets, though it never names an alternative explicitly.
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 no when-to-use guidance, no prerequisites, and no mention of alternatives. The only workflow hint ('slug from search_datasets') lives in the input schema, not the description, so the agent gets no routing help from the text itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Line-item prices and total for a list of dataset slugs. If a bundle covers several requested brands for less, it says so.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Dataset slugs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description goes further by disclosing what the response contains: per-line prices, a total, and a note when a bundle is cheaper. That output-shape disclosure is genuinely useful given there is no 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?
Two tight sentences with the primary output (prices and total) front-loaded and the conditional bundle behavior following. No filler or redundancy.
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, single-parameter read tool with full schema coverage and safe annotations, this is close to sufficient; it even sketches the return shape. The bundle clause ('it says so') stays vague about how that alternative is surfaced, leaving a small gap.
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% for the single 'slugs' parameter, so the schema already carries the semantics. The description only echoes the parameter as 'a list of dataset slugs' and adds no syntax, count limits, or format detail beyond what is structured.
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 concrete verb and resource: it returns line-item prices and a total for a list of dataset slugs. That clearly separates it from buy_dataset and create_checkout, though it never names a sibling explicitly.
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 stated when-to-use condition or routing to alternatives such as buy_dataset or create_checkout. The pre-purchase framing is inferable from the name and output, but nothing in the text tells the agent when this tool is the right choice versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Up to 10 real rows from the live file (spread across the dataset, not the first ten), as JSON plus CSV text. Show these to the user so they can judge the fields and quality.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Rows to return (default 10) | |
| slug | Yes | Dataset slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety traits (readOnly, idempotent, non-destructive). The description adds valuable behavioral detail beyond that: it returns up to 10 rows sampled across the dataset rather than the first ten, and returns JSON plus CSV text. It does not cover auth or rate limits, but those are minor for this tool.
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 return scope and sampling strategy, followed by a direct usage instruction. Every sentence earns its place.
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 2-parameter read-only tool with full schema coverage and rich annotations, the description covers what an agent needs: output format (JSON + CSV), sampling behavior, and how to present results. No output schema exists, so explaining the return shape here is appropriate and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the 'rows' parameter by specifying that the returned rows are spread across the dataset, not just the first ten, which is not captured in 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 ('get') and resource ('sample rows from the live file') with clear scope (up to 10, spread across dataset). It does not explicitly differentiate from siblings like get_dataset or search_datasets, so it falls short of the top score.
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: 'Show these to the user so they can judge the fields and quality.' This tells the agent when the tool is useful, but it offers no explicit exclusions or named alternatives for other retrieval tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return matching rows from one dataset, filtered on exact column values (state, city, county, zip — whichever that dataset has). Priced per row in USDC via x402 and settled only after the rows are produced, so a failed call costs nothing. The rate is derived from the dataset: roughly 2x its list price spread over its record count, so a small slice of a big file is cents. You pay for the limit you request, up to 100 rows. Call without a payment header first to get an exact quote. Datasets under 5,000 records are not sold by the row — buy those files outright.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| city | No | ||
| limit | No | ||
| state | No | Two-letter state code | |
| county | No | ||
| dataset | Yes | Dataset slug, e.g. dental-practice-list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior, but the description adds substantial payment and settlement semantics: pricing is per row in USDC via x402, settlement happens only after rows are produced, failed calls cost nothing, and the limit is capped at 100 rows. These are the critical behavioral details an agent cannot infer from 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 core purpose is front-loaded in the first sentence, and the remaining sentences carry useful pricing and workflow context. It is slightly dense but no sentence is wasted, so it reads as appropriately sized rather than bloated.
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 complex paid query tool with no output schema and partial schema coverage, the description covers the essential workflow: filtering semantics, payment timing, quote retrieval, row-limit pricing, and the threshold at which file purchase is preferred. An agent has enough information to call it correctly and understand the cost consequences.
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?
With only 33% schema description coverage, the description compensates by explaining that state, city, county, and zip are exact-match filters and that only the columns present in the dataset apply. It also clarifies that payment scales with the requested limit, though it does not fully document every parameter beyond that.
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: return matching rows from one dataset filtered on exact column values. It names the filterable columns and explicitly notes they are dataset-dependent, which lets an agent distinguish it from sibling tools like buy_dataset and search_datasets.
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 when-to-use guidance, including calling without a payment header first for an exact quote, and a when-not-to-use condition: datasets under 5,000 records must be bought outright instead. This routes the agent away from per-row querying in the wrong scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find LocationLists datasets by brand name, product line, location type or category (e.g. 'bobcat', 'generator dealers', 'hardware stores', 'breakfast restaurants'). Returns slug, name, record count, coverage and page URL. Use the slug with the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 15) | |
| query | No | Free-text search: brand, product, or location type | |
| category | No | Restrict to one catalog category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description usefully discloses what is returned (slug, name, record count, coverage, page URL), but says nothing about pagination or the default/max result 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 tight sentences with no filler; the searchable scope and examples come first, and the output/workflow note is front-loaded at the end. Every clause earns its place.
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 the returned fields and explaining how the slug is reused downstream. Only gap is the absence of result-limit/pagination behavior, which is only partially implied by the schema's limit parameter.
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 baseline is 3. The examples ('bobcat', 'generator dealers', 'hardware stores') add color for building the query string, but no syntax, matching behavior, or interaction rules between query and category are 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?
States a specific verb and resource ('Find LocationLists datasets') and enumerates the searchable dimensions (brand, product line, location type, category) with concrete examples. This clearly separates it from siblings like get_dataset (fetch by slug) and query_locations (query records within a dataset).
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 closing line 'Use the slug with the other tools' gives useful follow-through guidance, implying this is the entry point in a workflow. However, it never states when to prefer this over get_dataset when a slug is already known, nor any when-not conditions.
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.
buy_datasetcheck_ordercreate_checkoutget_datasetget_quoteget_samplequery_locationssearch_datasetsCounts and firmographics for 7.5M+ verified US B2B businesses, by industry, state and city.
US local-services data: find locals by trade and city, browse open jobs, see which markets answer
Search and enrich US property, owner, people, and company data for sales and lead generation.
Search 7,000+ local service businesses across America by category, location, or keyword.
