webdatatools-leads-mcp

overpass_poi_extractor

Extract OpenStreetMap POIs such as shops, cafes, and restaurants by category within a radius, bbox, or named area via Overpass API. Returns one row per place.

Instructions

OpenStreetMap POI Extractor returns shops, cafes, restaurants and any tagged place within a radius, a bounding box, or a named area — one row per point of interest, powered by the free Overpass API. Billed to your own Apify account: ~$0.0005 per place (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema

Name	Required	Description
`bbox`	No	Bounding box (bbox mode) — Bounding box as "south,west,north,east" decimal degrees, e.g. "50.05,14.35,50.13,14.55" for central Prague. Required when Search mode is "bbox". Example: "50.05,14.35,50.13,14.55".
`mode`	Yes	Search mode — How to define the search area: "radius" around a point, "bbox" (a bounding box), or "area" (a place name resolved via Nominatim, e.g. a city or district). Options: radius = Radius around a point; bbox = Bounding box; area = Named area (city/district). Example: "radius".
`areaName`	No	Area name (area mode) — A place name to search inside, e.g. "Prague, Czechia" or "Brooklyn, New York". Resolved to an OpenStreetMap area via Nominatim. Required when Search mode is "area". Example: "Prague, Czechia".
`latitude`	No	Latitude (radius mode) — Center point latitude for radius mode, e.g. 50.0755 for Prague's city centre. Ignored in bbox and area mode. Example: 50.0755.
`longitude`	No	Longitude (radius mode) — Center point longitude for radius mode, e.g. 14.4378 for Prague's city centre. Ignored in bbox and area mode. Example: 14.4378.
`categories`	Yes	OSM categories (key=value tags) — OpenStreetMap tags to search for, each as "key=value", e.g. "amenity=cafe" or "shop=supermarket". Every category is searched and merged into one result list. Example: ["amenity=cafe","amenity=restaurant"].
`maxResults`	No	Max results — Maximum number of POIs to return, e.g. 500. Overpass results beyond this count are dropped before they are pushed to the dataset.
`radiusMeters`	No	Radius in meters (radius mode) — How far from the center point to search, in meters, e.g. 1000 for a 1 km radius. Larger radii return more results and take longer to query.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does a good job: it discloses the data source (free Overpass API), the cost model (~$0.0005 per place, billed to the caller's Apify account), and the result cardinality (one row per POI). It omits auth prerequisites and rate/quota limits, which is the remaining gap.

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?

Two sentences, front-loaded with what the tool returns and how the search area is defined, followed by the billing caveat. No filler or redundancy.

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?

No output schema exists, but the description states the return shape ('one row per point of interest') and the cost implication, covering what an agent needs to decide and call. Missing only ancillary details such as how categories combine with modes and any hard caps beyond maxResults.

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 parameter (mode, bbox, areaName, latitude/longitude, categories, maxResults, radiusMeters) is already fully documented with examples. The description only restates the three area modes and the merge behavior for categories, adding little beyond the schema — 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 concrete verb+resource ('returns shops, cafes, restaurants and any tagged place') with explicit scope (radius, bbox, named area) and output granularity (one row per POI). No sibling tool (hiring_signals, market_quotes, etc.) overlaps with POI extraction, so differentiation is implicit and unambiguous.

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?

Names the three search-area modes and the backing service, which tells the agent how to frame a request, but offers no explicit when-to-use/when-not or alternative tools to prefer for other geodata needs. Context is clear; exclusions are absent.

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

Deploy Server

overpass_poi_extractor

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools