MapMap

get_usage

Check what your own API key has spent, so you can decide mid-task whether to keep going. Reading it is free: it costs no quota. Optional from and to (YYYY-MM-DD UTC, inclusive, at most 92 days apart) bound the report; omitted, it covers the current month to date. Returns days (per-day, per-endpoint), totals per endpoint over the range, total_units, plus month_used_units against monthly_quota_units and the prepaid balance_millipence (thousandths of a penny). Everything is counted in UNITS — weighted quota units, where a heavier endpoint costs more than one unit per request — so never report these figures as a number of calls. When identity_pooled is true the quota is shared with the other keys belonging to the same owner, so these figures are not yours alone. The key that authenticates the call is the key reported on: there is no way to read another caller's usage. Needs the MapMap gateway (GATEWAY_URL + GATEWAY_API_KEY).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No	Last day to report, `YYYY-MM-DD` (UTC) inclusive. Defaults to today.
`from`	No	First day to report, `YYYY-MM-DD` (UTC) inclusive. Defaults to the first day of the current month. At most 92 days may separate `from` and `to`.

Output Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Last day covered, `YYYY-MM-DD` inclusive.
`days`	Yes	Per-day breakdown over the range, oldest first. A day with no usage is absent rather than reported as zero.
`from`	Yes	First day covered, `YYYY-MM-DD` inclusive.
`key_id`	Yes	Identifier of the key this usage belongs to.
`totals`	Yes	Units per endpoint over the whole range.
`total_units`	Yes	Total units over the whole range.
`identity_pooled`	Yes	Whether quota is pooled across every key belonging to the same identity. When true, these figures are the identity's shared consumption, so another key of the same owner also spends them.
`month_used_units`	Yes	Units counted against the monthly quota right now: the very number the quota check enforces on, independent of `from`/`to`. Quota is monthly, so this — not `total_units` — is what to compare with `monthly_quota_units`. It includes units recorded but not yet written to the daily counters, so over a whole-month range it can exceed `total_units`; that is not a discrepancy.
`balance_millipence`	Yes	Prepaid balance in millipence (thousandths of a penny), for usage beyond the monthly allowance.
`monthly_quota_units`	Yes	The key's monthly allowance in units.

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 does so thoroughly. It discloses that the call costs no quota, that figures are weighted units rather than raw request counts, that identity_pooled may make the numbers shared across keys, and that only the authenticating key's usage can be read. It also warns against misreporting units as calls.

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?

The description is longer than a minimal one, but every extra sentence addresses a real interpretation risk: units vs. calls, pooled quota, and inability to query other keys. It is front-loaded with purpose and cost, then moves through parameters, return semantics, and caveats in a logical order.

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 simple two-optional-parameter read tool with an output schema, the description is exceptionally complete. It covers purpose, cost, default ranges, date-bound behavior, output semantics, unit weighting, pooled identity, authentication key ownership, and the required gateway setup. An agent has everything needed to call and interpret this tool correctly.

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 coverage is 100%, so the schema already documents both optional parameters including defaults, format, inclusiveness, and the 92-day cap. The description repeats and lightly contextualizes this ('bound the report; omitted, it covers the current month to date') but does not add substantial new parameter-level meaning 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 a specific verb and resource: 'Check what your own API key has spent.' It also adds a clear use case ('decide mid-task whether to keep going') and is plainly distinct from all sibling tools, which concern routing, geocoding, style, or planning rather than quota usage.

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?

It states exactly when to use the tool: mid-task to decide whether to continue. It also gives an explicit when-not: 'there is no way to read another caller's usage,' and clarifies that reading is free, so there is no quota cost concern. No alternative tool is relevant among siblings, so no alternative routing is needed.

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

All MapMap tools Inspect

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/5.0

Disambiguation4/5

Most tools target a distinct action and resource pair, and descriptions are explicit about which tool fits which scenario. The closest overlaps—plan_ev_route vs cheapest_charging_along_route, and route vs plan_day vs order_stops vs optimise_routes—are mitigated by clear guidance, so an agent can usually pick correctly.

Naming Consistency4/5

Tool names overwhelmingly follow a verb_noun snake_case pattern (plan_ev_route, set_palette, list_style_layers) with a consistent geo_ prefix for geometry helpers. Minor deviations like elevation, route, and matrix are short and readable but break the strict verb_noun convention.

Tool Count2/5

At 39 tools, this surface is well past the 25+ threshold and feels heavy even for a broad mapping platform. The set spans routing, geocoding, places, styles, EV/fuel, telematics, usage, and feedback, which would be easier for an agent to navigate if split into smaller domain-focused servers.

Completeness4/5

For the stated breadth, coverage is strong: routing, multi-stop planning, VRP, EV/fuel detours, geocoding, places, geometry, style lifecycle, and telematics all have workable primary paths. Minor gaps like no style deletion, no route alternatives, and no batch geocoding are present but do not create dead ends for core workflows.

Resources

Need Help?