Skip to main content
Glama

Distance matrix

distance_matrix
Read-onlyIdempotent

Calculate straight-line (great-circle) distances in meters between up to 10 origins and 10 destinations for spatial analysis.

Instructions

Straight-line (great-circle) distance in meters between every origin and destination.

origins and destinations are each a list of LocationRefs — a {"lat":
..., "lon": ...} dict, a GERS id, or a free-text place name, mixed
freely — capped at 10 each (100 pairs max). This is a plain haversine
calculation, not a routed distance or travel time, so it's cheap but it
is NOT what Google/Mapbox distance-matrix APIs return: no roads, no
turns, no travel time. For "how far can I get in N minutes" use
isochrone() instead; for actual routed times/distances between several
points use travel_time_matrix().

An id/name that failed to resolve returns an indexed error
(origins[i]: ... or destinations[i]: ...) with candidates on ambiguity
— checked after the 10-point cap, so an over-cap list always fails on
the cap first. Any origin/destination given by id/name adds "resolved":
{"origins": [{"index", "name", "id", "lat", "lon", "matched_by"}, ...],
"destinations": [...]} covering just those entries; each side is
present only if it had a string entry, and the whole key is absent when
every point was already coordinates.

Returns {"elements": [{"origin_idx": 0, "dest_idx": 0, "distance_m":
812}, ...]}, flat and origin-major (all destinations for origin 0,
then origin 1, ...), budgeted like every other tool. Empty origins or
destinations returns {"elements": []}. Returns a structured {"error":
"bad_request", ...} instead of raising if either list exceeds 10
points or a point is missing/non-numeric lat or lon.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
originsYes
destinationsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds substantial behavioral context beyond that: the 10-point cap with 100-pair limit, error handling for unresolved names with indexed errors and ambiguity candidates, check ordering (cap fails first), the 'resolved' field behavior, flat origin-major return order, empty-input handling, and structured bad_request errors. No contradiction with annotations.

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 long but every sentence earns its place. The first sentence front-loads the core function, then paragraphs cover scope limits, alternatives, error semantics, resolved-field behavior, output format, and edge cases. There is no fluff or repetition; dense paragraphs are organized by topic.

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?

Despite the output schema being present, the description also details the return shape and ordering, covers empty input, error behavior, id/name resolution, and budget hints. With sibling differentiation and clear parameter semantics, nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the full burden. It fully compensates by explaining that origins and destinations are lists of LocationRefs with three acceptable forms (lat/lon dict, GERS id, free-text name), that they can be mixed freely, that each is capped at 10, and how unresolved strings are reported. This goes far beyond the plain array/string schema.

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?

The description opens with a precise verb+resource statement: 'Straight-line (great-circle) distance in meters between every origin and destination.' It immediately distinguishes itself from routed-distance or travel-time tools by calling the calculation a plain haversine and explicitly saying what it is NOT, which differentiates it from travel_time_matrix and Google/Mapbox APIs.

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?

The description gives explicit when-to-use and when-not-to-use guidance, naming alternatives: use isochrone() for 'how far can I get in N minutes' and travel_time_matrix() for routed times/distances. It also characterizes the tradeoff (cheap but not routed), making the selection rationale clear.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chuofringer/placeroot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server