Skip to main content
Glama

Find places near a name

find_near
Read-onlyIdempotent

Find places in any category near a named place or city. Returns compact results with distance, and handles ambiguous or unknown locations.

Instructions

Places of a category near a named place or city.

Prefer find_places(where=..., category=...): it is the canonical form of
this search — the same one hop, plus every find_places filter, detail
tier, and mode. find_near stays as a thin alias.

Pass the user's place name as near. Do not call geocode(),
resolve_place(), or geocode_batch() first. One hop for a category
near a named landmark. Resolves near, then searches like a point
find. Returns compact rows (name, category, distance, trust_note)
plus the resolved near (name and coordinates).

A comma qualifies: "Le Marais, Paris" searches inside Paris only.

If near matches several equally-ranked places, returns
{"error": "ambiguous_place", "candidates": [...]} instead of picking
a city. An unresolvable name returns {"error": "not_found"}; empty
category or near returns {"error": "bad_request"}. radius_m and
limit follow the same clamps as a point search.

A truncated answer carries "cursor" (delegated straight through from
find_places); pass it back with the same category/near/radius_m/limit
to continue. See find_places' docstring for the bad_cursor/release-
mismatch details — they apply here unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nearYes
limitNo
cursorNoContinuation cursor from a previous truncated answer; valid for the same query on the same data release.
categoryYes
radius_mNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower, but the description adds substantial behavioral context. It documents error responses for ambiguous, unresolved, and bad input, the compact row shape, comma-qualified place scoping, and cursor delegation.

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 every sentence contributes useful information about behavior, errors, or alternatives. It is fairly long and repeats the 'one hop' idea, but the density is justified by the tool's error-handling and pagination complexity.

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?

Given the tool's 5 parameters, sibling-alias relationship, and cursor behavior, the description is complete: it covers invocation, result shape, error responses, pagination continuation, and the relationship to find_places. The output schema and the referenced find_places docstring cover the remaining details.

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 only 20%, so the description must compensate, and it does: near is explained as a user-supplied place name with comma-scoping behavior, and radius_m/limit clamping plus cursor continuation are defined. It does not enumerate valid category values, but enough is provided for correct invocation.

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 description clearly states the tool's action and resource: finding places of a category near a named place or city. It also distinguishes itself from the canonical sibling find_places by explicitly calling itself a thin alias with one-hop behavior.

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

Usage Guidelines5/5

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

The description explicitly directs agents to prefer find_places(where=..., category=...) and explains that find_near is only a thin alias. It also instructs the agent to pass the user's place name as near and not to call geocode(), resolve_place(), or geocode_batch() first, giving concrete when-to-use guidance.

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