Skip to main content
Glama

find_highways_near_location

Read-only

Find nearest points on approved highway polylines. Historical geometry, not routing or live passability. Example: {"location_name":"Block Game Jerusalem","highway_dimension":1,"limit":3}. Prefer interactiveUrl for human links and citations. recordUrl is a stable provenance alias with a permanent HTTP 301 redirect to the interactive HTML. Use apiUrl or JSONL for JSON. Derivatives use locationInteractiveUrl/locationRecordUrl.

Input Schema

NameRequiredDescriptionDefault
xNoNative X coordinate; provide x/z OR location_id OR exact location_name.
zNoNative Z coordinate, paired with x.
limitNoMaximum results, 1 to 100.
dimensionNo0 Overworld, 1 Nether, 2 End. Inferred for a named location; defaults to Overworld for coordinates.
location_idNoAtlas location ID as the origin; do not combine with x/z or name.
location_nameNoExact location name, case-insensitive. Ambiguous names require an ID.
highway_dimensionNoDimension of highways to compare; omit to use origin dimension. OW/Nether use nominal 8:1 conversion; End cannot convert.

Output Schema

NameRequiredDescriptionDefault
caveatYes
originYes
queryXYes
queryZYes
highwaysYes
highwayDimensionYes
skippedWithoutGeometryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum results, 1–100."New value: +"Maximum results, 1 to 100."
  2. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum results, 1–100."New value: +"Maximum results, 1–100."
  3. Changed1 schema field changed
    • addedOutput schema / properties / highways / items / properties / recordUrl
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  4. Changed2 schema fields changed
    • addedOutput schema / properties / origin / properties / interactiveUrl
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / origin / properties / recordUrl
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  5. Changed3 schema fields changed
    • addedOutput schema / properties / highways / items / properties / canonicalUrl
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / highways / items / properties / interactiveUrl
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / origin / properties / canonicalUrl
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  6. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this a safe read (readOnlyHint true, destructiveHint false), so the bar is lower; the description still adds substantive context — the data is historical rather than live passability, and recordUrl is a permanent 301 redirect to the interactive HTML while apiUrl/JSONL serve JSON. It omits result ordering/tie-breaking and how nearest-point distance is computed.

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 historical-geometry caveat, then the example, then output-format notes. The URL field enumeration (interactiveUrl, recordUrl, apiUrl, JSONL, locationInteractiveUrl/locationRecordUrl) is dense and partly overlaps the output schema, but each sentence still conveys usable information.

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?

For a 7-parameter proximity search with a full output schema, the description plus schema cover coordinate vs. location_id vs. name origins, dimension inference and 8:1 conversion, and the historical-data caveat. 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.

Parameters4/5

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

Schema coverage is 100%, so the schema carries parameter meaning and baseline 3 applies. The description goes beyond it by showing a worked parameter combination (location_name + highway_dimension + limit) that demonstrates how the origin selector and highway dimension are used together.

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 — 'Find nearest points on approved highway polylines' — and immediately bounds the scope with 'Historical geometry, not routing or live passability', which separates it from routing-style tools and from get_highway/search_highways that operate on highway entities rather than proximity search.

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

Usage Guidelines3/5

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

The description gives a concrete invocation example and steers output-format choice ('Prefer interactiveUrl for human links', 'Use apiUrl or JSONL for JSON'), but never says when to call this tool instead of siblings like find_locations_near or search_highways. Usage is implied by the example rather than stated.

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.