Skip to main content
Glama
Sign In

InstaMaps

by com.get-instamaps
OverviewDiscussionsAdmin

Crime, flood or natural-hazard risk for each place

get_area_risk
Read-onlyIdempotent

One risk fact for each of up to 250 addresses or points. crime: recorded crimes within about 250 m in the latest month (police.uk; England and Wales; kind narrows it: vehicle, burglary, violent, theft, shoplifting, robbery, anti-social, drugs, criminal damage, bike). flood: the flood zone with high/medium/low (Environment Agency for England, FEMA for the US) and how each compares: FEMA's base flood elevation, the neighbourhood's river and coastal flooding on FEMA's National Risk Index with its national percentile (US), the place's rank on the list (1 = most at risk) and a sentence in words (says) to use on a call or in a note; the map beside the answer draws the places coloured by risk over the official flood zones (for flood prospecting, renewals or a book of business). hazard: FEMA National Risk Index rating for the census tract (US; kind: overall, flood, hurricane, wildfire, tornado, earthquake, heat…). Rows outside a source's coverage say so rather than guess. Set render to true only when the user wants to keep or share the map: it returns a link, GeoJSON and KML, and update_map can change it later.

Input Schema

NameRequiredDescriptionDefault
kindNo
titleNoThe kept map's title when render is on.
metricYes
renderNoflood: also keep the map (the places by risk over the flood zones): a link to share, GeoJSON and KML.
sourceNoInstead of typing rows: { sheet: "<Google Sheets link>", tab?: "Sites" } (shared with the InstaMaps service account, or viewable by anyone with the link), { file: "<Drive link to a CSV or Excel file>" }, or { run: "<run_id from an earlier answer>" }. Columns are found by their headers (id, name, address or its parts, lat/lng); name them if they aren't obvious (id_column, address_column, lat_column, lng_column; from_column and to_column for road distances). Rows with coordinates are used as they are.
recordsNo{id, address} or {id, lat, lng}. Send your own ids to merge results back.
addressesNoOr plain addresses/postcodes, numbered from 1.
backgroundNoWith source: run as a background job and answer at once with job_id (automatic past 200 rows). Check with get_job; write_to_sheet with the job_id puts the results in the sheet as they finish.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / render
      Added value: +{
+  "default": false,
+  "description": "flood: also keep the map (the places by risk over the flood zones): a link to share, GeoJSON and KML.",
+  "type": "boolean"
+}
    • addedInput schema / properties / title
      Added value: +{
+  "description": "The kept map's title when render is on.",
+  "type": "string"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantial context on top: source coverage boundaries (police.uk is England and Wales only; Environment Agency vs FEMA), the 'rows outside a source's coverage say so rather than guess' fallback, the 250-row cap, and the automatic background switch past 200 rows. It does not cover error behavior or rate limits, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading is good (scope first, then per-metric detail), but the flood clause is a single sprawling run-on with nested parentheticals, and the render/background guidance is buried at the very end. Information density is high, yet the structure makes it hard to scan.

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?

With no output schema, 8 parameters and nested source/records objects, the description carries a lot and mostly delivers: it describes what comes back per metric (counts, zone, rank, 'says' sentence), what render returns, and how background jobs are retrieved via get_job/write_to_sheet. Only the exact result shape per metric remains underspecified.

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

Parameters4/5

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

With 75% schema coverage the baseline is 3, but the description materially enriches the undocumented parameters: it enumerates the crime kinds, defines each flood comparison, lists the hazard kinds, and explains render's link/GeoJSON/KML return and background's job_id flow. It adds meaning well beyond the schema text.

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 concrete verb and resource ('One risk fact for each of up to 250 addresses or points') and then spells out the three metrics (crime, flood, hazard) with their underlying sources. An agent can tell exactly what comes back, but the description never differentiates this static-risk tool from the near-named siblings get_live_hazards and check_live_hazards.

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 real conditional guidance: 'Set render to true only when the user wants to keep or share the map', the flood prospecting/renewals/book-of-business use case, and the background-job rule. It stops short of naming alternatives, so it never says when NOT to use this versus the live-hazard tools.

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

All InstaMaps toolsInspect
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