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.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. Beyond that the description adds real behavioral context: results come back complete and best-first with a listed field set, the operations are free ('Both are free'), registers are read live and 'never sold', and each brand is treated as its own dataset. These are useful traits not present in the annotations, though some of the text reads more as routing advice than behavior.

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 first sentence is well front-loaded, but the remainder is one sprawling paragraph that crams list-mode, register-mode, distance filtering, pricing and multi-chain aggregation together. It is dense and fatiguing and would read far better as bullets, though little of it is strictly redundant.

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?

There is no output schema, so the description usefully enumerates the returned fields (slug, name, business type, industry, record count, coverage, distanceSearch, page URL) and result ordering. Combined with the register/live-read caveat and sibling routing, an agent has nearly everything needed, with only the minor `kinds`/`category` ambiguity outstanding.

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 100%, so the schema already documents all five parameters and the baseline is 3. The description reinforces the 'register' semantics of `kind`/`state` and cross-tool use of the result's `source`, but it inconsistently refers to a `kinds` category concept that appears in the schema as `category`, which risks mild confusion rather than adding clean meaning.

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?

Opens with a specific verb+resource ('Find LocationLists datasets'), scopes it by brand/kind/industry with concrete examples, and immediately distinguishes the 'list' vs 'register' modes. It also names the sibling it hands off to (count_locations, get_sample), so an agent can tell it apart from the rest of the family 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.

Usage Guidelines5/5

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

Gives explicit hand-off conditions: count_locations when you want a count, get_sample for count plus fixed free rows, and passing datasets/category with a total to combine chains into one answer/price/file. The register path is spelled out as a separate query mode. Nothing about when to reach here vs a sibling 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.