Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

datasets_doordash_stores_search

Search and filter DoorDash merchant stores by text, location, tags, price, rating, or DashPass status to retrieve structured store listings.

Instructions

Search the DoorDash store directory. Searches the DoorDash merchant-location directory (dataset id doordash-stores). Identity and marketplace fields (name, marketplace tags, price range, ratings, DashPass eligibility) are available for each store; contact, address, and coordinates can be missing for a store that has not been fully processed yet. display_status, display_asap_time, asap_available, and pickup_available are a point-in-time observation of the PICKUP surface at crawl time, not a durable capability. Geographic coverage is best-effort. Supports full-text q, country/state/city/tag filters, dash_pass_only, min_price/max_price/min_rating, lat/lon/radius_m radius filtering, and sort (relevance, rating, distance, distance_asc). sort=relevance ranks by text-match score when q is supplied; without q it sorts by store name. Use pagination=cursor and the returned next_cursor to enumerate beyond the 10,000-result offset window against a point-in-time snapshot. Billing: this search costs 1 credit per record returned, with a minimum of 2 (an empty result costs 2, a full page of 100 costs 100).

Input Schema

NameRequiredDescriptionDefault
qNoFull-text search over store name, address, city, and marketplace tags, max 256 characters
latNoLatitude for radius filtering or distance sort, requires lon
lonNoLongitude for radius filtering or distance sort, requires lat
tagNoSingle marketplace tag filter, e.g. Pizza
cityNoExact city filter
pageNoOffset page number, defaults to 1; ignored by cursor pagination except page=1 to start
sortNoSort enum: relevance, rating, distance, distance_asc
stateNoState/region code filter, e.g. CA
cursorNoOpaque continuation token returned in next_cursor; use with pagination=cursor and the same filters and sort
countryNoISO-3166-1 alpha-2 country filter, e.g. US, CA
radius_mNoRadius in meters, 1 through 50000; requires lat and lon
max_priceNoMaximum price range tier, inclusive
min_priceNoMinimum price range tier, inclusive
page_sizeNoPage size, defaults to 20 and maxes at 100; the 10,000-result cap applies only to offset pagination
min_ratingNoMinimum aggregate rating, 0 through 5; excludes unrated stores
paginationNoPagination mode: offset or cursor. Cursor mode supports full enumeration beyond the offset result window.
dash_pass_onlyNoKeep only DashPass-eligible stores

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A3.9/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden and does so thoroughly: it discloses that contact/address/coordinates may be missing for unprocessed stores, that display fields are a point-in-time PICKUP observation rather than durable capability, that geographic coverage is best-effort, that enumeration is against a snapshot, and that billing is 1 credit per record with a 2-credit minimum. This is unusually rich behavioral disclosure.

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 a clear purpose sentence and information-dense thereafter. There is minor redundancy between the opening two sentences, but nearly every clause (data-quality caveats, snapshot semantics, billing) earns its place.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter search with no output schema, the description covers the offset-vs-cursor pagination tradeoff, cost model, snapshot/data-quality limitations, and sort semantics. An agent has everything needed to invoke it correctly and predict cost.

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 description coverage is 100%, so baseline is 3, and the description adds meaningful nuance beyond the schema: `sort=relevance` ranks by text-match score only when `q` is supplied (otherwise by store name), and cursor pagination is required to enumerate beyond the 10,000-result offset window. These are semantics the schema does not state.

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

Purpose4/5

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

The first two sentences state a specific verb ("Search") and resource ("DoorDash store directory" / merchant-location directory, dataset id `doordash-stores`), which is unambiguous. It does not, however, differentiate itself from sibling tools like datasets_doordash_stores_nearby or datasets_doordash_stores_facets, which share the same resource.

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

Usage Guidelines2/5

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

The description catalogs supported filters and sort modes but never states when to choose this tool over the nearby/facets/item siblings or portal-specific doordash_search. There is no when-to-use or when-not-to-use guidance, only a capability inventory.

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

Deploy Server

Other Tools