Skip to main content
Glama

Explore what's around a stay area

explore_nearby
Read-onlyIdempotent

Show the area around a recommended home as part of planning the trip, without waiting for a separate area question. Prefer propertyId for a home you recommend, including after narrowing a broad search to a country; use nearArea only for an exact locality the traveler chose. Pick two to four themes from their priorities: family beach outings and easy dinners, work cafés, sunsets or surf. Places come from a licensed open dataset covering the area; where no dataset covers it, the configured maps provider answers instead. Kinds are broad catalog groupings; a surf business does not establish a surf break or its quality. Inspect category and place evidence. Results do not verify swimming safety, opening hours or walking routes: distances are straight-line from the stored home when available, otherwise from its public locality center. Do not infer walkability, travel time or whether a car is needed from these distances alone; say those are unverified unless supported by independent route or transport evidence. Read distanceBasis and coverage before making proximity claims. Home lookups use the local catalog only; home coordinates are never returned. A missing origin is an explicit gap, never permission to substitute another city. Explain the most relevant places and cite returned source links. In MCP responses, include clickable Markdown links to the source and attribution URLs in each place's sources; naming the providers alone is not a link. Include the distance basis and material coverage gaps; do not claim a map or place cards were displayed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tripLabel": "<tripLabel>",
      "themes": "<themes>"
    },
    "name": "explore_nearby"
  }
}

Input Schema

NameRequiredDescriptionDefault
localeNoen
themesYes
nearAreaNoExact public stay-area key from get_stay_areas. Give this or propertyId.
radiusKmNoMaximum straight-line distance from the stored home or public locality center identified in the result.
tripLabelYesA short headline for this kind of trip in the traveler's language, e.g. 'Work week' or 'Family beach week'.
propertyIdNoA published home's id. Uses its stored home location when available, otherwise its public locality center. The result states which origin was used; home coordinates are never returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses data provenance (licensed open dataset, with the configured maps provider as fallback), what the results cannot verify (swimming safety, opening hours, walking routes), and how distance is derived. It also states hard privacy behavior ('home coordinates are never returned') and that a missing origin is an explicit gap rather than license to substitute another city.

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 origin-selection rules are front-loaded, and nearly every sentence carries an operative instruction rather than filler. The closing instructions about Markdown source links and not claiming a map was displayed are response-formatting detail that lengthens the text, but they remain actionable.

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 output schema, the description covers origin handling, distance basis, coverage gaps, source attribution, and privacy limits of the return payload. The only material omission is an explicit statement of what the result structure looks like beyond the named fields distanceBasis and coverage.

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 67% schema coverage, the description adds real meaning: themes must be drawn from the traveler's priorities and map to broad catalog kinds, propertyId versus nearArea selection rules are spelled out, and the agent is told to read distanceBasis and coverage before making proximity claims. The locale parameter is left unexplained, though its enum makes it self-evident.

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 description opens with a specific verb and resource ('Show the area around a recommended home') and frames it as part of trip planning, which tells an agent what it produces and when it fits. It does not explicitly separate itself from siblings like search_nearby_properties or get_stay_areas, so an agent must infer that boundary from the origin parameters.

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?

Strong routing guidance between the two origin parameters: 'Prefer propertyId for a home you recommend, including after narrowing a broad search to a country; use nearArea only for an exact locality the traveler chose.' It also tells the agent to pick two to four themes from traveler priorities. It stops short of stating when not to use this tool at all versus sibling search tools.

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