Skip to main content
Glama

Search location datasets

search_datasets
Read-onlyIdempotent

Find LocationLists datasets by brand, kind of business or industry (e.g. 'bobcat', 'restaurants', 'bank branches', 'dental practices', 'hardware stores'). Returns EVERY matching dataset, best first, with slug, name, business type, industry, record count, coverage, whether it can be searched by distance (distanceSearch), and page URL. A kind of business or an industry in the query matches every dataset of that kind, and kinds names it as a category that count_locations can combine into one answer. Each brand or chain is its own dataset. After finding one you can filter it by city, state, zip, any column, or a radius around a place (e.g. within 25 miles of Los Angeles, CA) when it has coordinates: use count_locations for how many match, and get_sample with the same filters for that count plus the list's fixed free sample rows, each marked matches_your_question. Both are free. To cover several chains near one place, pass datasets or category and a total to count_locations, and you get one answer, one price and one file. kind "register" searches LIVE public registers instead (a state's licensed child care, liquor licences, SNAP retailers…): each result's source is the key relate_locations takes as a set's opendata {source, state}, compared by distance (mode near). Registers are read live, never sold.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNolist (default): the lists we sell. register: live public registers read from their publisher, e.g. {"query": "child care", "kind": "register", "state": "NY"} — each result's source goes in relate_locations as {"opendata": {"source": "<source>", "state": "NY"}}.
limitNoMax results (default: every match)
queryNoFree text: brand, kind of business, industry or product
stateNoWith kind "register": prefer registers covering this state, e.g. "NY"
categoryNoRestrict to one catalog category, industry or subcategory

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / kind
      Added value: +{
      +  "description": "list (default): the lists we sell. register: live public registers read from their publisher, e.g. {\"query\": \"child care\", \"kind\": \"register\", \"state\": \"NY\"} — each result's source goes in relate_locations as {\"opendata\": {\"source\": \"<source>\", \"state\": \"NY\"}}.",
      +  "enum": [
      +    "list",
      +    "register"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / state
      Added value: +{
      +  "description": "With kind \"register\": prefer registers covering this state, e.g. \"NY\"",
      +  "type": "string"
      +}
  2. Changed5 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"Restrict to one catalog category"New value: +"Restrict to one catalog category, industry or subcategory"
    • removedInput schema / properties / category / enum
      Removed value: -[
      -  "Equipment",
      -  "Retail",
      -  "Hardware",
      -  "Grills",
      -  "Industrial",
      -  "Breakfast",
      -  "Outdoor Furniture",
      -  "Furniture",
      -  "Mattresses",
      -  "Nonprofits",
      -  "Healthcare",
      -  "Financial",
      -  "Government",
      -  "Other Transactions"
      -]
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 15)"New value: +"Max results (default: every match)"
    • changedInput schema / properties / limit / maximum
      Previous value: -50New value: +1000
    • changedInput schema / properties / query / description
      Previous value: -"Free-text search: brand, product, or location type"New value: +"Free text: brand, kind of business, industry or product"
  3. Changed1 schema field changed
    • changedInput schema / properties / category / enum
      Previous value: -[
      -  "Equipment",
      -  "Retail",
      -  "Hardware",
      -  "Grills",
      -  "Industrial",
      -  "Breakfast",
      -  "Outdoor Furniture",
      -  "Furniture",
      -  "Mattresses",
      -  "Nonprofits",
      -  "Healthcare",
      -  "Financial",
      -  "Government"
      -]New value: +[
      +  "Equipment",
      +  "Retail",
      +  "Hardware",
      +  "Grills",
      +  "Industrial",
      +  "Breakfast",
      +  "Outdoor Furniture",
      +  "Furniture",
      +  "Mattresses",
      +  "Nonprofits",
      +  "Healthcare",
      +  "Financial",
      +  "Government",
      +  "Other Transactions"
      +]
  4. Changed1 schema field changed
    • changedInput schema / properties / category / enum
      Previous value: -[
      -  "Equipment",
      -  "Retail",
      -  "Hardware",
      -  "Grills",
      -  "Industrial",
      -  "Breakfast",
      -  "Outdoor Furniture",
      -  "Furniture",
      -  "Mattresses",
      -  "Nonprofits",
      -  "Healthcare"
      -]New value: +[
      +  "Equipment",
      +  "Retail",
      +  "Hardware",
      +  "Grills",
      +  "Industrial",
      +  "Breakfast",
      +  "Outdoor Furniture",
      +  "Furniture",
      +  "Mattresses",
      +  "Nonprofits",
      +  "Healthcare",
      +  "Financial",
      +  "Government"
      +]
  5. First observed

TDQS

A4.5/5.0
Behavior4/5

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). The description adds genuinely useful context beyond them: results are returned best-first and exhaustively, count_locations/get_sample are free, registers are read live and 'never sold'. It stops short of noting rate limits or pagination behavior.

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

Conciseness4/5

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

Front-loaded with the core action and return shape, then secondary guidance. Dense but mostly earning its place; the cross-tool instructions for relate_locations/count_locations could be trimmed since those tools document themselves.

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?

No output schema exists, so the description carries the return-value burden and does so by enumerating slug, name, business type, industry, record count, coverage, distanceSearch and page URL. Combined with mode handling for registers, it is nearly complete; only count/pagination limits are unaddressed.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning on top: it explains that a kind of business or industry in the query matches every dataset of that kind, that `kinds` can be named as a category for count_locations, and that kind 'register' switches to live public registers with `source`/`state` semantics.

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?

States a specific verb (find/search) and resource (LocationLists datasets), and immediately distinguishes the two modes: sold 'list' datasets vs LIVE 'register' datasets. An agent can tell this apart from get_dataset or count_locations without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use count_locations to count matches, get_sample for count plus sample rows, relate_locations for registers via the {source, state} opendata key, and count_locations with datasets/category to combine several chains into one answer. Names alternatives and the conditions that select them.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.