Skip to main content
Glama

Aeralas Maps

Buy a print-ready map

make_map

Render the print-resolution map and return a download link. Costs $1 USDC, paid over x402: the first call returns the payment requirements; sign and call again with the payment. Charged only if the render succeeds. Includes 7 days of free revisions via revise_map.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dpiNo
mapIdNoRevise a map you already bought. Returned as X-Map-Id on your paid export. Re-exports are free for 7 days as long as the FRAME is unchanged — change labels, styling, overlays and page elements freely; changing address, center, groundWidthM, pageSize, orientation or dpi makes it a different map.
titleNoTitle block heading. Defaults to the address.
centerNo[longitude, latitude] in WGS84. Alternative to address.
formatNopdf
addressNoUS street address, city and state. Geocoded via the US Census.
overlaysNoThematic layers drawn under the annotations. A legend is added automatically. fema-flood: regulated floodplain (blank means no mapped hazard — FEMA draws Zone X with no symbol). nwi-wetlands: USFWS National Wetlands Inventory.
pageSizeNotabloid
autoLabelNoDraft tenant callouts from OpenStreetMap and road names from Census TIGER before drawing your own. Use this when you do not know what is at the location. Pass an object to control how many: fewer labels is the simplest cure for a crowded page.
labelScaleNoText size multiplier applied to every annotation that does not set its own textScale. Drop to ~0.8 to fit more labels; raise for a map read at arm’s length.
annotationsNoCallouts to draw. Placement, collision avoidance and leader lines are automatic.
orientationNoportrait
groundWidthMNoTrue ground width of the frame in meters. 500 fits a typical retail plaza; 20000-40000 makes a regional map, where autoLabel drafts cities, highway shields and water instead of tenants.
pageElementsNoPage furniture. Turn elements off to free up room for labels.
imagerySourceIdNoImagery source id. Defaults to the sharpest source covering the frame.
titleBlockScaleNoSize multiplier for the title block.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) establishing this as a non-idempotent write, the description adds material context they cannot: the $1 USDC cost, the two-step x402 payment handshake, the fact that it is charged only if the render succeeds, and the 7-day free revision window. It does not contradict the annotations.

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?

Three sentences, zero filler, and front-loaded with the outcome (render + download link) before cost and revision policy. Every sentence carries distinct, actionable information.

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?

For a 16-parameter tool with nested objects and no output schema, the description covers the two things the schema cannot: the payment protocol and what is returned (a download link). It stops short of noting that no spatial parameter (address or center) is technically required but practically necessary to define a frame.

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 75%, so the schema already documents most parameters (mapId, address, center, overlays, autoLabel, etc.) in detail. The description adds no parameter-level meaning of its own — no mention of dpi, format, address-vs-center, or frame constraints — so it neither compensates for the gap nor regresses below the baseline.

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?

States a specific verb and resource: 'Render the print-resolution map and return a download link.' The 'print-resolution' qualifier implicitly separates it from preview_map, and it names revise_map as the follow-up path. It never explicitly contrasts itself with preview_map or check_map, so an agent must infer the distinction.

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?

Strong procedural guidance: the first call returns x402 payment requirements, the caller signs and re-calls, and revisions are free for 7 days via revise_map. It does not, however, advise previewing first or explain when to pick this over preview_map, which is the obvious alternative for checking layout before paying.

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