Remap generates routes for cycling, running and walking anywhere on Earth.
Scored across 2 tools
find_place is a pure place-lookup helper and generate_routes produces loop routes; their purposes are clearly distinct. The descriptions actively prevent misselection by ruling out directions A-to-B, driving, and the find_place+generate_routes overlap is explicitly described as a pre-check flow.
Both tools follow a clean verb_noun snake_case pattern (find_place, generate_routes) with no deviation or mixed conventions.
With only two tools the surface feels thin: find_place is essentially an optional helper for generate_routes, so the practical capability set is close to a single operation. It is reasonable for a narrow loop-route service but leaves little room for adjacent operations.
For its stated scope (generate a loop route from a start point, with an optional place-resolution step) the surface is essentially complete and includes fallback behavior when no start is given. Gaps exist for adjacent needs such as retrieving or managing previously generated routes, but core workflow is covered.
Look up a place by name or address and return matching places with their coordinates. Use it to confirm an ambiguous start before generating routes.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Place name or address to look up. | |
| near_lat | No | Optional latitude to prefer nearby matches. | |
| near_lng | No | Optional longitude to prefer nearby matches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that matches come back with coordinates, which is genuinely useful since there is no output schema, but it says nothing about ranking, match count, or ambiguity handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the core purpose front-loaded and the usage note second. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with full schema coverage and rich annotations, this is nearly sufficient. The remaining gap is that it never clarifies whether multiple matches are returned or how near_lat/near_lng affect ordering, which matters for an ambiguous-name lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, near_lat and near_lng. The description's 'by name or address' merely restates the query parameter and never explains how the proximity coordinates bias results, so it adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('look up a place by name or address') and what comes back ('matching places with their coordinates'). The closing clause ties it to the routing workflow, which implicitly separates it from the sibling generate_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it to confirm an ambiguous start before generating routes' gives a concrete triggering condition and names the downstream tool. It stops short of stating when not to use it (e.g., when a place is already unambiguous or when routing is not needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a cycling, running or walking route that starts and finishes at the same place, with a target distance or duration and optional climbing and scenery preferences. Do not use it for directions from one place to another or for driving. Shows the routes on a map where the host supports it, and always returns a link that opens the same request in Remap. Give either start (place text such as "Tempelhofer Feld, Berlin") or lng and lat, never both. When the person has not said where, call generate_routes without a start: the map asks for the person’s location and generates routes from there.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Start latitude in degrees, when the start is known as a coordinate. | |
| lng | No | Start longitude in degrees, when the start is known as a coordinate. | |
| sport | Yes | The activity. Walking generates foot routes at walking pace. | |
| start | No | Where the route starts and finishes, as place text (a town, park, street or address). | |
| climbing | No | flat avoids hills, balanced neither seeks nor avoids them, hilly looks for climbs. | |
| distance | No | Target distance of the whole route. | |
| environments | No | Scenery to favour where the area has it. forest: through forest; parks: through parks and nature reserves; waterside: along rivers, canals and lakes; coast: along the coastline; climbs: over hills worth climbing; quiet_streets: through calm residential streets and lanes; long_stretches: along long, quiet, uninterrupted stretches; cycle_routes: following signed cycle routes (cycling only). | |
| distance_unit | No | Unit of distance: km or mi. Defaults to km. | |
| duration_minutes | No | Target duration in minutes, instead of a distance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered; the description goes further by disclosing that routes render on a map where the host supports it, that a Remap link is always returned, and how the no-location path behaves. It does not say how a conflicting distance-and-duration pair is resolved or what happens when a start cannot be geocoded, which are the remaining behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the use case, then exclusions, then return behavior, then the parameter constraint and fallback — a sensible order with no filler sentences. The opening sentence is dense and the loop concept is restated slightly, but nothing is genuinely wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return-value burden and does so: map rendering plus an always-present Remap link. Combined with the exclusivity rule for start vs lng/lat and the fallback flow, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description earns above baseline by stating a constraint the schema never encodes — 'Give either start or lng and lat, never both' — plus a concrete place-text example and the no-start fallback. It adds little for the enum fields beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb (generate) and resource (routes) and pins the scope precisely: loop routes for cycling/running/walking with a distance or duration target. It also excludes what it is not ('directions from one place to another or for driving'), so an agent can separate it from the find_place sibling without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use, when-not-to-use, and a concrete fallback path: 'When the person has not said where, call generate_routes without a start' and let the map prompt for location. This is exactly the routing guidance an agent needs, including the edge case where the required context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_placegenerate_routesPlan trips on a map: routed transport, day-by-day itineraries, and a plan you can share.
Heart-shaped GPS running routes in 200+ cities — charity, gift, memorial, anniversary.
Routing, geocoding, places, matrix and map tools for location-aware AI workflows.
Look up elevation worldwide, profile route ascent/descent, grid areas, check terrain line of sight.
Add one secure layer between your agents and this server.