Skip to main content
Glama
Sign In
google-maps-mcp

google-maps-mcp

by benjamin-di
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Maps Static Map

maps_static_map
Read-onlyIdempotent

Generate a static Google Maps image with pins and/or a route line, using center and zoom or auto-fit to markers; returns JPEG plus a JSON legend.

Instructions

A map image like the Static Maps API: an area (center + zoom), pins and/or a route line, drawn on Google Maps tiles. Without center or zoom the view fits the pins and route. Returns a JSON legend {center, zoom, size, maptype, markers [{label, query, displayName, location, …}], route {travelMode, condition, description, distanceMeters, duration, googleMapsUri}, missingTiles, attribution} and the JPEG.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "maps_static_map"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNoWIDTHxHEIGHT, 128-1024 each640x480
zoomNo1 world … 10 city … 15 streets … 18 buildings
routeNoA route to draw, with its stops pinned A, B, …
centerNoCentre: a place or area name, a place id or 'lat,lng'
maptypeNoMap styleroadmap
markersNoPlaces to pin, lettered after the route's stops

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A3.7/5.0
Behavior4/5

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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's added value is the auto-fit fallback when center or zoom is missing: clear, non-obvious behavior. It also discloses the return shape (legend fields, missingTiles, attribution) even though no output schema exists, plus the JPEG payload. It does not mention rate limits, tile-availability caveats beyond missingTiles, or size/error behavior.

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?

Two sentences; the purpose and the fallback rule are front-loaded, followed by the return contract. The legend enumeration is dense but earns its place because there is no output schema. It is slightly heavy in the return-detail sentence but has no 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 correctly takes on the return contract (legend keys and the JPEG). It also covers the key behavioral edge case (auto-fit). It lacks guidance on choices among siblings or on limits (for example, markers max 10, route intermediates max 8), though the schema covers those. It is adequate but not exhaustive for a tool with six optional parameters.

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 already documents each parameter, including formats like 'lat,lng' and zoom levels. The description adds only the relational semantics (center + zoom define an area; markers and route are optional overlays; markers are lettered after route stops), which is real but limited added meaning. This sits at the baseline of 3.

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 states a concrete verb and resource: it renders a map image (an area, pins, and/or a route line) on Google Maps tiles, and it names the returned artifacts (legend JSON plus JPEG). It is clearly a rendering tool rather than a query tool. It does not explicitly differentiate itself from siblings such as maps_show_places or maps_show_route, so the agent must infer that those are interactive displays while this tool returns a static image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one useful behavioral rule — omitting center and zoom makes the view fit the pins and route — which tells the agent how to call the tool with minimal input. It never states when to prefer this tool over maps_show_places, maps_show_route, or maps_compute_route. As a result, the usage is implied rather than prescribed.

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

Deploy Server

Other Tools