Skip to main content
Glama

Vee3

by io.github.Vee3io

google-maps.search

Search Google Maps by text query.

Optional filters include location, radius (defaults to 1000 meters), open_now, min_price, max_price, place_type, language, and region. Pass cursor from a previous cursor_next to fetch the next page.

Returns matching places in places with names, full_address, place_id, ratings, and location. Use place_id with place detail, review, and photo endpoints.

cursor_next and cursor_previous appear only when pagination cursors are available. Additional upstream fields may appear.

Cost = 10 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query for places (for example restaurants in Paris).
cursorNoPagination cursor from cursor_next on a previous response.
radiusNoSearch radius in meters (default 1000).
regionNoTwo-character region code (for example us). On search endpoints this biases results by ccTLD. On place endpoints this selects regional place data.
languageNoLanguage code for results (for example en).
locationNoOptional latitude and longitude bias point (for example 40,-110). A location embedded in the query may override this.
open_nowNoWhen true, return only places open for business at query time.
max_priceNoMaximum price level (0–4, inclusive).
min_priceNoMinimum price level (0–4, inclusive).
place_typeNoRestrict results to a single Google Maps place type (for example restaurant).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
placesNoMatching places from the text search. Additional upstream fields may appear.
cursor_nextNoCursor for the next page when more results are available.
cursor_previousNoCursor for the previous page when available.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • changedOutput schema / $defs / GoogleMapsSearchResponsePlacesItem / properties / rating / anyOf
      Previous value: -[
-  {},
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / $defs / GoogleMapsSearchResponsePlacesItemLocation / properties / latitude / anyOf
      Previous value: -[
-  {},
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / $defs / GoogleMapsSearchResponsePlacesItemLocation / properties / longitude / anyOf
      Previous value: -[
-  {},
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed2 schema fields changed
    • changedOutput schema / $defs / GoogleMapsSearchResponsePlacesItem / properties / types / anyOf
      Previous value: -[
-  {
-    "items": {
-      "$ref": "#/$defs/GoogleMapsSearchResponsePlacesItemTypesItem"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedOutput schema / $defs / GoogleMapsSearchResponsePlacesItemTypesItem
      Removed value: -{
-  "additionalProperties": true,
-  "properties": {
-    "type": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Place type label.",
-      "title": "Type"
-    }
-  },
-  "title": "GoogleMapsSearchResponsePlacesItemTypesItem",
-  "type": "object"
-}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses the default radius, pagination cursor behavior, presence of cursor fields, possibility of additional upstream fields, and token cost. It does not mention error handling or rate limits, but for a read-only search tool, it provides solid behavioral coverage.

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 well-structured: purpose first, then filters, return data, pagination, and cost. Every sentence contributes useful information, with no fluff or redundancy. It is appropriately sized for a tool with 10 parameters.

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?

Despite having an output schema, the description still summarizes return fields and cross-references place_id with related endpoints. It covers pagination, default radius, filters, and cost. It is sufficiently complete for an agent to select and invoke the tool correctly.

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 baseline is 3. The description lists all optional filters and repeats the default radius and cursor usage, but these details are already present in the schema. It adds a convenient summary but no new semantic meaning beyond the schema.

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 verb and resource: 'Search Google Maps by text query.' It clearly states the tool searches for places and lists return fields, distinguishing it from sibling tools like nearby_search, which likely focuses on location-based search. It also explicitly ties place_id to other endpoints.

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 gives clear context on how to use the tool: text query, optional filters, pagination via cursor, and downstream use with place endpoints. However, it does not explicitly mention when to use this tool instead of nearby_search or other alternatives, so it lacks explicit exclusions.

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

All Vee3 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct purpose, further clarified by group prefixes and clear descriptions. Within each group, tools perform different operations (e.g., domains.lookup vs. domains.whois vs. domains.rdap) with no ambiguity.

Naming Consistency5/5

All tools follow a consistent group.tool_name pattern using snake_case. The naming is predictable and uniformly applied across all groups.

Tool Count4/5

78 tools is high, but the server aggregates multiple distinct API domains (11 groups). Each group has a reasonable number of tools, typically under 10, with TikTok having 17. The count reflects breadth, not bloat.

Completeness5/5

Each domain's tool set covers the primary expected operations (e.g., search, details, reviews, metrics, user info). There are no obvious gaps for read-only analytical use; features like posting are likely out of scope.

Resources