Skip to main content
Glama

Google Maps

maps
Read-onlyIdempotent

Find places (name, rating, category, address, phone, website, place_id and cid, or oid with engine=yandex, and coordinates); the place tool returns one place's hours and full listing. Put the area in location (e.g. "Berlin, Germany" or "Kreuzberg, Berlin") or in q; ll searches around an exact point. 1 credit.

Input Schema

NameRequiredDescriptionDefault
qYesSearch query
llNoMap viewport "@lat,lng,14z": search around that point
pageNo
engineNogoogle (default) or yandex (Yandex Maps, for Russia and the CIS where enabled; its places carry an oid for the place tool)
countryNoCountry code, e.g. us, de, ru. Uses shared proxy routes
languageNoLanguage code, e.g. en, ru (Russian). Does not change country
locationNoCity-level location, e.g. "Austin, Texas, United States"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / engine
      Added value: +{
      +  "description": "google (default) or yandex (Yandex Maps, for Russia and the CIS where enabled; its places carry an oid for the place tool)",
      +  "enum": [
      +    "google",
      +    "yandex"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower; the description still adds real context by disclosing the cost ('1 credit') and the engine-specific caveat that Yandex results carry an oid usable by the place tool. It does not discuss result caps or the page limit, which the schema only implies.

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 the place-tool boundary are front-loaded in the first clause, with operational hints following. The parenthetical field list is dense but each item carries information; nothing is redundant filler.

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?

With no output schema, the description compensates by naming the fields returned (name, rating, category, address, phone, website, place_id/cid/oid, coordinates) and the cost. Remaining gap is pagination/result-count behavior for a 7-parameter, page-bounded search.

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 86% so the 3 baseline is already met; the description goes further by explaining the q vs location vs ll split (area text vs exact-point viewport) and the engine=yandex/oid relationship, which the schema does not fully spell out. It adds no detail on page or country/language interaction.

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?

Opens with a specific verb+resource ('Find places') and enumerates the returned fields, then explicitly contrasts itself with the sibling 'place' tool that returns one place's hours and full listing. An agent can distinguish maps from place and search without opening a schema.

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?

Gives concrete routing rules: put the area in location (with example values) or in q, and use ll when searching around an exact point; also points to the 'place' tool for single-place detail and names engine=yandex for Russia/CIS. No explicit when-not-to-use exclusions beyond the place-tool redirect, which keeps it short of a 5.

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.