Skip to main content
Glama

Vee3

by io.github.Vee3io

google-maps.place_details

Get detailed information for a Google Maps place.

Provide place_id from search results. The identifier also accepts the business identifier form (0x...:0x...). Optional region and language are supported.

Returns a flat place object with fields such as name, full_address, location, hours, status, rating, review_count, website, phone_number, and types when available. Additional upstream fields may appear.

Cost = 4 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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).
place_idYesGoogle Maps place identifier (for example ChIJk_grnPDq9EcRE7gOH9gAPZA). Also accepts the business identifier form (for example 0x47f4eb87e91f866d:0x9629fabb993eb66).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoPlace display name.
hoursNoOpening hours when available.
typesNoPlace type labels when available.
ratingNoAverage user rating when available.
statusNoHuman-readable open/closed status when available.
websiteNoPlace website when available.
locationNoPlace coordinates when available.
full_addressNoFull formatted address when available.
phone_numberNoPlace phone number when available.
review_countNoTotal number of reviews 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 / GoogleMapsPlaceDetailsResponseLocation / properties / latitude / anyOf
      Previous value: -[
-  {},
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / $defs / GoogleMapsPlaceDetailsResponseLocation / properties / longitude / anyOf
      Previous value: -[
-  {},
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / rating / anyOf
      Previous value: -[
-  {},
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed2 schema fields changed
    • removedOutput schema / $defs / GoogleMapsPlaceDetailsResponseTypesItem
      Removed value: -{
-  "additionalProperties": true,
-  "properties": {
-    "type": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Place type label.",
-      "title": "Type"
-    }
-  },
-  "title": "GoogleMapsPlaceDetailsResponseTypesItem",
-  "type": "object"
-}
    • changedOutput schema / properties / types / anyOf
      Previous value: -[
-  {
-    "items": {
-      "$ref": "#/$defs/GoogleMapsPlaceDetailsResponseTypesItem"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  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 provided, the description carries the full burden. It discloses the return shape ('flat place object'), lists example fields ('name, full_address, location, hours...'), warns that 'Additional upstream fields may appear,' and states the cost ('Cost = 4 tokens'). This gives a good sense of what to expect, though it does not explicitly mention auth requirements or side effects.

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 concise and front-loaded: the first sentence states the purpose, the second gives usage instructions, the third describes the return value, and the fourth mentions cost. Every sentence adds value with no redundancy or padding.

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 relatively simple tool with one required and two optional parameters, the description covers the necessary context: how to obtain the ID, what the output looks like, and the cost. Since an output schema is present, the description does not need to fully detail every return field, but it still provides a helpful preview. This is complete for practical use.

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 baseline is 3. The description does add the useful hint that place_id comes from search results, but otherwise repeats what the schema already states about the business identifier form and optional region/language parameters. It does not significantly enhance the parameter understanding 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 'Get detailed information for a Google Maps place,' which clearly states the verb and resource. It distinguishes itself from sibling tools like google-maps.search or google-maps.place_photos by specifying that it returns detailed place information for a given place_id.

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 says 'Provide place_id from search results,' which clearly indicates the typical workflow: perform a search first, then use the returned place_id to fetch details. It also notes the optional region and language parameters, implying their use for localization. However, it doesn't explicitly mention when not to use this tool or mention sibling alternatives.

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