Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

apple_maps_search

Find Apple Maps places near a coordinate by keyword, name, category, or address. Returns place IDs, contact details, ratings, hours, and photos in structured JSON.

Instructions

Search Apple Maps places near a coordinate. Returns Apple Maps places matching a keyword, business name, category, or street address near a coordinate. Each place carries its Apple place ID (the value the place endpoint takes), name, category, coordinates, formatted and structured address, phone, website, rating and review count, price level, weekly opening hours, and a hero photo. Apple returns a bounded set per viewport (around 25 places for the default span) with no pagination; widen the span or move the center to cover more area. When nothing matches near the center Apple may relocate the search to a default region, reported by relocated=true and the region bounds. The response's filters block lists the refinement chips Apple offers for this query and area (open now, top rated, in guides, cuisines, price bands, amenities, accolades, sort); pass their keys back as filters and sort to refine the same search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoDisplay language as a BCP 47 tag, e.g. en-US, ja-JP, de-DE. Defaults to en-US.
sortNoResult order. Costs a second upstream search.
spanNoSearch viewport size in degrees of latitude/longitude around the center. Defaults to 0.05 (roughly a 5km box); minimum 0.001, maximum 5.
limitNoMax places returned. Defaults to 25, maximum 100.
queryYesKeyword, business name, category, or street address to search for
countryNoTwo-letter ISO 3166-1 country code selecting Apple's regional catalog. Defaults to US.
filtersNoComma-separated filter keys from the filters block of an unfiltered search for the same query and area, e.g. OPEN_NOW, TOP_RATED, FEATURED_IN_GUIDES, PRICE_RANGE_MODERATE, modern_pizza_restaurant, ACCEPTS_CREDIT_CARDS. Unknown keys return 400 listing the available keys. Costs a second upstream search.
latitudeYesSearch center latitude
longitudeYesSearch center longitude

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / sort / enum
      Added value: +[
+  "best_match",
+  "distance",
+  "ratings"
+]
  2. Addedv1.16.2

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations present, the description carries the full behavioral burden and reveals important non-obvious traits: Apple returns only a bounded set (~25 places default), there is no pagination, searches may relocate to a default region when nothing matches (reported by relocated=true), and filter keys are round-trippable. This is strong disclosure, though it does not mention auth/permission expectations or rate-limit behavior.

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

Conciseness5/5

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

The description is dense but well organized: purpose is front-loaded, followed by return fields, then behavioral limits, then refinement workflow. Every sentence contributes useful information, and the length is justified because there is no output schema to inherit return-field documentation from.

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?

The description is unusually complete for a tool with no annotations and no output schema. It covers what is returned, how to interpret place IDs, the lack of pagination, the relocation edge case, and the filter refinement loop. An agent has enough information to call this tool correctly and interpret its response.

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?

Since the input schema already has 100% parameter description coverage, the baseline is 3. The description adds cross-parameter value by explaining how span and center interact to cover more area and how filters and sort consume keys from the response's filters block, which goes beyond the individual schema definitions.

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 description clearly states the verb and resource: 'Search Apple Maps places near a coordinate' and enumerates what kinds of queries are accepted (keyword, business name, category, street address). It stops short of explicitly naming sibling tools like apple_maps_category_search or apple_maps_autocomplete, so the differentiation is implied rather than stated.

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?

The description gives useful operating context: results are bounded per viewport, there is no pagination, and users should widen the span or move the center to cover more area. It also explains how to use the response's filters block to refine searches, but it does not explicitly say when to prefer an alternative tool such as apple_maps_place or apple_maps_category_search.

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