Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

apple_maps_directions

Get driving, walking, or cycling directions from Apple Maps with route details, turn-by-turn steps, traffic-aware estimates, and preferences for tolls, highways, and stairs.

Instructions

Get Apple Maps driving, walking, or cycling directions. Returns Apple Maps routes between an origin and a destination, with optional intermediate stops, for driving, walking, or cycling. Each route carries its name, whether it is Apple's main or an alternate route, distance, live/historic/free-flow durations, toll and highway flags, Apple's route description and traffic note, and per-leg turn-by-turn steps (maneuver, road, shield, instruction text, distance, duration); detail=full adds each leg's path as coordinates. Departure time and avoid-tolls/highways/stairs preferences are supported. Transit routing is not available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viaNoIntermediate stops as lat,lng pairs separated by |, at most 8
langNoLanguage for road names and instructions as a BCP 47 tag. Defaults to en-US.
modeNoTravel mode. Defaults to driving.
detailNoHow much of each route to return. Defaults to steps.
countryNoTwo-letter ISO 3166-1 country code. Defaults to US.
depart_atNoDeparture time as RFC 3339 for traffic-aware estimates. Defaults to now.
avoid_tollsNoDriving only: prefer routes without tolls
avoid_stairsNoWalking only: prefer routes without stairs
avoid_highwaysNoDriving only: prefer routes without highways
origin_latitudeYesOrigin latitude
origin_longitudeYesOrigin longitude
destination_latitudeYesDestination latitude
destination_longitudeYesDestination longitude

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / detail / enum
      Added value: +[
+  "summary",
+  "steps",
+  "full"
+]
    • addedInput schema / properties / mode / enum
      Added value: +[
+  "driving",
+  "walking",
+  "cycling"
+]
  2. Addedv1.16.2

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure, and it does substantial work: it enumerates what each route contains (name, main/alternate flag, distance, live/historic/free-flow durations, toll/highway flags, description, traffic note, per-leg steps), explains that detail=full adds leg path coordinates, and notes supported preferences. It stops short of describing edge-case behavior (e.g., no route found) or output root structure, but the core behavioral profile is well covered.

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 description is front-loaded with the core purpose and uses compact clauses for route contents, detail levels, preferences, and the transit limitation. Minor redundancy exists (the modes driving/walking/cycling are repeated in the first two sentences), but no filler.

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 13-parameter tool with no output schema and no annotations, the description covers the essential behavioral surface: modes, route fields, detail levels, preferences, and the transit gap. It does not describe the top-level response shape or error/edge conditions, but the schema covers all parameter semantics.

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 coverage is 100%, so the baseline is 3, and the description still adds value by explaining that detail=full adds coordinates, depart_at enables traffic-aware estimates, and avoid_tolls/highways/stairs are preference toggles. These context bits are not obvious from the raw parameter names alone.

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 Apple Maps driving, walking, or cycling directions' and 'Returns Apple Maps routes between an origin and a destination.' The modes, route contents, and explicit 'Transit routing is not available' make it distinguishable from sibling tools like apple_maps_eta, apple_maps_search, and apple_maps_transit_departures 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 Guidelines3/5

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

The description implies usage context (needs driving/walking/cycling directions between coordinates) and states an explicit exclusion ('Transit routing is not available'), but it never names alternative tools or says when to prefer a sibling such as apple_maps_transit_departures or apple_maps_eta. The 'when-not' is stated but not routed to an alternative.

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