Provides access to a suite of 30 tools for OpenStreetMap data, including global geocoding, turn-by-turn routing via OSRM, point-of-interest discovery, and advanced data analysis through Overpass QL and OSMOSE quality assurance services.
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., "@OpenStreetMap MCP Server Get driving directions from Changi Airport to Marina Bay Sands"
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.
A powerful Model Context Protocol (MCP) server for OpenStreetMap, providing 30 tools for geocoding, routing, quality assurance, and data analysis. Optimized for AI assistants like Cursor and Claude.
A community project by Grab — providing open-source mapping tools to help developers and researchers work with OpenStreetMap data more effectively.
git clone https://github.com/GRABOSM/osm-mcp.git
cd osm-mcp
npm install
npm run buildOpen Cursor Settings → Features → Model Context Protocol.
Add a new server with:
Type: command
Command: node /absolute/path/to/osm-mcp/dist/index.js
Add this to your mcp.json:
{
"mcpServers": {
"osm-mcp": {
"command": "node",
"args": ["/absolute/path/to/osm-mcp/dist/index.js"]
}
}
}Add this to your claude_desktop_config.json:
{
"mcpServers": {
"osm": {
"command": "node",
"args": ["/absolute/path/to/osm-mcp/dist/index.js"]
}
}
}Try asking your AI:
"Find coffee shops in Makati, Manila"
"Calculate a 15-minute driving isochrone from Grab HQ Singapore"
"Get directions from Changi Airport to Marina Bay Sands"
Related MCP server: Geo MCP Worker
Geocoding: Search addresses and landmarks globally.
Routing (OSRM): Turn-by-turn directions, distance matrices, and route optimization.
Smart POI: Find restaurants, shops, and attractions with intelligent tag detection.
Quality Assurance (OSMOSE): Detect mapping errors and monitor data quality.
Changeset Analysis: Analyze recent edits and user contributions.
Tag Intelligence (Taginfo): Real-world tag usage statistics and validation.
Dual Interface: Use via MCP (AI tools) or HTTP REST API.
search_location: Search for places and addresses.
reverse_geocode: Get address from coordinates.
search_structured: Search by street, city, country, etc.
get_place_details: Get full details of an OSM element.
search_pois: General POI search (amenities, shops, etc.).
search_pois_smart: Intelligent POI search with category detection.
find_amenities_nearby: Locate facilities within a specific radius.
get_osrm_route: Detailed turn-by-turn directions.
get_distance_matrix: Travel times and distances between multiple points.
optimize_route: Find the best route through multiple stops (TSP).
map_match_gps: Snap GPS traces to the road network.
calculate_isochrone: Area reachable within a time limit.
search_highways_smart: Smart search for roads and motorways.
get_elements_in_bounds: Get all data within a bounding box.
search_by_tags: Find elements by specific OSM tags.
get_route_data: Extract road geometry for custom use.
execute_overpass_query: Run advanced Overpass QL queries.
snap_to_roads: Find the nearest road for any point.
get_changeset: Details of a specific mapping edit.
search_changesets: Find edits by user, time, or location.
get_changeset_diff: View exact changes made in an edit.
osmose_search_issues: Find data errors with filters.
osmose_get_issue_details: Details of a specific quality issue.
osmose_get_issues_by_country: Quality issues by nation.
osmose_get_issues_by_user: Issues related to a specific user.
osmose_get_stats: Data quality metrics and charts.
osmose_get_items: List of detectable issue categories.
get_tag_suggestions: Autocomplete for OSM tags.
get_tag_stats: Usage statistics for any tag.
validate_osm_tag: Check if a tag combination is proper.
"Get directions from KL Sentral to Petronas Twin Towers"
"Calculate 30-minute driving isochrone from Grab HQ Singapore"
"Analyze recent mapping activity in Bengaluru"
Run as a standalone server:
npm run dev:httpAccess docs at: http://localhost:8888/api/info
Absolute Paths: Always use full paths in AI tool configurations.
Build First: Ensure you run npm run build after any changes.
Node Version: Use Node.js v18 or higher.
This project is licensed under the MIT License.
OpenStreetMap Contributors
OSRM, Nominatim, Overpass, OSMOSE, Taginfo communities.
Calculate travel time isochrone (areas reachable within time limit) using Valhalla
| Name | Required | Description | Default |
|---|---|---|---|
| center_longitude | Yes | Center longitude | |
| center_latitude | Yes | Center latitude | |
| max_duration_seconds | Yes | Maximum travel time in seconds (1 minute to 1 hour) | |
| profile | No | Routing profile (default: driving). Maps to Valhalla costing: driving->auto, walking->pedestrian, cycling->bicycle | |
| contours | No | Optional: Array of contours to generate. If not provided, uses max_duration_seconds as single contour. Example: [{"time": 5}, {"time": 10}, {"time": 15}] | |
| polygons | No | Return polygons (true) or lines (false). Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions the technology (Valhalla) but doesn't disclose rate limits, authentication requirements, computational cost, output format, or error conditions. For a complex geospatial calculation tool, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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, efficient sentence that packs essential information: action, definition, and technology. Every word earns its place with no redundancy or unnecessary elaboration. It's perfectly front-loaded with the core functionality.
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 6 parameters, no annotations, and no output schema, the description provides adequate basic purpose but lacks important contextual information. It doesn't explain what the output looks like (geojson? image?), performance characteristics, or common use cases. The schema handles parameter documentation well, but the description should compensate more for the missing annotations and output 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?
The description doesn't add parameter details beyond what's already in the schema (which has 100% coverage), but it provides crucial context by defining what an isochrone is and mentioning Valhalla. This helps the agent understand the overall purpose of the parameters. Since schema coverage is complete, the baseline is 3, and the additional context justifies a 4.
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 specific action ('calculate travel time isochrone'), defines what an isochrone is ('areas reachable within time limit'), and specifies the technology used ('using Valhalla'). It distinguishes itself from siblings like 'get_distance_matrix' or 'get_osrm_route' by focusing on area-based reachability rather than point-to-point routing or distance calculations.
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 implies usage context through the term 'isochrone' and Valhalla reference, suggesting it's for geographic accessibility analysis. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_distance_matrix' for multiple point-to-point calculations or 'get_osrm_route' for specific route planning. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a custom Overpass QL query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Overpass QL query string | |
| timeout | No | Query timeout in seconds (default: 25) | |
| maxsize | No | Maximum response size in bytes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions executing a query but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or response format. This is inadequate for a tool that likely interacts with external APIs.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized, making it easy to parse without unnecessary elaboration.
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 annotations, no output schema, and a tool that executes custom queries (potentially complex with external dependencies), the description is incomplete. It should cover more behavioral aspects, response expectations, or error cases to be fully helpful.
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 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying a custom query, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Execute') and resource ('custom Overpass QL query'), making the tool's purpose evident. However, it doesn't differentiate from siblings like 'search_by_tags' or 'get_elements_in_bounds' that might also query Overpass data, missing specific distinction.
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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for querying OSM data (e.g., 'search_by_tags', 'get_elements_in_bounds'), the description lacks context on use cases, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find amenities near a specific location
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude | |
| lon | Yes | Longitude | |
| radius | No | Search radius in meters (default: 1000) | |
| amenity_type | No | Specific amenity type to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds amenities but lacks details on what constitutes an 'amenity', how results are returned (e.g., format, pagination), rate limits, authentication needs, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and appropriately sized for a straightforward search tool, making it easy for an agent to parse quickly.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, result limitations, or error conditions, which are critical for an agent to use the tool effectively. Without annotations or an output schema, the description should provide more context to compensate.
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 100%, so the schema fully documents all parameters (lat, lon, radius, amenity_type). The description adds no meaning beyond what the schema provides, such as examples of amenity types or clarification on coordinate systems. Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose with a specific verb ('Find') and resource ('amenities'), specifying the location-based nature ('near a specific location'). It distinguishes itself from most siblings by focusing on amenities rather than routes, distances, or OSM data operations, though it doesn't explicitly differentiate from similar tools like 'search_pois' or 'search_pois_smart'.
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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools available for location-based searches (e.g., 'search_pois', 'search_pois_smart', 'search_location'), the description offers no context on preferred use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific changeset
| Name | Required | Description | Default |
|---|---|---|---|
| changeset_id | Yes | Changeset ID | |
| include_discussion | No | Include changeset discussion/comments (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying a read operation) but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or what 'detailed information' includes (e.g., format, fields). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 annotations and no output schema, the description is incomplete for a tool that retrieves 'detailed information'. It doesn't specify what information is returned (e.g., metadata, user details, changes), leaving the agent uncertain about the tool's output. For a read operation with no structured output documentation, this is a significant gap.
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 100%, with clear descriptions for both parameters in the input schema. The description doesn't add any meaningful semantics beyond what the schema already provides (e.g., it doesn't explain what a changeset ID is or give examples). This meets the baseline score when schema coverage is high.
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 verb ('Get') and resource ('detailed information about a specific changeset'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_changeset_diff' or 'search_changesets', which would require more specificity about what 'detailed information' entails compared to those alternatives.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_changeset_diff' (which might provide diff details) or 'search_changesets' (which might list multiple changesets), leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the diff/changes for a specific changeset
| Name | Required | Description | Default |
|---|---|---|---|
| changeset_id | Yes | Changeset ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves diff/changes but does not specify what the diff includes (e.g., format, scope), whether it's read-only or has side effects, or any limitations like rate limits or authentication needs. This leaves significant gaps in understanding the tool's 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?
The description is extremely concise, consisting of a single sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficient, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It does not explain what the diff output includes (e.g., format, structure), potential errors, or how it differs from related tools like 'get_changeset'. This leaves the agent with insufficient context to use the tool effectively.
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 100% description coverage, with the single parameter 'changeset_id' documented as 'Changeset ID'. The description adds no additional semantic context beyond this, such as examples or constraints, but since the schema is fully covered, a baseline score of 3 is appropriate as it doesn't compensate for gaps but doesn't need to.
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 purpose as retrieving diff/changes for a specific changeset, using the verb 'Get' and specifying the resource 'changeset'. However, it does not differentiate from sibling tools like 'get_changeset' or 'search_changesets', which might have overlapping or related functionality, leaving some ambiguity about its unique role.
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 no guidance on when to use this tool versus alternatives, such as 'get_changeset' or 'search_changesets', nor does it mention any prerequisites or exclusions. It lacks context for distinguishing its use from sibling tools, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate distance and duration matrix between multiple points
| Name | Required | Description | Default |
|---|---|---|---|
| coordinates | Yes | Array of [longitude, latitude] coordinates | |
| profile | No | Routing profile (default: driving) | |
| sources | No | Indices of source coordinates | |
| destinations | No | Indices of destination coordinates | |
| annotations | No | Additional annotations to include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states the calculation action but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, error conditions (e.g., invalid coordinates), or the format of the output matrix. For a tool with 5 parameters and no output schema, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place, contributing to clarity without unnecessary elaboration.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance), usage context, and output format, which are crucial for an agent to invoke it correctly. While the schema covers parameters well, the overall context for effective tool use is insufficient.
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 adds no specific meaning beyond what the input schema provides, as it doesn't mention any parameters or their roles. However, with 100% schema description coverage, the baseline score is 3, as the schema already documents all parameters (e.g., 'coordinates' as an array of [longitude, latitude], 'profile' with enum values). The description doesn't compensate but doesn't need to, given the comprehensive 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 purpose with a specific verb ('calculate') and resource ('distance and duration matrix between multiple points'), making it immediately understandable. However, it doesn't explicitly distinguish this matrix calculation from sibling tools like 'get_osrm_route' (which might calculate single routes) or 'optimize_route' (which might optimize based on such matrices), leaving some ambiguity about its unique role.
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 no guidance on when to use this tool versus alternatives. For example, it doesn't explain when to choose this over 'get_osrm_route' for single routes or 'optimize_route' for routing optimization, nor does it mention prerequisites like coordinate formatting or limitations. This lack of context makes it harder for an agent to select the right tool in practice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all OSM elements within a bounding box
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | Yes | Bounding box coordinates | |
| element_types | No | Types of elements to include (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets all OSM elements' but doesn't mention performance characteristics (e.g., rate limits, result size limits), authentication requirements, or what 'all' means in practice (complete data vs. sampled). For a query tool with potentially large result sets, this is a significant gap.
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, efficient sentence that front-loads the essential information. Every word earns its place with no wasted text, making it immediately clear what the tool does without unnecessary elaboration.
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 read-only query tool with good schema coverage but no output schema, the description is minimally adequate. It explains what the tool does but lacks important context about result format, pagination, performance limits, and differentiation from similar tools. With no annotations and no output schema, users must infer behavioral characteristics.
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 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it mentions 'bounding box' but doesn't explain coordinate systems, units, or valid ranges. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Get all') and resource ('OSM elements within a bounding box'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_by_tags' or 'search_structured' that might also retrieve OSM elements with different filtering approaches.
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 no guidance on when to use this tool versus alternatives. With many sibling tools for querying OSM data (e.g., 'search_by_tags', 'search_structured', 'execute_overpass_query'), there's no indication of when spatial bounding box queries are preferred over tag-based or other search methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed route with turn-by-turn directions using OSRM
| Name | Required | Description | Default |
|---|---|---|---|
| coordinates | Yes | Array of [longitude, latitude] coordinates | |
| profile | No | Routing profile (default: driving) | |
| alternatives | No | Return alternative routes | |
| steps | No | Include turn-by-turn instructions (default: true) | |
| geometries | No | Geometry format (default: polyline) | |
| overview | No | Geometry overview level (default: full) | |
| language | No | Language for instructions (ISO 639-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'detailed route' and 'turn-by-turn directions', hinting at output behavior, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what 'detailed' entails. For a routing tool with no annotations, this is a significant gap.
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, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a tool with a clear function, earning its place by concisely stating what the tool does.
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 (routing with multiple parameters) and no output schema, the description is minimally adequate. It hints at output ('detailed route with turn-by-turn directions') but lacks details on return format, error cases, or performance. With no annotations and incomplete behavioral context, it's functional but has clear 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 description coverage is 100%, meaning all parameters are documented in the schema. The description adds no parameter-specific information beyond what's in the schema, such as examples or usage tips. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 purpose: 'Get detailed route with turn-by-turn directions using OSRM'. It specifies the verb ('Get'), resource ('detailed route'), and key feature ('turn-by-turn directions'), distinguishing it from siblings like 'get_distance_matrix' or 'optimize_route'. However, it doesn't explicitly differentiate from 'get_route_data', which might be similar, so it's not a perfect 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over siblings like 'get_route_data', 'optimize_route', or 'map_match_gps', nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific OSM place
| Name | Required | Description | Default |
|---|---|---|---|
| osm_type | Yes | OSM element type (N=Node, W=Way, R=Relation) | |
| osm_id | Yes | OSM element ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, data freshness, or error handling. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, direct sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with the main action and resource, making it easy to parse quickly for an AI agent.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., tags, geometry, metadata) or potential behavioral traits like response format or errors. For a tool with no structured behavioral hints, this leaves the agent under-informed about critical operational aspects.
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 100% description coverage, with clear documentation for both parameters (e.g., osm_type enum values explained). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage without compensating value.
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 verb 'Get' and the resource 'detailed information about a specific OSM place', making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'get_elements_in_bounds' or 'search_structured', which might also retrieve OSM data but with different scopes or methods.
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 no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for retrieving pre-existing place details versus searching or filtering, nor does it mention prerequisites like needing OSM identifiers, leaving the agent to infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get road/path data for routing between two points
| Name | Required | Description | Default |
|---|---|---|---|
| start_lat | Yes | ||
| start_lon | Yes | ||
| end_lat | Yes | ||
| end_lon | Yes | ||
| route_type | No | Type of route (default: driving) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't mention any behavioral traits like rate limits, authentication requirements, data freshness, response format, or potential side effects. For a routing tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 extremely concise - a single sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. It's appropriately sized for a tool with a straightforward purpose, though this conciseness comes at the cost of completeness.
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 complexity of routing (which typically involves multiple algorithms, data sources, and output formats), the description is insufficient. With no annotations, no output schema, and low schema description coverage, the description doesn't provide enough context about what 'road/path data' includes, how results are structured, or any limitations of the routing service.
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 only 20% (only 'route_type' has a description), so the description needs to compensate. However, it doesn't mention any parameters beyond implying two points are needed. It doesn't explain what the lat/lon parameters represent, their format, or the meaning of 'route_type' options. The description adds minimal value beyond what the bare schema provides.
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 purpose: 'Get road/path data for routing between two points'. It specifies the action ('Get'), resource ('road/path data'), and context ('routing between two points'), which is more specific than just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'get_osrm_route' or 'optimize_route', which likely have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. With many sibling tools available (like 'get_osrm_route', 'optimize_route', 'get_distance_matrix'), there's no indication of what makes this tool distinct or when it should be preferred. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get usage statistics for OSM tags from Taginfo
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | OSM tag key (e.g., "highway", "amenity", "shop") | |
| include_values | No | Include popular values for the key (default: true) | |
| values_limit | No | Maximum number of values to include (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics but does not mention potential limitations such as rate limits, data freshness, or error handling. For a read operation with external data sources, this omission leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information, earning 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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output expectations. Without annotations or an output schema, the description should provide more completeness to guide the agent effectively, but it falls short of being fully informative.
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 100% description coverage, clearly documenting all three parameters. The description adds no additional semantic context beyond what the schema provides, such as explaining the significance of 'Taginfo' or typical use cases for the parameters. However, with high schema coverage, the baseline score of 3 is appropriate as the schema adequately handles parameter documentation.
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 specific action ('Get usage statistics') and resource ('for OSM tags from Taginfo'), distinguishing it from sibling tools like 'get_tag_suggestions' or 'validate_osm_tag' which focus on different aspects of OSM tags. It precisely identifies what the tool does without being vague or tautological.
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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'search_by_tags' or 'validate_osm_tag', nor does it specify contexts or exclusions for usage. This lack of comparative information leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OSM tag suggestions and autocomplete based on Taginfo statistics
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Partial tag input (e.g., "highway", "amenity=rest", "shop=super") | |
| limit | No | Maximum number of suggestions (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits like rate limits, authentication needs, response format, or whether it's read-only/destructive. The mention of 'Taginfo statistics' hints at data source but lacks operational details.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and includes the key detail about Taginfo statistics, making it appropriately sized for the tool's 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?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or practical usage context. Given the sibling tools include similar tag-related functions, more guidance on differentiation would improve completeness.
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 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying the 'input' parameter is for partial tags, which is already covered in the schema's examples. Baseline 3 is appropriate as the schema handles parameter semantics.
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 verb 'Get' and the resource 'OSM tag suggestions and autocomplete', specifying it's based on Taginfo statistics. It distinguishes from siblings like 'get_tag_stats' by focusing on suggestions/autocomplete rather than raw statistics, though it doesn't explicitly contrast them.
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?
No guidance is provided on when to use this tool versus alternatives like 'search_by_tags' or 'validate_osm_tag'. The description implies usage for partial inputs but doesn't specify scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map-match GPS traces to road network
| Name | Required | Description | Default |
|---|---|---|---|
| coordinates | Yes | Array of [longitude, latitude] GPS coordinates | |
| profile | No | Routing profile (default: driving) | |
| timestamps | No | Unix timestamps for each coordinate | |
| radiuses | No | Search radius for each coordinate (meters) | |
| steps | No | Include turn-by-turn instructions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't explain what 'map-match' entails (e.g., algorithm used, accuracy, or output format), nor does it cover performance aspects like rate limits, authentication needs, or error handling, which are critical for a GPS processing tool.
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, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
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 complexity of GPS data processing and lack of annotations or output schema, the description is incomplete. It doesn't explain the output (e.g., matched coordinates, confidence scores) or behavioral traits like error conditions, leaving gaps that could hinder an agent's ability to use the tool effectively.
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 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining how parameters interact (e.g., timestamps for speed inference) or default behaviors. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('map-match') and resource ('GPS traces to road network'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'snap_to_roads' or 'get_osrm_route', which may have overlapping functionality for road network alignment.
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?
No guidance is provided on when to use this tool versus alternatives such as 'snap_to_roads' or 'get_osrm_route'. The description lacks context on prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve Traveling Salesman Problem to find optimal route through all points
| Name | Required | Description | Default |
|---|---|---|---|
| coordinates | Yes | Array of [longitude, latitude] coordinates to visit | |
| profile | No | Routing profile (default: driving) | |
| roundtrip | No | Return to starting point (default: false) | |
| source | No | Source coordinate constraint | |
| destination | No | Destination coordinate constraint | |
| steps | No | Include turn-by-turn instructions (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions solving TSP but doesn't disclose computational complexity, timeouts, rate limits, or what happens with invalid coordinates. The description doesn't explain what 'optimal' means (shortest distance, fastest time, etc.) or whether this is a heuristic vs exact solution.
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, efficient sentence that gets straight to the point. However, it could be slightly more front-loaded by mentioning key constraints like the 3-12 coordinate limit upfront. Every word earns its place, but there's room for slightly more informative structure.
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 complex optimization tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (optimized route, distance, duration), performance characteristics, or error conditions. The TSP context suggests computational intensity that should be disclosed.
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 100%, so the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It doesn't explain how 'coordinates' relate to TSP solving, or how 'profile' affects optimization. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('solve Traveling Salesman Problem') and resource ('optimal route through all points'). It distinguishes this from sibling tools like 'get_osrm_route' which likely provides standard routing rather than optimization, and 'get_distance_matrix' which calculates distances without route optimization.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_osrm_route' for standard routing, or when the TSP optimization is appropriate versus simpler routing approaches. No prerequisites or constraints are stated beyond what's in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific OSMOSE issue
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | OSMOSE issue ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying it's a read operation, but lacks details on permissions, rate limits, error handling, or response format. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral traits like error cases. For a tool with no structured data beyond the input schema, this leaves critical 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?
The input schema has 100% description coverage, with the 'issue_id' parameter clearly documented. The description doesn't add any meaning beyond the schema, such as examples or format details, but the high schema coverage justifies a baseline score of 3.
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 purpose with a specific verb ('Get') and resource ('detailed information about a specific OSMOSE issue'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'osmose_get_issues_by_country' or 'osmose_search_issues', which focus on broader queries rather than single-issue details.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an issue ID, or compare it to sibling tools like 'osmose_get_items' or 'osmose_search_issues', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OSMOSE issues in a specific country
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country name | |
| level | No | Optional severity level filter | |
| item | No | Optional issue type filter | |
| limit | No | Maximum number of results (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important traits like whether it's read-only, pagination behavior, rate limits, authentication needs, or what format/issues are returned. For a tool with 4 parameters and no output schema, this leaves significant 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear parameters documented elsewhere.
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 complexity (4 parameters, no annotations, no output schema, and multiple sibling tools with similar purposes), the description is inadequate. It doesn't explain what 'OSMOSE issues' are, how results are structured, or when to choose this tool over alternatives. For a data retrieval tool with filtering options, more context is needed.
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 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying country filtering. This meets the baseline of 3 when the schema does the heavy lifting, but doesn't provide extra value like explaining what 'OSMOSE issues' actually are or how the filters interact.
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 purpose with a specific verb ('Get') and resource ('OSMOSE issues'), and specifies the scope ('in a specific country'). However, it doesn't explicitly differentiate from sibling tools like 'osmose_get_issues_by_user' or 'osmose_search_issues', which could have overlapping functionality.
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 no guidance on when to use this tool versus alternatives like 'osmose_get_issues_by_user' or 'osmose_search_issues'. It mentions the country filter but doesn't explain when this tool is preferred over other issue-fetching tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OSMOSE issues last modified by a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | OSM username | |
| level | No | Optional severity level filter | |
| bbox | No | Optional bounding box filter | |
| limit | No | Maximum number of results (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves issues but lacks details on permissions, rate limits, pagination, error handling, or return format. For a read operation with multiple parameters, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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, clear sentence with zero wasted words. It front-loads the core purpose efficiently, making it easy to parse. Every part of the description earns its place by specifying the action, resource, and key constraint.
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 (4 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain what 'OSMOSE issues' are, how results are returned, or behavioral aspects like rate limits. For a tool with rich input options but no structured output or safety hints, more context is needed to guide effective use.
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 100%, so the input schema fully documents all parameters (username, level, bbox, limit). The description adds no additional parameter semantics beyond what's in the schema, such as explaining 'OSMOSE issues' context or filter interactions. This meets the baseline for high schema coverage.
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 purpose: 'Get OSMOSE issues last modified by a specific user.' It specifies the verb ('Get'), resource ('OSMOSE issues'), and key constraint ('by a specific user'). However, it doesn't explicitly differentiate from sibling tools like 'osmose_get_issues_by_country' or 'osmose_search_issues,' which would be needed for a perfect 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'osmose_get_issues_by_country' for country-based filtering or 'osmose_search_issues' for broader searches), nor does it specify prerequisites or exclusions. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available OSMOSE issue categories/items
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, response format, or any side effects. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential information without unnecessary elaboration.
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 has 0 parameters and no output schema, the description adequately covers the basic purpose. However, without annotations or output details, it lacks completeness for guiding an agent on behavioral aspects like response structure or operational constraints, which is a notable gap.
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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline expectation. No additional semantic value is required or provided.
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 action ('Get') and the resource ('OSMOSE issue categories/items'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'osmose_get_issue_details' or 'osmose_get_issues_by_country', which would require specifying this tool retrieves available categories/items rather than specific issues or filtered lists.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OSMOSE statistics (issue counts by level, type, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Optional bounding box filter | |
| country | No | Optional country filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify whether it requires authentication, has rate limits, returns paginated results, or what the output format looks like (e.g., JSON structure). For a tool with no annotation coverage, this leaves significant gaps in understanding its operational 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?
The description is a single, efficient sentence that front-loads the core purpose ('Get OSMOSE statistics') and adds clarifying examples ('issue counts by level, type, etc.') without unnecessary elaboration. Every word serves a purpose, making it easy to parse and understand quickly.
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 moderate complexity (2 optional parameters, nested object, no output schema), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits (due to no annotations), output format, or usage context. It's complete enough to identify the tool's function but insufficient for an agent to fully understand how to invoke it effectively without additional inference.
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 100%, with both parameters ('bbox' and 'country') documented as optional filters in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining how 'bbox' coordinates work or what country codes are accepted. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 action ('Get') and resource ('OSMOSE statistics') with specific examples of what statistics are returned ('issue counts by level, type, etc.'). It distinguishes from siblings like 'osmose_get_issue_details' or 'osmose_get_issues_by_country' by focusing on aggregated statistics rather than individual issues or filtered lists. However, it doesn't explicitly contrast with all statistical siblings like 'get_tag_stats'.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over other OSMOSE tools like 'osmose_get_issues_by_country' for country-level stats or 'osmose_search_issues' for filtered issue lists, nor does it specify prerequisites or exclusions. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for OSMOSE quality assurance issues with various filters
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Bounding box to search within | |
| item | No | Issue type/category (number or array of numbers) | |
| level | No | Severity level: 1=major, 2=normal, 3=minor (number or array) | |
| country | No | Filter by country name | |
| username | No | Filter by OSM username | |
| limit | No | Maximum number of results (default: 100) | |
| full | No | Get full details for each issue (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'search' implies a read-only operation, the description doesn't address important behavioral aspects: whether this tool requires authentication, rate limits, pagination behavior (beyond the 'limit' parameter), what the response format looks like, or error conditions. For a search tool with 7 parameters and no annotation coverage, this is inadequate.
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, efficient sentence that states the core purpose. There's no wasted verbiage or unnecessary elaboration. However, it could be slightly more front-loaded by specifying this is for OSM (OpenStreetMap) quality assurance to provide immediate context.
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 complexity (7 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain what OSMOSE is (OpenStreetMap quality assurance system), what types of issues it finds, the significance of severity levels, or what the search results contain. Without an output schema, the description should at least hint at the response structure for a tool with this many filtering options.
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 100%, so the schema already documents all 7 parameters thoroughly with descriptions, types, constraints, and defaults. The description adds no additional parameter information beyond mentioning 'various filters' generically. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 purpose: 'Search for OSMOSE quality assurance issues with various filters'. It specifies the verb ('search'), resource ('OSMOSE quality assurance issues'), and scope ('with various filters'). However, it doesn't explicitly differentiate from sibling tools like 'osmose_get_issues_by_country' or 'osmose_get_issues_by_user', which appear to be more specialized versions.
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 no guidance on when to use this tool versus alternatives. There are multiple sibling tools for OSMOSE issues (e.g., osmose_get_issues_by_country, osmose_get_issues_by_user, osmose_get_issue_details), but the description doesn't indicate whether this is the primary search tool or how it relates to those specialized ones. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get address information from coordinates (reverse geocoding)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude (-90 to 90) | |
| lon | Yes | Longitude (-180 to 180) | |
| zoom | No | Zoom level for detail (3-18, default: 18) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs reverse geocoding but doesn't describe any behavioral traits such as rate limits, authentication requirements, data sources, accuracy, or what happens with invalid coordinates. For a geocoding tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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, efficient sentence: 'Get address information from coordinates (reverse geocoding)'. It is front-loaded with the core purpose and uses parentheses to clarify the technical term. There is no wasted verbiage, making it highly concise and well-structured for quick understanding.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format. Without annotations or an output schema, the agent must infer these aspects, leaving room for uncertainty in tool selection and 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 100%, with clear documentation for 'lat', 'lon', and 'zoom' parameters including ranges and defaults. The description adds no additional parameter semantics beyond what the schema provides, such as explaining coordinate systems or how 'zoom' affects address detail. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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: 'Get address information from coordinates (reverse geocoding)'. It specifies the verb ('Get'), resource ('address information'), and transformation ('from coordinates'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_location' or 'get_place_details', which might also involve location-based queries.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'search_location' (which might handle forward geocoding) or 'get_place_details' (which might retrieve more specific place data). Usage is implied only by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for OSM elements by specific tags
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Key-value pairs of OSM tags to search for | |
| bbox | No | Bounding box to search within | |
| around | No | Search around a specific location |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches but doesn't mention critical details like rate limits, authentication needs, output format (e.g., JSON, GeoJSON), pagination, or error handling. For a search tool with complex parameters (bbox, around), this leaves significant gaps in understanding how it behaves.
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, efficient sentence: 'Search for OSM elements by specific tags.' It's front-loaded with the core purpose and contains no redundant or verbose language. Every word earns its place, making it easy for an agent to parse quickly.
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 complexity (3 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what 'OSM elements' are (e.g., nodes, ways, relations), how results are returned, or any limitations (e.g., max results, bounding box constraints). Without annotations or output schema, the agent lacks sufficient context to use the tool effectively.
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 100%, with clear descriptions for 'tags,' 'bbox,' and 'around' in the input schema. The description adds no additional parameter semantics beyond what's already documented in the schema. According to the rules, when coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 purpose: 'Search for OSM elements by specific tags.' It specifies the verb ('search') and resource ('OSM elements'), and the qualifier 'by specific tags' distinguishes it from generic search tools. However, it doesn't explicitly differentiate from sibling tools like 'search_pois' or 'search_structured,' which likely have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'search_pois,' 'search_structured,' 'get_elements_in_bounds'), the agent lacks context on whether this is the primary tag-based search or if others are preferred for specific scenarios. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for changesets with various filters
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Filter by username (string) or user ID (number). Username is more commonly used. | |
| display_name | No | Deprecated: Use "user" parameter instead. Filter by user display name for backward compatibility. | |
| bbox | No | Bounding box to search within | |
| time | No | Time filter (ISO 8601 format or comma-separated range) | |
| open | No | Filter for open changesets only | |
| closed | No | Filter for closed changesets only | |
| changesets | No | Specific changeset IDs to retrieve | |
| limit | No | Maximum number of results (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'various filters' but doesn't describe what a changeset is, the search scope (e.g., global vs. local), pagination behavior (beyond the 'limit' parameter), rate limits, authentication requirements, or expected output format. For a search tool with 8 parameters, this leaves significant 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded with the core purpose. Every word earns its place without redundancy or unnecessary elaboration.
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 (8 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what a changeset is in this context, the search domain (e.g., OpenStreetMap changesets), result format, or error conditions. The agent lacks critical context to use this tool effectively despite the well-documented 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 description coverage is 100%, so the schema fully documents all 8 parameters with descriptions. The description adds no additional parameter semantics beyond implying filtering capability. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 'Search for changesets with various filters' clearly states the verb ('search') and resource ('changesets'), and specifies the filtering capability. It distinguishes from siblings like 'get_changeset' (singular retrieval) and 'get_changeset_diff' (difference analysis), but doesn't explicitly contrast with other search tools like 'search_by_tags' or 'search_pois'.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to other search tools (e.g., 'search_by_tags', 'search_pois'), nor does it specify prerequisites or exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Smart highway search using Taginfo-enhanced queries for major roads, motorways, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Highway search intent: "major", "motorway", "primary", "all", or specific highway type | major |
| bbox | No | Bounding box to search within | |
| around | No | Search around a specific location | |
| limit | No | Maximum number of results (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Taginfo-enhanced queries' but doesn't explain what this entails—whether it affects performance, accuracy, or data sources. It lacks details on rate limits, authentication needs, error handling, or what the search returns (e.g., format, pagination). The description adds minimal context beyond the basic purpose.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a search tool, though it could be more front-loaded with key details like the target resource ('highways') to improve clarity at a glance.
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 complexity of a search tool with 4 parameters (including nested objects), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'Taginfo-enhanced' means, how results are returned, or any behavioral traits. For a tool with rich input schema but missing output and annotation context, more detail is needed to guide effective use.
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 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema—it doesn't clarify parameter interactions, default behaviors, or examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 purpose as 'Smart highway search using Taginfo-enhanced queries for major roads, motorways, etc.' It specifies the verb 'search' and resource 'highways' with the enhancement method 'Taginfo-enhanced queries.' However, it doesn't explicitly differentiate from sibling tools like 'search_by_tags' or 'search_pois_smart' that might also search OpenStreetMap data.
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 no guidance on when to use this tool versus alternatives. It mentions 'Taginfo-enhanced queries' but doesn't explain what this means or when it's preferable over other search tools like 'search_by_tags' or 'search_pois_smart.' There's no mention of prerequisites, exclusions, or specific contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for locations, addresses, or places using Nominatim geocoding service
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (address, place name, etc.) | |
| limit | No | Maximum number of results (1-100, default: 10) | |
| countrycodes | No | Limit search to specific countries (2-letter ISO codes) | |
| bounded | No | Restrict search to viewbox area | |
| viewbox | No | Bounding box to limit search area |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Nominatim geocoding service,' which implies external API usage, but doesn't disclose critical traits like rate limits, authentication needs, error handling, or response format. For a search tool with external dependencies, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose without unnecessary details. It's appropriately sized for a search tool, with zero waste or 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 complexity (5 parameters, external API dependency) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like rate limits or response structure, nor does it guide usage relative to siblings. For a tool with these characteristics, more context is needed.
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 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain query formatting best practices or viewbox coordinate systems). Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose: 'Search for locations, addresses, or places using Nominatim geocoding service.' It specifies the verb (search) and resource (locations/addresses/places) with the specific service (Nominatim). However, it doesn't explicitly differentiate from sibling tools like 'reverse_geocode' or 'search_by_tags,' which is why it doesn't achieve a perfect 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 no guidance on when to use this tool versus alternatives. It mentions 'Nominatim geocoding service' but doesn't explain when to choose this over sibling tools like 'reverse_geocode' (for coordinates to addresses) or 'search_by_tags' (for OSM tag-based searches). There's no mention of prerequisites, exclusions, or comparative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Points of Interest (POIs) using Overpass API
| Name | Required | Description | Default |
|---|---|---|---|
| amenity | No | Amenity type (restaurant, hospital, etc.) | |
| shop | No | Shop type (supermarket, bakery, etc.) | |
| cuisine | No | Cuisine type for restaurants | |
| tourism | No | Tourism type (hotel, attraction, etc.) | |
| bbox | No | Bounding box to search within | |
| around | No | Search around a specific location | |
| limit | No | Maximum number of results (1-100, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the Overpass API but doesn't explain rate limits, authentication requirements, response format, error conditions, or whether this is a read-only operation. For a search tool with 7 parameters and complex nested objects, this leaves significant 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 a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information. Every word 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?
Given the tool's complexity (7 parameters with nested objects), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how results are structured, error handling, or performance characteristics. For a search tool in a crowded namespace of 28 siblings, more context is needed to help the agent use it effectively.
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 description coverage is 100%, providing good documentation for all parameters. The description adds no additional parameter semantics beyond what's already in the schema. This meets the baseline expectation when schema coverage is high, but doesn't enhance understanding of how parameters interact or which combinations are most effective.
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 verb ('Search for') and resource ('Points of Interest (POIs)'), and specifies the API used ('Overpass API'). However, it doesn't distinguish this tool from its many siblings like 'search_pois_smart', 'find_amenities_nearby', or 'search_by_tags', leaving the agent uncertain about when to choose this specific tool.
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?
No guidance is provided on when to use this tool versus alternatives. With 28 sibling tools including several similar search tools (search_pois_smart, find_amenities_nearby, search_by_tags, search_structured), the agent receives no help in selecting this specific POI search implementation over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Smart POI search using Taginfo-enhanced queries for restaurants, shops, tourism, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | POI category: "restaurant", "shop", "tourism", "amenity", or specific type | |
| subcategory | No | Subcategory (e.g., cuisine type for restaurants, shop type for shops) | |
| bbox | No | Bounding box to search within | |
| around | No | Search around a specific location | |
| limit | No | Maximum number of results (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Taginfo-enhanced queries' which hints at some intelligence or data enrichment, but doesn't explain what this means operationally—how results differ, whether there are rate limits, authentication needs, or what the output format looks like. For a search tool with 5 parameters and no output schema, this leaves significant 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 a single, efficient sentence that front-loads the core purpose. It wastes no words, though it could be slightly more informative by elaborating on 'smart' or 'Taginfo-enhanced' without becoming verbose. The structure is clear but minimal.
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 (5 parameters including nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain the 'smart' aspect, output format, error handling, or how it differs from similar tools. For a search tool that likely returns structured data, more context is needed to guide effective use.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema—it mentions 'restaurants, shops, tourism, etc.' which loosely relates to the 'category' parameter, but doesn't provide additional syntax, format details, or examples. This meets the baseline 3 when schema coverage is high.
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 purpose: 'Smart POI search using Taginfo-enhanced queries for restaurants, shops, tourism, etc.' It specifies the action (search), resource (POIs), and enhancement method (Taginfo-enhanced). However, it doesn't explicitly differentiate from sibling tools like 'search_pois' or 'search_by_tags', which appears to be a similar POI search tool without the 'smart' enhancement.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_pois' or 'search_by_tags', nor does it explain what makes this 'smart' search different or preferable. There's no context about prerequisites, limitations, or typical use cases beyond the generic mention of POI categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search using structured address components
| Name | Required | Description | Default |
|---|---|---|---|
| street | No | Street name and number | |
| city | No | City name | |
| county | No | County name | |
| state | No | State or province | |
| country | No | Country name | |
| postalcode | No | Postal/ZIP code | |
| limit | No | Maximum number of results (1-100, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' but doesn't disclose behavioral traits such as what the search returns (e.g., geocoded coordinates, address matches), error handling, rate limits, or authentication needs. This is a significant gap for a search tool with no structured safety hints.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a tool with a clear name and detailed schema, avoiding unnecessary elaboration.
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 complexity of a search tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., geocoding results, matches), how results are structured, or any constraints, leaving the agent under-informed for effective use.
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 100%, with all 7 parameters well-documented in the input schema (e.g., 'street' as 'Street name and number'). The description adds no additional meaning beyond the schema, such as how parameters interact or search logic. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Search using structured address components' states the action (search) and resource type (address components), but it's vague about what exactly is being searched (e.g., addresses, locations, geocoding results). It doesn't distinguish from siblings like 'search_location' or 'reverse_geocode', leaving ambiguity about its specific domain.
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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'search_location', 'search_by_tags', and 'reverse_geocode', the description lacks any context about use cases, prerequisites, or comparisons, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snap coordinates to nearest road segments
| Name | Required | Description | Default |
|---|---|---|---|
| coordinate | Yes | [longitude, latitude] coordinate to snap | |
| profile | No | Routing profile (default: driving) | |
| number | No | Number of nearest roads to return (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('snap coordinates') but doesn't explain what 'snap' entails operationally—e.g., whether it modifies data, requires network access, has rate limits, or what the output looks like. For a geospatial tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that front-loads the core functionality without any wasted words. It's appropriately sized for a tool with a clear purpose and well-documented schema, making it easy for an agent to parse quickly.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It states what the tool does but lacks context on usage, behavioral details, or output expectations. With no annotations or output schema, more guidance would be helpful, though the high schema coverage provides some compensation.
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 100%, so the input schema fully documents all parameters (coordinate, profile, number) with descriptions and constraints. The description adds no additional parameter semantics beyond implying coordinate snapping, which aligns with the schema. This meets the baseline score of 3 when the schema does the heavy lifting.
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 purpose with a specific verb ('snap') and resource ('coordinates to nearest road segments'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'map_match_gps' or 'get_osrm_route', which might have overlapping functionality in mapping/geospatial contexts.
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 no guidance on when to use this tool versus alternatives. With many sibling tools related to routing, geocoding, and mapping (e.g., 'map_match_gps', 'reverse_geocode', 'get_osrm_route'), there's no indication of specific use cases, prerequisites, or comparisons to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate if an OSM tag combination is commonly used and get suggestions
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | OSM tag key | |
| value | Yes | OSM tag value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions validation and suggestions but lacks details on what 'commonly used' means (e.g., thresholds, data sources), whether it's a read-only operation, potential rate limits, or error handling. This is insufficient for a tool with no annotation coverage.
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, efficient sentence that front-loads the core functionality without unnecessary words. It directly communicates the tool's purpose, making it easy to parse and understand quickly.
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 validation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the validation entails (e.g., criteria, sources), what the suggestions include, or the format of results. This leaves significant gaps in understanding the tool's behavior and output.
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 100% description coverage, with clear definitions for 'key' and 'value' as OSM tag components. The description adds minimal value beyond this, as it doesn't elaborate on parameter usage, examples, or constraints. Given the high schema coverage, a baseline score of 3 is appropriate.
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 purpose: 'Validate if an OSM tag combination is commonly used and get suggestions.' It specifies the verb ('validate'), resource ('OSM tag combination'), and outcome ('get suggestions'). However, it doesn't explicitly differentiate from sibling tools like 'get_tag_stats' or 'get_tag_suggestions', which might offer related functionality, preventing a perfect 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as comparing it to sibling tools like 'get_tag_suggestions' or 'search_by_tags'. This lack of usage context leaves the agent with minimal direction.
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. Dates show when Glama detected each change.
calculate_isochroneexecute_overpass_queryfind_amenities_nearbyget_changesetget_changeset_diffget_distance_matrixget_elements_in_boundsget_osrm_routeget_place_detailsget_route_dataget_tag_statsget_tag_suggestionsmap_match_gpsoptimize_routeosmose_get_issue_detailsosmose_get_issues_by_countryosmose_get_issues_by_userosmose_get_itemsosmose_get_statsosmose_search_issuesreverse_geocodesearch_by_tagssearch_changesetssearch_highways_smartsearch_locationsearch_poissearch_pois_smartsearch_structuredsnap_to_roadsvalidate_osm_tagMost tools have distinct purposes, but there is some overlap that could cause confusion. For example, 'search_pois' and 'search_pois_smart' both search for POIs, and 'get_osrm_route' and 'get_route_data' both handle routing, though their descriptions differentiate them slightly. Overall, the descriptions help clarify boundaries, but agents might need to carefully choose between similar tools.
Tool names follow a highly consistent snake_case pattern with clear verb_noun structures, such as 'calculate_isochrone', 'execute_overpass_query', and 'search_location'. This consistency makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
With 30 tools, the count is on the high side for an MCP server, bordering on heavy. While OpenStreetMap is a broad domain, this many tools might overwhelm agents or indicate potential redundancy. It feels slightly excessive compared to well-scoped servers, but it's not extreme.
The tool set provides comprehensive coverage for OpenStreetMap operations, including geocoding, routing, data querying, quality assurance (OSMOSE), and tag management. It supports CRUD-like actions for OSM elements and changesets, with no obvious gaps that would hinder agent workflows in this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
Geocoding, truck routing, traffic, weather, and place search via MCP — 11 hosted tools.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
The Google Maps MCP server is a fully-managed server provided by the Maps Grounding Lite API that connects AI applications to Google Maps Platform services. It provides three main tools for building LLM applications: searching for places, looking up weather information, and computing routes with details like distance and travel time. The server acts as a proxy that translates Google Maps data into a format that AI applications can understand, enabling agents to accurately answer real-world location and travel queries.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GRABOSM/osm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server