Skip to main content
Glama

places_in_view

What is over THERE: given a position and the direction the user is facing, the places inside that cone, and whether the ground and the buildings in between let them actually be seen. Use this for "what is that over there", "is there a pub in that direction", "what am I looking at". Use nearby_places instead when the question is about what is NEAR a point rather than what is in a direction. Provide lat, lon, bearing_deg (degrees CLOCKWISE FROM TRUE NORTH: 0 north, 90 east, 180 south, 270 west) and at least one of category or name; category=building reaches named buildings. Optional fov_deg is the FULL width of the cone (default 60, so 30 degrees either side), radius_m the range (default 1000, max 5000), eye_height_m the observer's eye height (default 1.6). Each result carries distance_m, bearing_deg, a signed angular_offset_deg (negative left, positive right), a spoken direction, and a visibility block. READ THE VISIBILITY BLOCK BEFORE SAYING ANYTHING: clear means nothing in the data stands in the way, occluded names what does (a hill, or a building with its height), and unknown means NO check could run: with unknown say you cannot tell, never that it is visible. Read basis too: terrain-only in a town means hills were checked and buildings were not, which is weak. A non-zero out_of_sector means there ARE matching places nearby, just not in that direction, so say that rather than "nothing nearby". coverage names the datasets that answered and caveat is the standing limit: visibility is modelled from maps, not observed, and trees, walls, scaffolding and weather are not in it. Requires the MapMap gateway (GATEWAY_URL + GATEWAY_API_KEY).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesLatitude of the observer in decimal degrees (−90 to 90).
lonYesLongitude of the observer in decimal degrees (−180 to 180).
nameNoA place name or brand to look for. At least one of `category` and `name` is required.
limitNoMaximum number of results (1–25, default 5).
fov_degNoFull width in degrees of the cone centred on `bearing_deg` (1–360, default 60, so 30 degrees either side). The FULL width, not the half angle.
categoryNoThe kind of place to look for, from the same vocabulary `nearby_places` uses ("cafe", "pub", "fuel", "charging_station" …). Use "building" to ask what a named building over there is. At least one of `category` and `name` is required.
radius_mNoMaximum straight-line range in metres (1–5000, default 1000).
bearing_degYesWhich way the observer is facing, in degrees **clockwise from true north** (0 = north, 90 = east, 180 = south, 270 = west). Required: this tool answers "what is over there", and "there" has to point somewhere.
eye_height_mNoHeight of the observer's eye above the ground in metres (0–500, default 1.6, a standing adult). A driver's eye is nearer 1.2 m.
visible_onlyNoWhen true, return only places whose visibility verdict is `clear`. Default false, which returns everything in the cone WITH its verdict, usually the better answer, because "it is there but you cannot see it from here" is worth saying.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
caveatYesThe standing caveat: visibility here is modelled, not observed.
resultsYesPlaces inside the cone, best first: everything visible before everything unchecked before everything occluded, and within each of those, nearest and most nearly dead-ahead first.
coverageYesOne sentence naming which datasets the visibility verdicts were actually checked against. Worth repeating when a verdict is being relied on.
out_of_sectorNoHow many otherwise-matching places were dropped for lying outside the cone. Non-zero means there ARE matching places near the observer, just not in the direction they are facing, so say that rather than "nothing nearby".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description bears the full burden of behavioral disclosure, and it delivers: it explains the three visibility verdicts, instructs the agent to read the visibility block before speaking, warns that `unknown` must not be reported as visible, explains `basis`, `out_of_sector`, `coverage`, `caveat`, and the model's limits (trees, walls, scaffolding, weather). It even mentions the required MapMap gateway. This is exemplary transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every clause earns its place: purpose, examples, sibling routing, parameter defaults, output-reading rules, and caveats are all packed densely without repetition. The most important direction semantics and visibility-reading instructions are front-loaded, and the auth requirement is saved for the end. Nothing is wasted.

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 tool with 10 parameters, an output schema, no annotations, and subtle output semantics, the description is complete: it tells the agent what inputs to supply, what the key output fields mean, how to react to `unknown` and `out_of_sector`, what the standing limitations are, and what infrastructure is required. An agent has everything needed to invoke it 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics beyond the schema: `bearing_deg` is clockwise from true north, `fov_deg` is the FULL cone width (30 degrees either side of default), `eye_height_m` has a standing-adult default, and `category=building` is a named-building shortcut. It doesn't explicitly discuss `visible_only` or `limit`, but the schema documents those well, so the added value receives a 4.

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 opens with a specific, memorable framing—'What is over THERE'—and states the exact inputs (position, facing direction) and outputs (places in the cone, visibility verdicts). It also explicitly names the sibling it is not: `nearby_places`. This makes the tool's identity and scope immediately distinguishable.

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?

It gives concrete example queries ('what is that over there', 'is there a pub in that direction') and an explicit routing rule: use `nearby_places` when the question is about proximity rather than direction. It also tells the agent that `category=building` reaches named buildings and warns about reading `out_of_sector`. The when-to-use guidance is unambiguous.

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.

Resources