Skip to main content
Glama

Check within distance

within_distance
Read-onlyIdempotent

Check whether a place matching a category or name exists within a given distance from a location. Returns the nearest match and its distance, or confirms none is found in range.

Instructions

Is the nearest place matching category/name within max_distance_m of (lat, lon)?

Give the center as lat/lon, or as `where` — a {"lat", "lon"} dict, a
GERS id, or a free-text place name — but not both (and not neither);
either way returns {"error": "bad_request"} naming the choice. A
`where` given as an id/name adds a compact "resolved": {"name", "id",
"lat", "lon", "matched_by"} to the answer; absent for lat/lon or a
{lat,lon} where.

max_distance_m is required and must be a positive number of meters — a
zero, negative, non-finite, or missing value returns {"error":
"bad_request"} rather than silently searching a 0m (or omitted from a
call entirely, in which case the schema itself rejects it before this
tool ever runs) window and answering a confident-looking "false".

Returns {"within": bool, "nearest": {...place row with id...} | None,
"distance_m": float | None}. nearest is None if nothing matches within
a search window capped at max_distance_m * 2 — a real match further out
than that isn't found (documented, not a bug: keeps the search bounded).
name is a literal substring match only — no alt-spelling or typo
fallback applies here, so a misspelled name is an honest "no match",
never a silent yes about a different name.
Returns a structured {"error": ...} if upstream is unavailable or the
dataset is missing columns this tool depends on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
nameNo
whereNo
categoryNo
max_distance_mYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.2/5.0
Behavior5/5

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

The description explicitly documents the error contract: bad_request for ambiguous center choices and for invalid max_distance_m, plus upstream/dataset failure errors. The detailed note about not silently returning a confident-looking 'false' for a zero or missing distance is especially valuable, and the conditional 'resolved' behavior is disclosed.

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 organized into clear blocks: center choice, distance validation, and return value/errors. Every sentence adds operational value; the zero-distance parenthetical is slightly long but earns its place by preventing a subtle misuse.

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?

For a six-parameter tool with no schema-level descriptions, this covers input alternatives, validation, return shape, and error outcomes exceptionally well. The output schema supplies remaining return details, but a bit more clarity on category/name matching semantics would make it fully complete.

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 description coverage is 0%, so the description must compensate. It does well by explaining max_distance_m requirements, the three `where` forms, the exclusivity of lat/lon vs `where`, and the conditional `resolved` field. Minor gaps remain: it does not fully define how category/name matching behaves or explicitly require lat and lon as a pair.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening question defines a precise boolean check: whether the nearest place matching category/name is within max_distance_m of a center. It distinguishes this from sibling list/detail tools by its predicate and matching criteria, though it never explicitly names a 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?

The description clearly frames the tool as a proximity test and fully specifies acceptable center inputs, so an agent can infer when it applies. It does not mention alternative tools or provide explicit when-not-to-use guidance, which keeps it from a 5.

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