Skip to main content
Glama
Sign In

Listing Location Toolkit

by io.github.Nero-Engine
OverviewDiscussionsAdmin

Nearby lakes, coast, peaks, parks and attractions

nearby_nature
Read-onlyIdempotent

Notable named places near an address, grouped: lakes and reservoirs, rivers, coast and beaches, islands, mountains, national parks, parks and nature reserves, golf, ski and marinas, museums and attractions. Each with miles, direction and (by default) drive minutes. Says when the site is on the water or inside a national park, measured from the real OpenStreetMap outline. Source Wikidata (CC0). US and UK.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nearby_nature"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoLatitude in decimal degrees (use with lon instead of address).
lonNoLongitude in decimal degrees.
addressNoStreet address with town and ZIP or postcode, e.g. "7090 State Highway 80, Cooperstown, NY 13326" or "Ambleside LA22 9BB". Not needed when lat and lon are given.
countryNoOptional hint for the address lookup.
categoriesNoLimit to these groups. Default all.
per_categoryNoPlaces per group. Default 4, max 10.
radius_milesNoSearch radius. Default 20, max 40.
drive_minutesNoAdd drive minutes to the closest places (one router call). Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), and the description adds real behavioral context beyond them: data provenance (Wikidata CC0), the OSM-outline measurement method, the default inclusion of drive minutes, and the note that this costs one router call. It stops short of describing result ordering or failure modes for ambiguous addresses.

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?

Purpose and scope are front-loaded and every element is substantive, but the nine-item category listing largely duplicates the schema enum and the telegraphic fragment style ("US and UK.") reads as clipped notes rather than polished prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With eight optional parameters and no output schema, the description compensates by naming the returned fields (miles, direction, drive minutes) and the on-the-water / inside-park flags, which is the key information an agent needs to interpret results. Missing only guidance on result ordering and address-resolution failure.

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

Parameters3/5

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 lat/lon vs address, the country enum, categories, per_category, radius_miles and drive_minutes. The description only reinforces the drive-minutes default; it adds no format or edge-case guidance (e.g. what happens with both address and lat/lon, or the unit of per_category behavior). Baseline 3 applies.

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?

Opens with a specific verb-and-resource phrase ("Notable named places near an address, grouped") and enumerates the exact categories returned, so an agent can separate it from schools_nearby, crime_nearby or daily_needs without opening the schema. Scope (US and UK) is stated explicitly.

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?

Usage is implied by the content and geography constraints, but the description never states when to prefer this over area_profile or listing_location_pack, nor any when-not condition or prerequisite. An agent must infer the choice from category vocabulary alone.

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

All Listing Location Toolkit toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources