Provides geocoding, reverse geocoding, points of interest search, route directions, meeting point optimization, neighborhood analysis, EV charging station location, and parking search using OpenStreetMap data.
Click on "Install 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., "@osm-mcp-server What's the best meeting point for people in downtown Austin?"
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.
An OpenStreetMap MCP server implementation that enhances LLM capabilities with location-based services and geospatial data.
Related MCP server: OSM Edit MCP Server
osm-mcp-server: The main server, available for public use.
"mcpServers": {
"osm-mcp-server": {
"command": "uvx",
"args": [
"osm-mcp-server"
]
}
}This server provides LLMs with tools to interact with OpenStreetMap data, enabling location-based applications to:
Geocode addresses and place names to coordinates
Reverse geocode coordinates to addresses
Find nearby points of interest
Get route directions between locations
Search for places by category within a bounding box
Suggest optimal meeting points for multiple people
Explore areas and get comprehensive location information
Find schools and educational institutions near a location
Analyze commute options between home and work
Locate EV charging stations with connector and power filtering
Perform neighborhood livability analysis for real estate
Find parking facilities with availability and fee information
The server implements location-based resources:
location://place/{query}: Get information about places by name or address
location://map/{style}/{z}/{x}/{y}: Get styled map tiles at specified coordinates
The server implements several geospatial tools:
geocode_address: Convert text to geographic coordinates
reverse_geocode: Convert coordinates to human-readable addresses
find_nearby_places: Discover points of interest near a location
get_route_directions: Get turn-by-turn directions between locations
search_category: Find places of specific categories in an area
suggest_meeting_point: Find optimal meeting spots for multiple people
explore_area: Get comprehensive data about a neighborhood
find_schools_nearby: Locate educational institutions near a specific location
analyze_commute: Compare transportation options between home and work
find_ev_charging_stations: Locate EV charging infrastructure with filtering
analyze_neighborhood: Evaluate neighborhood livability for real estate
find_parking_facilities: Locate parking options near a destination
To run the server locally:
Install the package in development mode:
pip install -e .Start the server:
osm-mcp-serverThe server will start and listen for MCP requests on the standard input/output.
The repository includes two example clients in the examples/ directory:
client.py demonstrates basic usage of the OSM MCP server:
python examples/client.pyThis will:
Connect to the locally running server
Get information about San Francisco
Search for restaurants in the area
Retrieve comprehensive map data with progress tracking
llm_client.py provides a helper class designed for LLM integration:
python examples/llm_client.pyThis example shows how an LLM can use the Location Assistant to:
Get location information from text queries
Find nearby points of interest
Get directions between locations
Find optimal meeting points
Explore neighborhoods
To create your own client:
Import the MCP client:
from mcp.client import ClientInitialize the client with your server URL:
client = Client("http://localhost:8000")Invoke tools or access resources:
# Example: Geocode an address
results = await client.invoke_tool("geocode_address", {"address": "New York City"})On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
"mcpServers": {
"osm-mcp-server": {
"command": "uv",
"args": [
"--directory",
"/path/to/osm-mcp-server",
"run",
"osm-mcp-server"
]
}
}To prepare the package for distribution:
Sync dependencies and update lockfile:
uv syncBuild package distributions:
uv buildThis will create source and wheel distributions in the dist/ directory.
Publish to PyPI:
uv publishNote: You'll need to set PyPI credentials via environment variables or command flags.
Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector.
You can launch the MCP Inspector via npm with this command:
npx @modelcontextprotocol/inspector uv --directory /path/to/osm-mcp-server run osm-mcp-serverUpon launching, the Inspector will display a URL that you can access in your browser to begin debugging.
Perform a detailed commute analysis between home and work locations.
This advanced tool analyzes commute options between two locations (typically home and work), comparing multiple transportation modes and providing detailed metrics for each option. Includes estimated travel times, distances, turn-by-turn directions, and other commute-relevant data. Essential for real estate decisions, lifestyle planning, and workplace relocation analysis.
Args: home_latitude: Home location latitude (decimal degrees) home_longitude: Home location longitude (decimal degrees) work_latitude: Workplace location latitude (decimal degrees) work_longitude: Workplace location longitude (decimal degrees) modes: List of transportation modes to analyze (options: "car", "foot", "bike") depart_at: Optional departure time (format: "HH:MM") for time-sensitive routing
Returns: Comprehensive commute analysis with: - Summary comparing all transportation modes - Detailed route information for each mode - Total distance and duration for each option - Turn-by-turn directions
| Name | Required | Description | Default |
|---|---|---|---|
| modes | No | ||
| depart_at | No | ||
| home_latitude | Yes | ||
| work_latitude | Yes | ||
| home_longitude | Yes | ||
| work_longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output nature (metrics, directions) and the optional time-sensitive routing via depart_at, but it does not mention limitations, data sources, or error handling. It reads as a straightforward analysis tool, but lacks deep 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 well-structured with a lead sentence, a functional overview, and clear Args/Returns sections. It is front-loaded and every line adds value, avoiding redundancy or fluff.
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?
Despite having no output schema and no annotations, the description explains the return structure with bullet points and covers all 6 parameters. It omits edge cases or limitations, but for a tool of this complexity it provides adequate context for an agent to invoke it 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?
The schema has 0% description coverage, but the description's 'Args:' section fully compensates. It explains units (decimal degrees), the format for depart_at (HH:MM), and lists valid mode options (car, foot, bike). This adds significant meaning beyond the bare 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?
The description clearly states the tool's function: 'Perform a detailed commute analysis between home and work locations.' It specifies the outputs (travel times, distances, directions) and differentiates itself from sibling tools like get_route_directions by focusing on comparing multiple modes and supporting real estate decisions.
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 provides clear use cases ('Essential for real estate decisions, lifestyle planning, and workplace relocation analysis') and describes the home/work context. However, it does not explicitly mention when not to use this tool or contrast it with alternatives like get_route_directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive neighborhood analysis focused on livability factors.
This advanced analysis tool evaluates a neighborhood based on multiple livability factors, including amenities, transportation options, green spaces, and services. Results include counts and proximity scores for various categories, helping to assess the overall quality and convenience of a residential area. Invaluable for real estate decisions, relocation planning, and neighborhood comparisons.
Args: latitude: Center point latitude (decimal degrees) longitude: Center point longitude (decimal degrees) radius: Analysis radius in meters (defaults to 1000m/1km)
Returns: Comprehensive neighborhood profile including: - Overall neighborhood score - Walkability assessment - Public transportation access - Nearby amenities (shops, restaurants, services) - Green spaces and recreation - Education and healthcare facilities - Detailed counts and distance metrics for each category
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It explains what the tool computes (counts, proximity scores, walkability, transport access) and what it returns (a structured profile with scores and distance metrics), going beyond a simple action statement. It does not disclose data sources, error cases, or auth requirements, but for a benign read-only analysis tool the behavior is well characterized.
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 well-structured with a one-line summary, a supporting paragraph, an Args section, and a Returns section, keeping the most important information front-loaded. It is slightly redundant—categories like amenities and green spaces appear in both the prose and the Returns list—but every sentence adds some value and the overall length is appropriate.
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?
With no output schema and no annotations, the description must explain both parameters and return values, and it does so thoroughly: it lists seven output categories and documents all three parameters with units. For a tool of moderate complexity (3 simple params, no nested objects), this is nearly complete, though it omits edge-case behavior like invalid coordinates or radius limitations.
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?
Although the context signal reports 0% schema description coverage, the description compensates by adding meaning beyond the bare schema: latitude and longitude are labeled 'Center point latitude (decimal degrees)' and radius is clarified as 'Analysis radius in meters (defaults to 1000m/1km)'. This adds units, role, and default interpretation that the schema properties lack, though it does not explain radius limits or coordinate validity.
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 opens with a specific verb+resource: 'Generate a comprehensive neighborhood analysis focused on livability factors' and elaborates with concrete categories (amenities, transportation, green spaces, services). This clearly distinguishes it from sibling tools like find_nearby_places, find_schools_nearby, and analyze_commute, which focus on narrower, single-category lookups rather than a holistic livability score.
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 provides clear use cases: 'Invaluable for real estate decisions, relocation planning, and neighborhood comparisons,' which tells the agent when to select this tool. However, it does not explicitly name alternatives or mention when not to use it, such as when a single category like schools or commute alone is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive profile of an area including all amenities and features.
This powerful analysis tool creates a detailed overview of a neighborhood or area by identifying and categorizing all geographic features, amenities, and points of interest. Results are organized by category for easy analysis. Excellent for neighborhood research, area comparisons, and location-based decision making.
Args: latitude: Center point latitude (decimal degrees) longitude: Center point longitude (decimal degrees) radius: Search radius in meters (defaults to 500m)
Returns: In-depth area profile including: - Address and location context - Total feature count - Features organized by category and subcategory - Each feature includes name, coordinates, and detailed metadata
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It describes the tool as an 'analysis tool' and details the return structure, implying a read-only, non-destructive operation. However, it does not explicitly state that the operation is safe or disclose potential limitations such as result volume, rate limits, or error behavior. This is a moderate gap given the lack of annotations.
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 well-structured and front-loaded: a one-sentence summary immediately conveys purpose, followed by a brief elaboration, then clearly formatted Args and Returns sections. Every sentence contributes useful information without unnecessary fluff, making it appropriately sized for a tool of this complexity.
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?
The description is largely complete: it explains all three parameters, provides a detailed Returns section (compensating for the missing output schema), and gives usage context. It lacks only explicit limitations or exclusions, such as maximum radius or performance caveats, but overall it gives enough for an agent to understand what the tool does and what to expect.
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?
The description provides a dedicated Args section that adds meaning beyond the schema: latitude and longitude are specified as 'Center point latitude (decimal degrees)' and the radius is 'in meters (defaults to 500m)'. Since the schema itself provides no descriptions, this fully compensates and clarifies units and semantics for all parameters.
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 opens with 'Generate a comprehensive profile of an area including all amenities and features,' which clearly states a specific action and resource. It further specifies that it identifies and categorizes geographic features, amenities, and points of interest, distinguishing it from narrower siblings like find_nearby_places or search_category.
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 states use cases: 'Excellent for neighborhood research, area comparisons, and location-based decision making.' This gives clear context on when to use the tool. However, it does not explicitly mention when not to use it or directly reference alternative tools, so it stops short of a full when/where-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate electric vehicle charging stations near a specific location.
This specialized search tool identifies EV charging infrastructure within a specified distance from a location. Results can be filtered by connector type (Tesla, CCS, CHAdeMO, etc.) and minimum power delivery. Essential for EV owners planning trips or evaluating potential charging stops.
Args: latitude: Center point latitude (decimal degrees) longitude: Center point longitude (decimal degrees) radius: Search radius in meters (defaults to 5000m/5km) connector_types: Optional list of specific connector types to filter by (e.g., ["type2", "ccs", "tesla"]) min_power: Minimum charging power in kW
Returns: List of charging stations with: - Location name and operator - Available connector types - Charging speeds - Number of charging points - Access restrictions - Other relevant metadata
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| latitude | Yes | ||
| longitude | Yes | ||
| min_power | No | ||
| connector_types | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the search behavior, filtering options, default radius, and a detailed return list. However, it does not mention pagination, no-result behavior, or any potential rate limits, which would push it to 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening statement, a brief explanatory paragraph, and organized Args/Returns sections. It is slightly verbose with the sentence 'Essential for EV owners planning trips or evaluating potential charging stops,' but overall each part earns its place and it remains focused.
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?
Despite having no output schema, the description fully explains return values, including 'Location name and operator, Available connector types, Charging speeds, Number of charging points, Access restrictions,' and 'Other relevant metadata.' It also covers key usage details like default radius and filter options, making it complete for this tool's 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 0%, so the description must compensate. The Args section explicitly defines each parameter with units, defaults, and examples (e.g., 'radius: Search radius in meters (defaults to 5000m/5km)' and 'connector_types: Optional list...'). This adds substantial meaning beyond the bare schema types.
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 begins with a clear, specific verb+resource: 'Locate electric vehicle charging stations near a specific location' and elaborates as a specialized search tool. It distinctly differentiates itself from siblings like find_parking_facilities by focusing on EV charging infrastructure, connector types, and power delivery.
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 provides clear context: 'This specialized search tool' and 'Essential for EV owners planning trips or evaluating potential charging stops.' It implies when to use the tool but does not explicitly name alternatives or state when not to use it, missing the 'when-not/alternatives' level required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover points of interest and amenities near a specific location.
This tool performs a comprehensive search around a geographic point to identify nearby establishments, amenities, and points of interest. Results are organized by category and subcategory, making it easy to find specific types of places. Essential for location-based recommendations, neighborhood analysis, and proximity-based decision making.
Args: latitude: Center point latitude (decimal degrees) longitude: Center point longitude (decimal degrees) radius: Search radius in meters (defaults to 1000m/1km) categories: List of OSM categories to search for (e.g., ["amenity", "shop", "tourism"]). If omitted, searches common categories. limit: Maximum number of total results to return
Returns: Structured dictionary containing: - Original query parameters - Total count of places found - Results grouped by category and subcategory - Each place includes name, coordinates, and associated tags
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| radius | No | ||
| latitude | Yes | ||
| longitude | Yes | ||
| categories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It explains the search scope, result grouping, and return structure. However, it does not explicitly state that it is read-only, how errors or empty results are handled, or any limitations, leaving some behavioral gaps.
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 well-structured with a clear opening sentence, a brief use-case statement, and detailed Args/Returns sections. Some redundancy with the schema exists, but the added defaults and examples justify the length.
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 absence of an output schema and annotations, the description appropriately provides a detailed return structure and parameter semantics. It lacks details on sorting order and error handling, but overall it gives a complete picture for a search tool.
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?
The input schema has no parameter descriptions, but the Args section compensates fully. It explains latitude/longitude as center point, radius with default and unit, categories with examples and default behavior, and limit as maximum total results. This goes well beyond the bare 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?
The description clearly states the tool's function: discovering points of interest and amenities via a comprehensive search around a geographic point. It distinguishes itself from siblings by highlighting category grouping and broad coverage, though it does not explicitly name alternative tools for specific category searches.
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 provides clear use cases: location-based recommendations, neighborhood analysis, and proximity-based decision making. It implies this is the general-purpose search while siblings may be more specific, but it does not explicitly say when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate parking facilities near a specific location.
This tool finds parking options (lots, garages, street parking) near a specified location. Results can be filtered by parking type and include capacity information where available. Useful for trip planning, city navigation, and evaluating parking availability in urban areas.
Args: latitude: Center point latitude (decimal degrees) longitude: Center point longitude (decimal degrees) radius: Search radius in meters (defaults to 1000m/1km) parking_type: Optional filter for specific types of parking facilities ("surface", "underground", "multi-storey", etc.)
Returns: List of parking facilities with: - Name and type - Capacity information if available - Fee structure if available - Access restrictions - Distance from search point
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| latitude | Yes | ||
| longitude | Yes | ||
| parking_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return format including name, type, capacity (if available), fee structure (if available), access restrictions, and distance. It also clarifies that capacity information is provided 'where available,' setting expectations for incomplete data.
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 well-structured with a lead sentence, usage context, and clear Args/Returns sections. Minor redundancy exists between the first two sentences ('Locate parking facilities' and 'This tool finds parking options'), but the overall length is appropriate.
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?
The description covers all four parameters and the return list structure, which is sufficient given the tool's simplicity. It lacks explicit mention of result ordering or empty-result behavior, but these are minor gaps.
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 descriptions are absent (0% coverage), but the Args section explains each parameter: latitude/longitude as decimal degrees, radius with default of 1000m, and parking_type with example values. This fully compensates for the schema gap.
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 opens with 'Locate parking facilities near a specific location,' a specific verb+resource statement. It distinguishes from sibling tools by focusing exclusively on parking lots/garages/street parking, unlike broader tools like find_nearby_places or find_ev_charging_stations.
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 states it is 'Useful for trip planning, city navigation, and evaluating parking availability in urban areas,' providing clear context. It does not explicitly exclude alternatives but its specificity to parking and mention of filters gives practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate educational institutions near a specific location, filtered by education level.
This specialized search tool identifies schools, colleges, and other educational institutions within a specified distance from a location. Results can be filtered by education level (elementary, middle, high school, university, etc.). Essential for families evaluating neighborhoods or real estate purchases with education considerations.
Args: latitude: Center point latitude (decimal degrees) longitude: Center point longitude (decimal degrees) radius: Search radius in meters (defaults to 2000m/2km) education_levels: Optional list of specific education levels to filter by (e.g., ["elementary", "secondary", "university"])
Returns: List of educational institutions with: - Name and type - Distance from search point - Education levels offered - Contact information if available - Other relevant metadata
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| latitude | Yes | ||
| longitude | Yes | ||
| education_levels | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the default radius, optional education_levels filter, and the fields returned, but does not disclose sorting behavior, edge cases, or any potential side effects. It adds some context but is not exhaustive.
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 well-structured with an overview, Args, and Returns sections. It is slightly verbose but each part provides useful information. It front-loads the main purpose and uses bullet-like formatting for readability.
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 output schema and no annotations, the description covers the parameter semantics and return format in enough detail for basic usage. However, it lacks edge-case information such as result sorting, handling of empty results, or radius inclusivity, making it just short of fully 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?
The input schema has no descriptions (0% schema description coverage). The description's Args section explains every parameter with units, defaults, and examples for education_levels, adding significant meaning beyond the schema's simple titles.
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 'locates educational institutions near a specific location, filtered by education level.' It uses specific verbs and resources, and distinguishes itself from generic sibling tools like find_nearby_places and search_category by focusing on schools and education levels.
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?
It provides clear context for use, such as 'families evaluating neighborhoods or real estate purchases with education considerations,' but does not explicitly mention when not to use the tool or recommend alternatives. It gives a use case but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an address or place name to geographic coordinates with detailed location information.
This tool takes a text description of a location (such as an address, landmark name, or place of interest) and returns its precise geographic coordinates along with rich metadata. The results can be used for mapping, navigation, location-based analysis, and as input to other geospatial tools.
Args: address: The address, place name, landmark, or description to geocode (e.g., "Empire State Building", "123 Main St, Springfield", "Golden Gate Park, San Francisco")
Returns: List of matching locations with: - Geographic coordinates (latitude/longitude) - Formatted address - Administrative boundaries (city, state, country) - OSM type and ID - Bounding box (if applicable) - Importance ranking
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (list of matches, coordinates, formatted address, admin boundaries, OSM type/id, bounding box, importance ranking), which gives useful behavioral insight. However, it does not mention potential ambiguity (e.g., multiple matches), error conditions, or whether the operation is read-only (though implied). More disclosure would improve it.
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 well-structured with a clear summary, an explanatory paragraph, and explicit Args/Returns sections. It is slightly longer than necessary for a single-parameter tool, but every sentence provides useful information. It is front-loaded with the core purpose, so appropriate.
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 there is no output schema, the description appropriately details the return format. It covers the key aspects needed to use the tool: what input to provide, what output to expect, and the structure of results. It does not cover edge cases like empty results or API limitations, but for a geocoding tool this is sufficient.
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?
The schema provides only a bare 'address' string with 0% coverage. The description compensates fully by explaining the parameter: 'The address, place name, landmark, or description to geocode' and offers concrete examples. This adds significant semantic meaning beyond the schema, making the tool easy to invoke correctly.
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 function: 'Convert an address or place name to geographic coordinates with detailed location information.' This uses a specific verb and resource, and the scope is unambiguous. It implicitly distinguishes from sibling tool reverse_geocode by specifying forward geocoding.
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 provides usage context: 'The results can be used for mapping, navigation, location-based analysis, and as input to other geospatial tools.' This implies when it is useful, though it does not explicitly mention when not to use it or alternative tools. Still, the purpose is clear enough for an agent to select it for address-to-coordinates tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate detailed route directions between two geographic points.
This tool provides comprehensive turn-by-turn navigation directions between any two locations on Earth. It calculates the optimal route based on the specified transportation mode and returns detailed information about distance, duration, maneuvers, and the route geometry. Perfect for trip planning, navigation assistance, and commute analysis.
Args: from_latitude: Starting point latitude (decimal degrees) from_longitude: Starting point longitude (decimal degrees) to_latitude: Destination latitude (decimal degrees) to_longitude: Destination longitude (decimal degrees) mode: Transportation mode - options include: - "car" (default): Standard automobile routing - "bike": Bicycle-friendly routes - "foot": Pedestrian walking paths
Returns: Comprehensive routing information including: - Summary with total distance (meters) and duration (seconds) - Turn-by-turn directions with individual segments - Route geometry for mapping visualization - Waypoint information
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | car | |
| to_latitude | Yes | ||
| to_longitude | Yes | ||
| from_latitude | Yes | ||
| from_longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: calculates the optimal route based on mode, returns distance/duration/maneuvers/geometry, and supports car/bike/foot modes. It clarifies that coordinates are in decimal degrees. It does not mention rate limits or error handling, but the core behavior is well covered.
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 well-structured with a summary, Args, and Returns sections, and it front-loads the purpose. It is slightly verbose with phrases like 'between any two locations on Earth,' but the structure makes it easy to parse and the content is relevant.
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 tool with no annotations and no output schema, the description provides parameter semantics, return value details, and use cases. It lacks explicit error handling or regional availability notes, but overall it gives an agent enough context to select and invoke the tool 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?
Schema description coverage is 0%, so the description compensates by explaining every parameter: coordinates as decimal degrees and the mode options with the default 'car'. This adds significant meaning beyond the bare schema property names and types.
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 'Calculate detailed route directions between two geographic points,' which is a specific verb and resource. It distinguishes itself from sibling tools like geocoding and nearby search by focusing on turn-by-turn navigation.
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 provides clear use cases: 'Perfect for trip planning, navigation assistance, and commute analysis.' It doesn't explicitly mention when not to use it or alternatives, but the context is sufficient for an agent to understand the primary scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert geographic coordinates to a detailed address and location description.
This tool takes a specific point on Earth (latitude and longitude) and returns comprehensive information about that location, including its address, nearby landmarks, administrative boundaries, and other contextual information. Useful for translating GPS coordinates into human-readable locations.
Args: latitude: The latitude coordinate (decimal degrees, WGS84) longitude: The longitude coordinate (decimal degrees, WGS84)
Returns: Detailed address and location information including: - Formatted address - Building, street, city, state, country - Administrative hierarchy - OSM metadata - Postal code and other relevant identifiers
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the nature of the operation (returns information, not mutating data) and details the output contents. It does not mention potential errors, rate limits, or network dependencies, but for a read-only reverse geocoding tool, the transparency is adequate.
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 well-structured with a clear summary, detailed paragraph, and explicit Args/Returns sections. It is slightly longer than necessary but every sentence contributes value, and the structure aids scanning.
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 two-parameter tool with no output schema, the description is complete: it covers both inputs thoroughly, explains the output structure, and gives usage context. It is sufficient for an agent to select and invoke the tool 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?
Schema description coverage is 0%, so the description fully compensates by explaining latitude and longitude as decimal degrees in WGS84. This adds meaningful semantic context beyond the schema's basic number type and required flags.
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 converts geographic coordinates to a detailed address and location description, using a specific verb and resource. It implicitly distinguishes itself from sibling geocode_address (which does the inverse) by focusing on coordinate-to-address conversion.
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 provides clear context by stating it is useful for translating GPS coordinates into human-readable locations. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific types of places within a defined geographic area.
This tool allows targeted searches for places matching specific categories within a rectangular geographic region. It's particularly useful for filtering places by type (restaurants, schools, parks, etc.) within a neighborhood or city district. Results include complete location details and metadata about each matching place.
Args: category: Main OSM category to search for (e.g., "amenity", "shop", "tourism", "building") min_latitude: Southern boundary of search area (decimal degrees) min_longitude: Western boundary of search area (decimal degrees) max_latitude: Northern boundary of search area (decimal degrees) max_longitude: Eastern boundary of search area (decimal degrees) subcategories: Optional list of specific subcategories to filter by (e.g., ["restaurant", "cafe"])
Returns: Structured results including: - Query parameters - Count of matching places - List of matching places with coordinates, names, and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| max_latitude | Yes | ||
| min_latitude | Yes | ||
| max_longitude | Yes | ||
| min_longitude | Yes | ||
| subcategories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It discloses the return format ('Structured results including...') and that results contain complete location details and metadata. It does not mention edges like limits or sorting, but for a search tool this level of detail is reasonably transparent.
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 well-structured with a one-sentence summary, a brief contextual paragraph, a clean Args list, and a clear Returns section. It avoids wordiness and each sentence earns its place.
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?
The description covers the purpose, all six parameters, and the return structure. However, it does not clarify how it differs from overlapping siblings like 'find_nearby_places' or 'explore_area', which would be useful context but is not essential for basic invocation.
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 0%, but the description provides a full Args section explaining each parameter with examples (e.g., 'category: Main OSM category…', 'min_latitude: Southern boundary…'). This fully compensates for the schema's lack of descriptions.
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 opens with a clear verb+resource+scope: 'Search for specific types of places within a defined geographic area.' It then specifies a rectangular geographic region and OSM categories, which distinguishes it from point-based 'nearby' searches and other geospatial tools.
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 provides context on when this tool is useful ('within a neighborhood or city district') but does not explicitly name alternatives or state when to use a different sibling tool. Since context is clear but exclusions are absent, a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the optimal meeting place for multiple people coming from different locations.
This tool calculates a central meeting point based on the locations of multiple individuals, then recommends suitable venues near that central point. Ideal for planning social gatherings, business meetings, or any situation where multiple people need to converge from different starting points.
Args: locations: List of dictionaries, each containing the latitude and longitude of a person's location Example: [{"latitude": 37.7749, "longitude": -122.4194}, {"latitude": 37.3352, "longitude": -121.8811}] venue_type: Type of venue to suggest as a meeting point. Options include: "cafe", "restaurant", "bar", "library", "park", etc.
Returns: Meeting point recommendations including: - Calculated center point coordinates - List of suggested venues with names and details - Total number of matching venues in the area
| Name | Required | Description | Default |
|---|---|---|---|
| locations | Yes | ||
| venue_type | No | cafe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the calculating/recommending behavior and output structure, and it implies read-only semantics ('recommends') without explicitly stating no side effects. It does not define what 'optimal' means (e.g., geographic vs. travel-time) or address failure modes, leaving moderate transparency gaps.
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 well-structured with an opening summary, a detailed explanatory paragraph, and separate 'Args' and 'Returns' sections. It is moderately concise, though there is some redundancy between the first sentence and the second paragraph. Overall it is organized and readable.
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 two-parameter tool with no output schema, the description covers input structure, venue options, and expected output (center point, venue list, total count). It is adequate for an agent to select and invoke the tool. It omits algorithmic details and error behavior, but these are not essential for basic usage.
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 0%, so the description must compensate. It provides a concrete example for 'locations' using latitude/longitude dictionaries and lists venue_type options with examples and 'etc.' This adds clear meaning beyond the schema. It does not mention the default 'cafe' for venue_type (though the schema carries that), so a small gap remains.
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 states a specific verb ('Find') and resource ('optimal meeting place for multiple people coming from different locations'), and continues with 'calculates a central meeting point' and 'recommends suitable venues.' This clearly distinguishes it from sibling tools like find_nearby_places (single-origin search) and get_route_directions (routing). The core functionality is immediately evident.
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 names ideal contexts: 'social gatherings, business meetings, or any situation where multiple people need to converge from different starting points.' This gives clear usage context. However, it does not directly state when not to use it or name alternative tools, so it lacks explicit exclusionary guidance.
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.1analyze_commuteanalyze_neighborhoodexplore_areafind_ev_charging_stationsfind_nearby_placesfind_parking_facilitiesfind_schools_nearbygeocode_addressget_route_directionsreverse_geocodesearch_categorysuggest_meeting_pointScored across 12 tools
Several tools perform similar place searches (find_nearby_places, search_category, explore_area, analyze_neighborhood) with only subtle differences in scope and output. The specialized find_* tools overlap with generic search capabilities, making misselection likely.
All tool names follow a consistent lowercase verb_noun pattern (reverse_geocode, find_nearby_places, analyze_neighborhood, etc.). The naming convention is uniform and predictable.
The server contains 12 tools, which is well within the ideal 3-15 range. Each tool serves a distinct geospatial use case, and the count feels appropriate for the domain.
The tool set covers geocoding, reverse geocoding, place search, routing, and neighborhood analysis. Minor gaps exist, such as missing direct OSM object detail lookup, but the core functionality is well represented.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Geospatial intelligence with Mapbox APIs like geocoding, POI search, directions, isochrones, etc.
Geocoding, weather forecasts, and timezone lookups
