Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

datasets_doordash_stores_nearby

Find nearby stored DoorDash stores. Returns stored DoorDash stores within a radius of a point, nearest first, from dataset id doordash-stores. lat, lon, and radius_m are required.

Instructions

Find nearby stored DoorDash stores. Returns stored DoorDash stores within a radius of a point, nearest first, from dataset id doordash-stores. lat, lon, and radius_m are required. Unlike the live /doordash/search endpoint (which is a proximity search capped at roughly five stores), this queries the stored directory, so it can return every discovered store in the radius. Coverage is best-effort rather than provably exhaustive: a store DoorDash never surfaced, or one not yet hydrated with coordinates, will not appear. Billing: this endpoint 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
latYesCenter latitude, from -90 through 90
lonYesCenter longitude, from -180 through 180
tagNoSingle marketplace tag filter
pageNoOffset page number, defaults to 1; ignored by cursor pagination except page=1 to start
cursorNoOpaque continuation token returned in next_cursor; use with pagination=cursor and the same location and filters
countryNoISO-3166-1 alpha-2 country filter
radius_mYesSearch radius in meters, 1 through 50000
page_sizeNoPage size, defaults to 20 and maxes at 100; the 10,000-result cap applies only to offset pagination
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

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it discloses result ordering, coverage limits ('best-effort rather than provably exhaustive', plus why stores can be missing), and an unusually explicit billing model (1 credit per record, minimum 2, empty result costs 2). This is well beyond what the schema conveys.

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?

The content is dense but front-loaded: purpose first, then scope/comparison, then caveats, then billing. Every sentence conveys a distinct fact; only the billing example sentence is slightly verbose relative to the rest.

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?

For a 10-parameter proximity tool with no output schema and no annotations, the description covers ordering, coverage caveats, and cost, which is what an agent most needs. It stops short of describing the shape of returned records or how cursor vs offset pagination should be chosen in practice, leaving minor gaps.

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 parameter meanings and ranges are already documented. The description restates that lat, lon, and radius_m are required and alludes to page size via the 100-record example, but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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?

The description opens with a specific verb+resource ('Find nearby stored DoorDash stores'), states the dataset id, the ordering (nearest first), and the required inputs. It explicitly distinguishes itself from the live /doordash/search endpoint and from the stored directory's scope, so an agent can identify the tool 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 Guidelines4/5

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

It clearly frames when this is the right choice versus the live proximity endpoint ('capped at roughly five stores'), which is real routing guidance. However, it never names the obvious sibling alternatives like datasets_doordash_stores_search or datasets_doordash_stores_item, so the agent must infer those distinctions.

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