Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Overture Maps MCP server Find Italian restaurants in Rome"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Query Overture Maps data — places (POIs), buildings and administrative divisions — directly from Claude and other MCP-compatible LLM tools.
This is a local (stdio) MCP server that wraps the Overture Maps API. Responses are compact summaries rather than full GeoJSON, so they stay token-efficient, and the tools steer toward cheap, well-scoped queries.
Tool | What it does |
| Search POIs/businesses by country or lat/lng+radius, filtered by category, taxonomy, brand or contact details. |
| List available place categories (with counts) for a country or area — use to find valid |
| List every country in the dataset with place/brand counts. |
| Look up administrative divisions (countries, regions, counties, localities) by name or location. |
| Find building footprints near a point (id, distance, height/levels). |
Related MCP server: Overture Maps MCP Server
Sign up at overturemapsapi.com for a free API key. The public DEMO-API-KEY also works for light testing. Set it as OVERTURE_API_KEY.
Note: the Free tier is for non-commercial use. Commercial use needs a paid plan.
Add this to your claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"overture-maps": {
"command": "npx",
"args": ["-y", "@thatapicompany/overture-maps-mcp"],
"env": {
"OVERTURE_API_KEY": "your-api-key-here"
}
}
}
}Restart Claude Desktop. You can then ask things like:
"Find cafes within 500m of the Eiffel Tower."
"List every used car dealer in the UK that has a website."
"What administrative region is Springfield in?"
"How many places does Overture have for Bermuda?"
Any client that supports local stdio MCP servers works the same way — run npx -y @thatapicompany/overture-maps-mcp with OVERTURE_API_KEY in the environment.
npm install
npm run build
OVERTURE_API_KEY=your-key node dist/index.jsVariable | Default | Purpose |
|
| Your Overture Maps API key. |
|
| Override for staging/self-hosted deployments. |
MIT
Find building footprints near a location from Overture Maps. Requires lat+lng; returns compact building summaries (id, distance, height/levels where known) without full geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude (required). | |
| lng | Yes | Longitude (required). | |
| limit | No | Number of results (default 10, max 50). | |
| radius | No | Radius in metres (default 250, max 25000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return structure (id, distance, height/levels) and omission (no full geometry). With no annotations, this adequately informs about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences; first states purpose, second adds constraints and output details. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description adequately describes output format and limitations. Could mention data source behavior but sufficient given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds minimal value beyond restating requirements. Lacks explanation of defaults/max for limit and radius, which are in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (find), resource (building footprints), and source (Overture Maps). Differentiates from sibling tools like search_places by focusing on building footprints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states required parameters (lat, lng) implying geometric queries. Does not list alternative tools, but context of siblings makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the place categories available in Overture Maps data for a country (or a lat/lng/radius area), with how many places each has. Use this to find valid categories values before calling search_places.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| radius | No | Radius in metres for a lat/lng area (max 25000). | |
| country | No | ISO country code, e.g. GB. Use this OR lat+lng. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-like operation (listing with counts) and mentions the OR condition for inputs, but does not detail side effects, auth needs, or return format. The behavior is generally clear but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one stating the core function and one providing actionable usage guidance. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with optional params and no output schema, the description covers the purpose, usage modes, and relation to search_places. It could be slightly more explicit about requiring lat and lng together, but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (radius and country have descriptions; lat and lng do not). The description adds value by grouping lat+lng+radius as an alternative to country, but does not provide additional meaning beyond that grouping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists place categories for a country or lat/lng/radius area with counts, and explicitly distinguishes it from sibling tools like search_places by positioning it as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool before calling search_places to find valid categories, and notes the alternative input modes (country vs. lat/lng/radius). However, it does not explicitly exclude alternative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every country present in Overture Maps places data, with the number of places (and brands) in each. Useful to check coverage before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Accurately describes what the tool does and returns. No annotations, but the description is transparent about the operation. Could mention data freshness or performance, but overall clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded purpose, no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and simple operation, the description is complete for the agent to understand what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 per instructions. The description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists every country with counts of places and brands, and distinguishes itself from siblings by noting its use for checking coverage before searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Useful to check coverage before searching,' guiding when to use it. No explicit when-not, but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up administrative divisions (countries, regions, counties, localities) in Overture Maps. Search by name (e.g. 'Springfield'), optionally narrowed by country, subtype (country, region, county, locality, ...) or admin_level. Geometry is omitted by default to save space; set include_geometry=true only if you specifically need the boundary polygon.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| name | No | Division name to search for, e.g. 'Paris', 'Bavaria'. | |
| limit | No | Number of results (default 10, max 50). | |
| radius | No | ||
| country | No | ISO country code to narrow the search, e.g. FR. | |
| subtype | No | Division subtype: country, region, county, locality, etc. | |
| admin_level | No | Administrative level (0 = country, higher = more local). | |
| include_geometry | No | Include the boundary polygon (large). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that geometry is omitted by default to save space, implying a performance consideration. But does not mention what happens with lat/lng/radius parameters, or if name is required. No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by a key usage tip. Every word earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no output schema), description covers the main search workflow but omits explanation of lat/lng/radius, pagination, and error scenarios. Lacks enough detail for an agent to use all parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema coverage, description adds value for include_geometry (explains default behavior) and highlights name as primary search key. However, lat, lng, and radius remain undocumented, and description does not clarify their role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Look up administrative divisions' in Overture Maps, listing subtypes and search attributes, distinguishing it from sibling tools like search_places or find_buildings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: search by name, optionally narrow by country/subtype/admin_level, and set include_geometry only if needed. However, no explicit comparison with sibling tools (e.g., when to use search_places instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for places (points of interest / businesses) in Overture Maps data. You must scope the search to keep it fast and cheap: provide either a country (ISO 3166-1 alpha-2, e.g. GB, US, FR) OR a lat+lng with a radius. Filter by categories (e.g. restaurant, cafe, used_car_dealer — use list_place_categories to discover valid values), brand_name (e.g. Starbucks), or has_contact to only return places with a website/phone. Returns compact summaries (name, category, location, website, phone), not full geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for a radius search. Requires lng. | |
| lng | No | Longitude for a radius search. Requires lat. | |
| page | No | 0-indexed page number for paging through results. | |
| limit | No | Number of results (default 10, max 50). | |
| radius | No | Search radius in metres for a lat/lng search (default 1000, max 25000). | |
| country | No | ISO 3166-1 alpha-2 country code, e.g. GB, US, FR. Use this OR lat+lng. | |
| taxonomy | No | Hierarchy-aware category, e.g. 'food_and_drink' matches every restaurant/cafe/bar/bakery. | |
| brand_name | No | Retail chain / brand name, e.g. 'Starbucks', 'Tesco'. | |
| categories | No | Comma-separated category names, e.g. 'restaurant' or 'cafe,bakery'. | |
| has_contact | No | Only return places that have at least one of these contact fields (OR): website, phone, email, social. e.g. 'website,social'. | |
| min_confidence | No | Minimum confidence 0-1 (default 0.5). Higher = more precise, fewer results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that searches must be scoped for performance and returns compact summaries, not full geometry. For a read-only search, this is sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads purpose and constraints. It is relatively concise, with every sentence contributing value, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description adequately covers the main use case, scoping requirements, filtering, and return format. It does not need to repeat parameter details already in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters (country OR lat+lng+radius) and explaining the rationale for scoping, as well as referencing list_place_categories for category values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for places (points of interest/businesses) in Overture Maps data. It distinguishes from siblings like find_buildings and list_place_categories by focusing on POI search and referencing sibling tools for category discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the search must be scoped with either a country or lat+lng+radius to keep it fast and cheap. Mentions using list_place_categories for valid categories, but does not explicitly contrast with other sibling tools like search_divisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_buildingslist_place_categorieslist_place_countriessearch_divisionssearch_placesScored across 5 tools
Each tool targets a distinct data type: buildings, place categories, place countries, administrative divisions, and places (POIs). There is no overlap in purpose, and descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern using lowercase and underscores: 'find_buildings', 'list_place_categories', 'list_place_countries', 'search_divisions', 'search_places'. The verbs ('find', 'list', 'search') are appropriate for query operations.
With 5 tools covering building footprints, places, administrative divisions, and metadata lookups, the count is well-scoped for a geographic data query server. It provides essential functionality without being excessive or too sparse.
The tool surface covers key query operations for Overture Maps data, including listing metadata and searching for buildings, places, and divisions. However, there is no tool to retrieve full geometry for buildings or places, which may be a gap for some use cases.
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
Live Google Maps business search, review, and photo data for AI agents over MCP.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
