Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_apple_maps_places_item

Retrieve a stored Apple Maps place by numeric or external place id from the apple-maps-places dataset, returning catalog country, country code, rating, and first/last seen timestamps without live scraping.

Instructions

Get a stored Apple Maps place. Returns one stored Apple Maps place by Apple place id from dataset id apple-maps-places. Accepts either the numeric place id (the id field) or the external place id that appears in maps.apple.com URLs (the place_id field, starting with I). A rating of null means Apple shows no rating for the place. catalog_country is the Apple storefront the place was found under, not its country; country_code is the place's own country. first_seen_at is when the directory first observed the place and last_seen_at the latest observation. Does not trigger live scraping; for a live Apple Maps lookup use the apple-maps-place endpoint.

Input Schema

NameRequiredDescriptionDefault
place_idYesApple place id: the numeric id or the external id starting with I

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses this is a stored/snapshot lookup (no live scraping) and clarifies several field semantics (`rating` null meaning, `catalog_country` vs `country_code`, observation timestamps). It stops short of describing return structure or edge cases like an unknown id.

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-loads the core purpose and the alternative-endpoint routing before the field explanations. The field notes are useful but slightly verbose; still, every sentence maps to a concrete piece of behavior.

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?

No output schema exists, so the description responsibly explains the meaning of several returned fields, which compensates well. What's missing is minor: return shape and behavior for an invalid id, but overall it is sufficient to call the tool correctly.

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 the single `place_id` parameter, including both id formats. The description largely repeats that (numeric id vs external `I`-prefixed id) rather than adding syntax or validation detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ("Get a stored Apple Maps place") and pins it to dataset id `apple-maps-places`. It also distinguishes itself from the live `apple-maps-place` sibling by declaring it does not trigger live scraping, so the agent can tell the two apart without opening schemas.

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?

Explicitly names the alternative ("for a live Apple Maps lookup use the apple-maps-place endpoint"), giving clear when-to-use guidance. It does not explain where place ids come from (e.g. search/nearby siblings), which is a minor gap.

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