Skip to main content
Glama

Map apps

list_map_apps
Read-onlyIdempotent

Mappit's Map Apps (its Layer Apps): statistics painted on the map — world and US economy, people, the environment and energy (temperature, the electricity mix, grid carbon), health, conflict and crisis, US elections and Mappit's own news atlas. Lists each app's views with the indicator code, levels, time grain, source, licence and a link that opens it. A view that draws places (nuclear reactors, data centers, AI campuses) or dated events names that dataset in events; one with no indicator (grain "site" or "event") has no statistic to fetch, so give its link. Use it to learn the indicator codes get_statistic and rank_regions take; a news-topic view's code carries its topic ("news_topic_share:world-conflict").

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": "list_map_apps"
  }
}

Input Schema

NameRequiredDescriptionDefault
appNoOptional app key, to list just that app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world, and non-destructive behavior, so the safety profile is covered. The description adds valuable behavioral context: what each view contains (indicator code, levels, time grain, source, licence, link), how events and site/event grains behave, and how news-topic codes are constructed. It does not mention pagination or output ordering, but the return shape is otherwise well disclosed.

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 front-loaded with the purpose, then the return contents, then edge cases and usage. It is somewhat dense and includes a long illustrative list of domains that could be trimmed, but every sentence carries substantive information.

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?

There is no output schema, so the description must explain the return values, and it does: each app's views with indicator code, levels, time grain, source, licence, and link. It also covers the no-indicator case and the news-topic code convention, leaving no significant gap for an agent to call the 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?

The single optional 'app' parameter is fully documented in the schema at 100% coverage. The description does not elaborate on the parameter or explain filtering behavior beyond the general 'lists each app's views', so it does not add meaning over the schema. Baseline 3 is appropriate.

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 gives a specific verb and resource ('Lists each app's views') and defines what Map Apps are ('statistics painted on the map'). It distinguishes the tool from siblings by naming get_statistic and rank_regions as consumers of the indicator codes it exposes.

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 explicitly says when to use it: 'Use it to learn the indicator codes get_statistic and rank_regions take.' It also covers the edge case where a view has no indicator and instructs the agent to give its link instead, which is clear routing guidance.

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