Skip to main content
Glama

Running Cat Geo

Stops along a route

stops_along_route
Read-only

Places to stop along a route: drinking water, food, groceries, toilets, bike shops and fuel by default; on request places to sleep, sights, charging points, benches and picnic sites. The route is GeoJSON in [lon, lat] order, such as {"type": "LineString", "coordinates": [[6.1432, 46.2044], [6.2, 46.15], [6.8694, 45.9237]]}, or a MultiLineString of sections in order; a route from plan_route works once you have its full line. Each stop comes with km (kilometres from the start along the route), offsetM (metres from the route to the place), category, subtype, name, [lon, lat] and, where OpenStreetMap has them, opening_hours, brand, fee and similar tags. Stops are sorted by km, nearest to the route first at the same km. How far off the route a place may be depends on the category: 150 m for water and toilets, 200 m for food, groceries, bike shops and fuel, 300 m for charging and picnic sites, 100 m for benches, 1 km for places to sleep and sights. gaps lists stretches of over 40 km with no water or food, with their start and end km; totals counts stops per category. A very long answer has its longest lists cut and says so. Counts as one request.

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": {
      "route": "<route>"
    },
    "name": "stops_along_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
routeYesGeoJSON LineString or MultiLineString, coordinates as [lon, lat]
categoriesNoCategories to find; default water, food, grocery, toilets, bike, fuel

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds substantial behavioral detail: per-category search radii (150 m water/toilets up to 1 km sleep/sights), gap reporting over 40 km, totals per category, truncation of very long lists with a notice, and the quota note "Counts as one request." These are exactly the operational facts an agent needs before calling and are not derivable from the annotations.

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?

Content is front-loaded (purpose, then input format, then return fields, then radii, then gaps/totals, then truncation) and every sentence carries information. It is a dense single block rather than a structured list, which makes the radii and return-field details slightly harder to scan than they could be.

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?

There is no output schema, and the description compensates fully by describing each returned field (km, offsetM, category, subtype, name, coordinates, OSM tags), the sort order, and the gaps/totals structures. For a two-parameter read-only tool this is complete.

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 100%, so the baseline would be 3, but the description goes beyond it: it gives a concrete GeoJSON example, fixes the [lon, lat] ordering, explains MultiLineString section ordering, and states the default category list plus the category-dependent radius behavior. The schema enum alone does not convey those defaults or the per-category distance semantics.

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 names a concrete resource (places to stop along a route) and enumerates the default categories plus the on-request ones, so the agent knows exactly what the tool returns. It also positions itself relative to plan_route ("a route from plan_route works once you have its full line"), which removes ambiguity with the most likely sibling.

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?

It states the default category set and the categories that must be requested explicitly, and explains how to feed in a route produced by plan_route. It does not say when to prefer another sibling (e.g. where_is or point_report for a single place), so usage context is clear but not exhaustive.

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