Skip to main content
Glama

mapdata

CLOSED — do NOT call. /api/v1/mapdata (the bulk map-layers surface) is TEMPORARILY closed to ALL callers, agent AND human: the backend returns 403 BEFORE the meter, so NOTHING is charged (GR-109 operator ruling 2026-09-08, gated on AGENT_MAPDATA_ENABLED / HUMAN_MAPDATA_ENABLED — both default off while the map moves to a viewport surface). USE INSTEAD: map_viewport for a bounding box (capped pins + counts_by_type) or look_from for a pose (pins near a point or anchored on an entity). Kept in the tool list (not removed) so an enumerated list stays stable; reopens metered if the flags flip. (When open it was: metered map dataset, layers + include_country_centroids.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
layersNocompanies
include_country_centroidsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "mapdataDictOutput",
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it handles it exceptionally well. It discloses the 403-before-meter billing behavior, the gating flags, the fact that nothing is charged, the temporary closure rationale, and the condition under which it reopens as metered. This is far beyond typical behavioral disclosure.

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 front-loaded with the critical status ('CLOSED — do NOT call') and every subsequent sentence earns its place: rationale, billing impact, alternatives, enumeration-stability reason, and reopen condition. Despite carrying many details, it remains tightly organized and scannable.

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?

Given the tool's current disabled state, two parameters, and existing output schema, the description covers everything an agent needs: it must not call this tool, it will not be charged, and it has concrete replacements. The conditions for future reopening are also specified, making the context complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description needed to compensate for the two parameters. It only names 'layers + include_country_centroids' without explaining valid values for layers, what include_country_centroids affects, or how the parameters interact. The parameter titles in the schema already provide roughly the same shallow meaning.

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 explicitly identifies the tool as 'the bulk map-layers surface' and immediately states its current status: 'CLOSED — do NOT call.' It also distinguishes itself from siblings by naming map_viewport and look_from as the alternatives for bounding-box and pose queries, so an agent can tell exactly what this tool is and is not for.

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

Usage Guidelines5/5

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

The description gives explicit when-not-to-use guidance ('do NOT call') and concrete when-to-use-alternative guidance: use map_viewport for a bounding box and look_from for a pose. It even explains that the tool is kept only for enumeration stability, leaving no ambiguity about the correct action.

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.

Resources