goplaces MCP

Overview Schema Source Related Servers Discussions Admin

Search near coordinates

goplaces_nearby

Read-onlyIdempotent

Search Google Places near a latitude/longitude within a radius. Returns compact nearby place summaries, with optional type filters, ranking, and travel distances.

Instructions

Search Google Places near a latitude/longitude within a radius. Use when the user gives coordinates or you already resolved a location. Returns compact place summaries.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	Yes	Latitude for a circular location bias/restriction.
`lng`	Yes	Longitude for a circular location bias/restriction.
`limit`	No	Maximum number of nearby results.
`region`	No	Optional CLDR region code, for example 'US' or 'DE'.
`rank_by`	No	Result ordering. Defaults to Google's popularity ranking.
`language`	No	Optional BCP-47 language code, for example 'en' or 'en-US'.
`radius_m`	Yes	Radius in meters for the circular location bias/restriction.
`include_ev`	No	Include EV charging connectors, charge rates, and availability.
`origin_lat`	No	Latitude to measure travel from. With origin_lng, each result gains distance_meters and duration_seconds, avoiding a directions call per result.
`origin_lng`	No	Longitude to measure travel from. Must be paired with origin_lat.
`origin_mode`	No	Travel mode for origin distances. Google does not support transit here.	drive
`detail_level`	No	Field tier to request. Google bills at the most expensive tier in the request, so prefer the cheapest that answers the question: 'ids' returns place IDs only, 'basic' adds name, address, location, type, and a Maps link, and 'full' adds rating, price, hours, phone, and website.	full
`excluded_types`	No	Excluded Google place types.
`included_types`	No	Included Google place types, e.g. ['cafe'] or ['restaurant', 'bar'].
`include_atmosphere`	No	Include the most expensive tier: editorial summary, dine-in/takeout/delivery/reservable, accessibility, and parking options.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No	Present only on failure; the result is also flagged isError.
`results`	No	Places inside the radius.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 12, 2026

TDQS

B3.4/5.0

Behavior2/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. Beyond that, the description adds almost nothing behavioral and notably omits billing-sensitive behavior that the schema itself flags (the detail_level and include_atmosphere cost tiers), which is the single most important behavioral fact for this tool. Rate limits and result caps are also unmentioned.

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?

Three sentences, front-loaded with the core operation, and no filler. The return-format sentence is placed after usage guidance, which is reasonable; slightly could be trimmed but generally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich schema, output schema, and full annotation coverage, the description does not need to explain parameters or return values. However, for a 15-parameter, cost-sensitive tool, it omits the billing-tier warning and sibling differentiation that an agent selecting between goplaces_search and goplaces_nearby needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 15 parameters including the billing-tier semantics of detail_level and origin-distance optimization. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb (Search) and resource (Google Places) with the spatial constraint (near a lat/lng within a radius). It is distinct from goplaces_search, but the description does not explicitly name that sibling to differentiate the coordinate-based vs. text-based use case.

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?

'Use when the user gives coordinates or you already resolved a location' gives a clear triggering condition. It lacks explicit exclusion guidance (e.g., when to prefer goplaces_search for free-text queries), keeping it just under a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server