Skip to main content
Glama

Show route

maps_show_route
Read-onlyIdempotent

Displays a route as an interactive card with map pins, time and distance, stop arrival details, turn-by-turn steps, and an Open in Google Maps button for sharing directions.

Instructions

Show a route to the person as a card: interactive map with the route and lettered pins, total time and distance, the stops with arrival times and open/closed status, turn-by-turn steps per leg, and an "Open in Google Maps" button (claude.ai and ChatGPT draw it). Same facts as maps_plan_route. Use it whenever you give directions or a route.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "origin": "<origin>"
    },
    "name": "maps_show_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoYour short note under the heading
titleNoHeading above the card
originYesA place name or address ('Albertina, Vienna'), a place id (ChIJ…) or 'lat,lng'
roundTripNoCome back to the origin
travelModeNoDRIVE (default), WALK or BICYCLEDRIVE
destinationNoEnd; omit with stops to end at the last stop
dwellMinutesNoMinutes at each stop, in the order given
departureTimeNoLocal wall-clock time at the stop, e.g. 2026-10-22T08:30 (no offset)
intermediatesNoStops in between
optimizeOrderNoReorder the stops for the fastest route

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: output is an interactive card with lettered pins, open/closed status and turn-by-turn steps, and that rendering depends on the client ('claude.ai and ChatGPT draw it'). It stops short of saying what the caller gets back in a client that cannot draw the card.

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-loaded with the core action, then the card contents, then the usage directive; every clause carries information. There is minor overlap between 'interactive map with the route' and the opening phrase, and the contents list is long, but it is not padding.

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?

With no output schema, the description carries the full burden of describing the return value, and it does so concretely (time, distance, stops with arrival times, open/closed, steps per leg, Google Maps button). For a 10-parameter tool with one required field and full schema coverage, nothing an agent needs to call it correctly 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 each of the ten parameters is already documented in the schema, including enums and defaults. The description adds no per-parameter meaning beyond echoing that stops carry arrival times, so baseline 3 is correct.

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 (show) and resource (route) plus the delivery medium (a rendered card), and enumerates exactly what the card contains. The line 'Same facts as maps_plan_route' lets an agent separate this presentation tool from the planning tool 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?

'Use it whenever you give directions or a route' is an explicit positive usage trigger, which is stronger than most definitions offer. It does not name alternatives or exclusions (e.g., when to prefer maps_compute_route for raw data instead), so the routing decision is only half-specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.