Skip to main content
Glama

Get travel time

well_get_travel_time
Read-only

Get how long one trip takes and how far it is, from Google Maps: "the drive to the 10:00 meeting", "le trajet jusqu'au match de samedi". Call it for each event that has a location when the person asks for the travel time: once per event and way of travel you compare. Pass destination: the event's location copied as the event or the mail states it. Pass origin: the start address the person gave; else, for a trip of the person to one of their events, the place of their meeting that ends at most 60 minutes before when a walk from it is under 10 minutes, else their saved home or that day's office from memory; never an address you complete. Leave it out only when no start is known: the trip then starts from the workspace's own address. Leave mode out for a car trip. A person with no pinned way of travel gets one call per way, walk first, stopping at the first that fits the scale of the skill in use; a pinned way gets its own call and, when it is not walk, one walk call. A walk or bicycle answer says the route is in beta and can miss sidewalks or bike paths. Pass departure_at when the time the person leaves is known, so a car trip reads traffic. An event with no location gets no call: say its travel time is unknown. The tool runs at most 12 times per turn.

For the walking time from a location the person shared in this conversation to a place that well_search_places returned: pass origin_latitude and origin_longitude exactly as the shared location states them, destination_place_id as the place's place_id, and mode "walk". A place with no place_id gets no call. Never pass an address and a point together, and never a destination and a place id together.

Returns status "found" with duration_minutes, mode and origin_kind, with distance_km and origin unless the trip starts at a shared location ("shared_point"), or "no_route" when Google Maps found no route. Give the duration as the tool returns it, say it comes from Google Maps, and when origin_kind is "workspace_address" say the trip starts from the workspace's address. Never estimate, compute or recall a travel time or a distance the tool did not return. On a failure, error_reason is one of "origin_required" (no start was given and the workspace has no address on file: ask the person where they leave from), "call_limit_reached" (this turn already asked enough trips), "daily_limit_reached" (the person or the workspace reached today's limit), "location_invalid" (the call gave no end, two ends, two starts or half a point: nothing was counted) or "travel_time_unavailable" (the travel time cannot be read now). Then say in the person's language that the travel time is not available and why, and give no figure.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
modeNoHow the person travels. Leave it out for "car" unless the person named another way.
originNoWhere the trip starts, only when it is known: the location of the person's previous event that day, or an address the person gave. Leave it out to start from the workspace's own address. Never give it with origin_latitude and origin_longitude.
destinationNoWhere the trip ends: the location of the event as the event or the mail states it, or an address the person gave. Copy it; never invent or complete an address. Give it or destination_place_id, never both.
departure_atNoWhen the person leaves, ISO 8601 with an offset. A car trip then reads traffic at that time.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
origin_latitudeNoThe latitude of a location the person shared in this conversation, in decimal degrees exactly as given, when the trip starts there. Give it with origin_longitude, and without origin.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
origin_longitudeNoThe longitude of a location the person shared in this conversation, in decimal degrees exactly as given, when the trip starts there. Give it with origin_latitude, and without origin.
destination_place_idNoWhere the trip ends, as the `place_id` of a place that well_search_places returned. Copy it as returned. Give it or destination, never both.

Output Schema

NameRequiredDescriptionDefault
modeNo
originNo
sourceNo
statusNo
successYes
distance_kmNo
origin_kindNo
error_reasonNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
duration_minutesNo
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / departure_at / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed8 schema fields changed
    • changedInput schema / properties / destination / description
      Previous value: -"Where the trip ends: the location of the event as the event or the mail states it, or an address the person gave. Copy it; never invent or complete an address."New value: +"Where the trip ends: the location of the event as the event or the mail states it, or an address the person gave. Copy it; never invent or complete an address. Give it or destination_place_id, never both."
    • addedInput schema / properties / destination_place_id
      Added value: +{
      +  "description": "Where the trip ends, as the `place_id` of a place that well_search_places returned. Copy it as returned. Give it or destination, never both.",
      +  "pattern": "^[A-Za-z0-9_-]{1,300}$",
      +  "type": "string"
      +}
    • changedInput schema / properties / origin / description
      Previous value: -"Where the trip starts, only when it is known: the location of the person's previous event that day, or an address the person gave. Leave it out to start from the workspace's own address."New value: +"Where the trip starts, only when it is known: the location of the person's previous event that day, or an address the person gave. Leave it out to start from the workspace's own address. Never give it with origin_latitude and origin_longitude."
    • addedInput schema / properties / origin_latitude
      Added value: +{
      +  "description": "The latitude of a location the person shared in this conversation, in decimal degrees exactly as given, when the trip starts there. Give it with origin_longitude, and without origin.",
      +  "maximum": 90,
      +  "minimum": -90,
      +  "type": "number"
      +}
    • addedInput schema / properties / origin_longitude
      Added value: +{
      +  "description": "The longitude of a location the person shared in this conversation, in decimal degrees exactly as given, when the trip starts there. Give it with origin_latitude, and without origin.",
      +  "maximum": 180,
      +  "minimum": -180,
      +  "type": "number"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "destination"
      -]
    • changedOutput schema / properties / error_reason / enum
      Previous value: -[
      -  "origin_required",
      -  "call_limit_reached",
      -  "daily_limit_reached",
      -  "travel_time_unavailable"
      -]New value: +[
      +  "origin_required",
      +  "call_limit_reached",
      +  "daily_limit_reached",
      +  "travel_time_unavailable",
      +  "location_invalid"
      +]
    • changedOutput schema / properties / origin_kind / enum
      Previous value: -[
      -  "stated",
      -  "workspace_address"
      -]New value: +[
      +  "stated",
      +  "workspace_address",
      +  "shared_point"
      +]
  3. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/openWorldHint/non-destructive, and the description layers on real behavioral context beyond them: the 12-calls-per-turn limit, daily limit, walk/bicycle beta caveat about missing sidewalks, exact error_reason taxonomy and what each means, and the multi-workspace auth rule. This is substantial disclosure the annotations cannot convey.

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 purpose and the per-event calling rule, and every paragraph carries operative instruction. It is dense and long, but the length is mostly justified by ten parameters and a rich error contract; a few heuristics could be tightened.

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?

Even though an output schema exists, the description still explains the return shape (status found/no_route, duration_minutes, origin_kind, distance_km omission for shared_point) and the failure contract. Nothing an agent needs to call or interpret this tool correctly is missing.

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. The description nevertheless adds resolution semantics the schema does not: how to derive `origin` (previous meeting within 60 minutes and under 10-minute walk, else saved home or that day's office), that `destination` must be copied verbatim, and the address-vs-point exclusion rules.

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 how long one trip takes and how far it is, from Google Maps') with concrete example phrasings. An agent can distinguish this from sibling reads like well_convert_time, well_get_weather or well_search_places without inspecting schemas.

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

Usage Guidelines5/5

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

Explicit when-to-call ('for each event that has a location when the person asks for the travel time: once per event and way of travel you compare'), when not to call ('An event with no location gets no call'), and routing to the sibling case that supplies place_id (well_search_places). Origin resolution and mode-default heuristics leave almost nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources