ShowMeOnMap

Analyze several datasets together

analyze

One call for a question that combines datasets: "which Asian capitals had the most earthquakes within 300 km this month", "people within 30 km of each volcano in Indonesia", "how much of each African country is desert". Give a plan: acquire steps (ask = a dataset in plain words answered without a model; hazard = USGS / GVP / FIRMS / GDACS; osm = exact OSM tags in an area), then op steps (within, overlap, zonal, join, population, near, rank, filter) that name their inputs by step id. The code computes, no model: returns a shareable map, a table of the answer step (top rows), a ledger naming each number's source and op, and a grounded summary. A step that cannot run fails the whole plan with that step named and why (a source that did not answer is never reported as "none"). Costs 1 credit; refunded when it fails or the answer is empty. Use build_map for a single dataset.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plan": "<plan>"
    },
    "name": "analyze"
  }
}

Input Schema

Name	Required	Description
`plan`	Yes	Acquire datasets, then compute over them. Example: [{id:"capitals",acquire:{ask:"capitals of Asia"}},{id:"quakes",acquire:{hazard:"earthquakes",place:"Asia",days:30}},{id:"x",op:"within",target:"capitals",source:"quakes",radius_km:300},{id:"top",op:"rank",input:"x",by:"within_count",n:10}], answer:"top"
`map_id`	No	Optional: run on this map — acquire {layer} reads its layers, and the result is added to it instead of a new map
`rationale`	No	Optional short label (≤300 chars) for the map edit history, e.g. "add wildfire layer". Omit it to send nothing beyond the tool arguments.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses cost (1 credit) and the refund condition, failure atomicity (one unrunnable step fails the whole plan, named, with reason), a correctness guarantee (an unanswered source is never reported as "none"), and the exact return artifacts (shareable map, answer-step table, source ledger, grounded summary). The 'computes, no model' note plus non-idempotent map creation is consistent with readOnlyHint=false.

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?

Front-loads the use case with concrete examples, then adds only load-bearing clauses (plan grammar, outputs, cost, failure behavior, sibling pointer). It is dense and somewhat run-on with heavy parenthetical nesting, but nearly every sentence carries distinct 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?

For a complex nested-plan tool with no output schema, the description supplies everything an agent needs: plan composition, step ordering, credit cost, failure semantics, and the four return artifacts. Nothing material is left to inference beyond the per-field details already in the schema.

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 every field including the op enum, acquire variants, and step-id referencing is already documented structurally. The description restates the acquire categories and op list with light added framing (steps named by id, answer = the table step), which is helpful orientation but largely duplicative of the schema, so the baseline 3 applies.

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?

States a specific verb+resource+scope: one call that answers a question combining multiple datasets, illustrated with three concrete worked questions (Asian capitals within 300 km of earthquakes, etc.). It also explicitly distinguishes itself from build_map for single-dataset cases, so an agent can route without opening either schema.

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?

Gives clear selection criteria (multi-dataset question → analyze; single dataset → build_map) and the shape of a valid plan. It does not mention other plausibly competing siblings such as run_analysis or correlate_layers, so the exclusion set is incomplete, but the primary routing decision is explicit.

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

All ShowMeOnMap tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?