Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

datasets_apple_maps_places_search

Search stored Apple Maps places by name, category, location, rating, contact details, and sort results to find businesses without live scraping.

Instructions

Search stored Apple Maps places. Searches the stored Apple Maps place directory (dataset id apple-maps-places), built by tiling populated areas and running category searches over each tile. Each place has its Apple place id, name, category path, address, coordinates, phone, website, opening hours, rating and price level where Apple shows them. Coverage is observed, not complete: Apple answers each search with at most 25 places, so very dense areas can hold places the directory has not reached, and a place missing from the results is not evidence that it does not exist or has closed. A rating of null means Apple shows no rating for the place (never a zero-star score); ratings and rating counts come from third-party review partners that Apple shows (for example Yelp and Foursquare), so they are not comparable across places and a few places carry a rating with no count. Supports full-text q, category/city/state/country_code/postal_code filters, min_rating, min_rating_count, has_website, has_phone, lat/lon/radius_m radius filtering, and sort (relevance, rating_desc, review_count_desc, updated_at_desc, distance_asc). Does not trigger live scraping. 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 place name, category, city and address; every term must match. Max 256 characters
latNoLatitude for radius filtering or distance sort, requires lon
lonNoLongitude for radius filtering or distance sort, requires lat
cityNoExact city filter, max 128 characters
pageNoPage number, defaults to 1
sortNoSort enum: relevance, rating_desc, review_count_desc, updated_at_desc, distance_asc. Defaults to relevance with q, otherwise updated_at_desc
stateNoExact state/region filter, max 128 characters
categoryNoExact Apple category name, max 128 characters, e.g. Coffee Shop; use facet=category to discover values
radius_mNoRadius in meters, 1 through 50000; requires lat and lon
has_phoneNotrue keeps only places with a phone number; false keeps only places without one
page_sizeNoPage size, defaults to 20 and maxes at 100; page * page_size must be <= 10000
min_ratingNoMinimum rating, from 0 through 5; any value above 0 excludes unrated places
has_websiteNotrue keeps only places with a website; false keeps only places without one
postal_codeNoExact postal code filter, max 128 characters
country_codeNoISO 3166-1 alpha-2 country filter, e.g. US, GB, JP
min_rating_countNoMinimum number of ratings behind the rating, 0 or greater

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4/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 incomplete observed coverage (Apple returns at most 25 places per tile search, so absences are not proof of non-existence or closure), the meaning of a null rating, that ratings come from third-party partners and are not cross-comparable, that no live scraping occurs, and the exact per-record billing with a 2-credit floor.

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?

Purpose and dataset identity are front-loaded, followed by coverage caveats, then capabilities, then billing — a sensible ordering. It is dense but nearly every clause is load-bearing; only the enumeration of filters and sort modes mildly duplicates the schema text.

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 16-parameter, annotation-free, output-schema-less tool, the description covers the missing pieces: it enumerates the returned fields (place id, name, category path, address, coordinates, phone, website, opening hours, rating, price level), explains result-count limits, and states cost per call. Nothing an agent needs to invoke or interpret it is missing.

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 description coverage is 100%, so the schema already documents all 16 parameters including ranges, defaults and enum values. The description enumerates the supported filter families and sort modes but adds no syntax or interaction detail beyond what the schema states, so the baseline of 3 applies.

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?

States a specific verb and resource ("Search stored Apple Maps places") and pins down the exact backing dataset (`apple-maps-places`) plus how it is built. It distinguishes itself from the live counterpart by saying it does not trigger live scraping, though it never names a sibling tool outright.

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

Usage Guidelines3/5

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

Usage is implied rather than prescribed: the agent can infer this is the stored-directory search and that live lookups live elsewhere, and the filter list plus sort enum sketches the supported query shapes. There is no explicit when-to-use/when-not-to-use statement and no pointer to `datasets_apple_maps_places_nearby`, `_item`, `_facets`, or `apple_maps_search` as alternatives.

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