Skip to main content
Glama

Water near a point

water_near
Read-onlyIdempotent

Check water proximity for any point: returns distance to rivers, canals, lakes, oceans, and detects if the point is inside a water polygon. Filter by subtype, class, and search radius.

Instructions

Water near a point, nearest first: waterfront check, distance to river/canal/lake.

From Overture's base theme (issue #200), type=water — oceans, bays,
lakes, ponds, reservoirs, rivers, streams, canals, springs, pools.
Returns {"center", "radius_m", "in_range_count", "results": [{"name"
(when named), "subtype", "class", "distance_m", "is_salt"/
"is_intermittent" (only when true)}, ...]}, plus "truncated": true and
a "note" when more matched than were returned. No raw geometry.

distance_m is to the closest point on the feature, not its centroid —
a canal bank you are standing on reads ~0 m. Water gets dense (an
Amsterdam canal district puts hundreds of rows in a 500 m circle),
which is what in_range_count and the filters are for:
subtype/water_class match Overture's `subtype`/`class` columns
(case-insensitive substring; water_class is `class` under a
non-reserved name) — e.g. subtype="canal", subtype="river",
water_class="lake".

"on_water": true plus "water_body" means the point is *inside* a water
polygon — a lake, a reservoir, a river. For oceans and seas that is a
coarse signal: Overture cuts them into 1-degree tiles whose landward
edge covers dry coastal land, so a waterfront building reads as inside
the ocean. Those bodies are reported this way rather than as a bogus
0 m "nearest water" row, and no distance-to-coast is derived from them
(their tile boundaries include phantom cuts through open water), which
also means subtype="ocean" cannot return distance rows. Lakes and
rivers carry none of that: however large, they appear in results with
a real edge distance. The "note" says which case applies.

An empty results list is a valid answer: coverage is OSM-derived, and
"no water within 500 m" is a real finding about an arid or unmapped
place. radius_m echoes the effective radius (large values are
clamped). Returns a structured {"error": ...} if upstream is
unavailable or the dataset is missing geometry/bbox, and {"error":
"bad_request"} for a bad coordinate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYes
lonYes
limitNo
subtypeNo
radius_mNo
water_classNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as read-only and idempotent, but the description adds substantial behavior beyond them: distance is to the closest point rather than centroid, no raw geometry is returned, ocean tiles cause phantom land overlap, radius is clamped, and error response shapes are detailed. It also explains the dense-water scenario and in_range_count purpose. No annotation contradiction exists.

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?

The description is front-loaded with the core purpose and each subsequent paragraph adds important caveats (distance semantics, ocean artifacts, empty-result validity, error behavior). It is dense and somewhat monolithic, and could be improved with bullet points or section breaks, but no sentence is pure filler.

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 complex filtering/query tool, the description is nearly exhaustive: it covers output shape, distance semantics, water classes, ocean edge cases, truncation, clamping, error handling, and data-coverage caveats. The presence of an output schema reduces the need to enumerate return fields, and the description still adds the semantic details needed to interpret them correctly.

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?

With 0% schema description coverage, the description compensates well for most parameters: radius_m (clamping, effective radius), subtype (case-insensitive substring, examples, ocean restriction), water_class (maps to class), and coordinates (bad_request error). It does not explicitly explain the 'limit' parameter as the maximum result count, only implying it through 'truncated': true and the results array.

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 first sentence, 'Water near a point, nearest first,' names a specific resource (water bodies) and behavior (distance-ordered), and the phrase 'waterfront check, distance to river/canal/lake' scopes it. It is clearly distinguishable from sibling tools by focusing exclusively on water features and explicitly disclaiming raw geometry.

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?

The description provides clear use context: waterfront checks, distance queries to specific water subtypes, and how to filter with subtype/water_class. It also states a when-not ('subtype="ocean" cannot return distance rows') and notes that empty results are a valid answer. However, it never names alternative sibling tools, so an agent must infer which other tool to choose when water info is not the goal.

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