myosm-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Several tools overlap in purpose, particularly find_nearby_places, explore_area, and analyze_neighborhood, all of which provide comprehensive amenity profiles around a location. While descriptions hint at differences (e.g., scores for livability), an agent could easily select the wrong one. Other specific searches (parking, schools, EV stations) are clearly distinct.
Naming Consistency4/5
Tool names consistently use lowercase snake_case with a verb_noun structure (find_*, get_*, analyze_*, etc.). The only minor deviation is 'reverse_geocode' which is a standard term, and no camelCase or mixed conventions appear. Overall, the pattern is predictable and readable.
Tool Count4/5
With 16 tools, the server is slightly above the typical 3-15 range but still reasonable for a broad OSM-based location service. Each tool covers a distinct aspect of geographic data (search, routing, utilities, transport), so the count feels appropriate rather than bloated.
Completeness4/5
The tool surface covers geocoding, reverse geocoding, POI search, routing, neighborhood analysis, map tiles, and specialized infrastructure queries (power, EV, public transport). Minor gaps exist, such as a direct tool for fetching OSM object details by ID, but core workflows are well-supported and no critical dead ends are apparent.
Average 4/5 across 16 of 16 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full transparency burden. It describes the expected output organization but provides no information on side effects, data source, performance, limits, or whether any authentication is required. This is insufficient for a tool that aggregates 'all amenities and features'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler. It front-loads the purpose, then specifies output structure and center address, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description partially compensates by describing output contents and categories, and all three parameters are fully documented in the schema. However, it remains incomplete as a standalone contract because it lacks usage guidance and does not state boundaries such as maximum radius or result limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it reinforces that latitude/longitude define the 'center point' and that the search is 'around a point', but it does not add details about radius behavior or units beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Generate a comprehensive profile of an area' with specific output details ('all amenities and features... organized by category and subcategory, plus the address of the center point'). This distinguishes it from more targeted sibling tools like find_nearby_places or search_category by emphasizing comprehensiveness and categorization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description implies a general 'explore an area' use case, but it does not mention any exclusions, prerequisites, or comparisons with sibling tools like analyze_neighborhood or find_nearby_places.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It discloses that results are grouped by OSM category and subcategory, which is a behavioral trait. However, it doesn't mention defaults, boundary conditions, or response format, leaving gaps for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no filler. Each sentence adds value: the first states the purpose, the second states the grouping and use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description hints at return structure via grouping but doesn't fully cover behavior or distinction from many nearby sibling tools. It's adequate but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no additional parameter-specific meaning beyond the schemas already provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Discover points of interest and amenities near a specific location' with a specific verb and scope, and mentions OSM category grouping. It doesn't explicitly contrast with sibling tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'useful for location-based recommendations and proximity-based decision making' gives an implied usage context but no explicit when-to-use or comparison against sibling tools like explore_area or search_category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool compares modes and returns directions, but it does not mention limitations, error handling, possible time-sensitivity, or operational constraints. For a read-only analysis tool, this is a minimal disclosure and leaves significant ambiguity about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no redundant phrases. It front-loads the core action and enumerates key output components, making it easy to parse and efficiently using the available space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, but the description effectively communicates the essential behavior and output fields. It does not explain optional parameters like 'depart_at' or how the modes array affects the analysis, but these are already defined in the schema. Given the moderate complexity and strong schema coverage, the description is sufficiently complete for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are already described in the input schema. The tool description does not add any additional parameter semantics or clarify relationships between parameters, but it also does not detract from the schema's clarity. A baseline score of 3 is appropriate since the structured data does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Perform') and identifies the resource ('commute analysis between home and work locations'), clearly distinguishing it from sibling tools like get_route_directions by emphasizing multi-mode comparison. It also enumerates the key output components (distances, durations, turn-by-turn directions), making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a commute-specific use case (between home and work) but does not explicitly state when to use this tool compared to alternatives like get_route_directions. It provides no exclusions or guidance on when a simpler routing tool would be more appropriate, so the usage context is only partially clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does mention that results are 'sorted by distance' and that filtering is optional, which adds some behavioral context. However, it does not disclose the return format, pagination limits, any maximum radius, or other operational details. The description is honest but not rich in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the verb and resource, then additional qualifiers. It contains no redundant phrases or filler, delivering maximum information in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema, no annotations), the description adequately covers the tool's purpose and key filtering/sorting behaviors. It does not explain what the returned data looks like, but for a straightforward geospatial search tool this is a minor gap. The description is complete enough for an agent to select and use the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all four parameters clearly defined. The description adds minimal new meaning: it acknowledges the 'education_levels' parameter as an optional filter and introduces 'sorted by distance' as an output trait, but the schema already covers the purpose and constraints of each parameter. The description does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Locate') and the resource ('educational institutions') with a specific scope ('near a location') and additional options ('filtered by education level, sorted by distance'). It distinguishes the tool from sibling tools like find_parking_facilities and find_public_transport by focusing on schools and educational institutions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (finding schools near a point with optional filtering), but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. There is no mention of sibling tools or scenarios where another tool would be more appropriate, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the output structure (list of matches with coordinates, formatted address, admin boundaries, OSM type/ID, bounding box, importance ranking) which is helpful, but it does not mention potential edge cases such as ambiguous addresses, multiple matches, or failure behavior. The description gives a reasonable but not exhaustive view of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and quickly enumerates the key output fields. Every clause adds meaningful information without redundancy or rambling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema. The description sufficiently explains the tool's purpose and return values, making it complete for most use cases. A minor gap is that it doesn't mention how multiple matches are ranked or potential limitations, but given the tool's simplicity, this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a detailed description for the 'address' parameter, so the baseline is 3. The tool description adds minimal additional semantic value beyond the schema, though it does confirm that the address can be a place name or landmark. The schema already provides examples, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Convert') and clearly identifies the resource (an address or place name) and the outcome (geographic coordinates). It also enumerates the detailed location information returned, effectively distinguishing this from sibling tools like reverse_geocode which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case (geocoding an address) but does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tool would be more appropriate for reverse geocoding or place discovery. However, the context is clear enough for a competent agent to infer the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose what the output will contain (administrative hierarchy, postal code, OSM metadata), which gives some insight into behavior. However, it does not mention potential errors, rate limits, data source specifics, or that this is a read-only operation. The description adds useful context about output contents but lacks depth on limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Convert') and clearly states the input and output. Every phrase contributes to understanding the tool, with no filler or repetition. It is appropriately concise for the tool's straightforward functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description partially compensates by listing key output fields (address, administrative hierarchy, postal code, OSM metadata). For a tool with only two parameters, this gives sufficient context for basic usage. However, it omits the exact return format and any edge-case behavior (e.g., invalid coordinates), but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, already explaining latitude and longitude as decimal degrees in WGS84. The description adds no additional parameter semantics beyond the overall purpose, so it does not enhance what the schema already provides. Baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Convert' and identifies the resource 'geographic coordinates' and the output as a 'detailed address and location description'. It explicitly lists output components (administrative hierarchy, postal code, OSM metadata), which distinguishes it clearly from sibling tools like geocode_address, which performs the opposite direction. This makes the tool's purpose immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have coordinates and need an address, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or comparison to sibling tools such as geocode_address. The context is clear but the guidance is implicit rather than explicit, so it stops short of a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output nature (scores for categories) but does not mention safety (read-only), data sources, or limitations. The description adds some behavioral context but lacks details about how the analysis is performed or potential caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, well-structured and front-loaded. The first sentence states the core functionality and outputs; the second gives a practical use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by enumerating the output categories (amenities, transportation, green spaces, services, walkability, overall score). It covers the main aspects of the tool's behavior, though it could mention how to interpret scores or what to expect if data is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter (latitude, longitude, radius) is already clearly described in the JSON schema. The tool description adds no additional parameter-level information, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Generate') and resource ('neighborhood livability analysis'), plus details about outputs (per-category scores, walkability, overall score). It distinguishes itself from sibling tools by emphasizing analysis and scoring rather than listing places or routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Useful for real estate decisions and relocation planning'), implying when to use it. It does not explicitly name alternative tools or exclusions, but the context is sufficient for an agent to make a basic choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses sorting by distance, optional line geometry, and the ability to include more types. However, it omits behavior like default power_types, potential data incompleteness, or response size implications, making it adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource. Every sentence earns its place, covering purpose, key return elements, optional parameters, and sorting behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description adequately covers the return content (voltage, circuits, operator, geometry), sorting, and extension mechanisms. It could mention pagination or response limits, but the given detail provides a solid overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds valuable context for power_types (listing examples like towers/poles) and include_geometry ('optional line geometry'), but it does not fundamentally enhance understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and names the resource 'electricity grid layer' with enumerated components (power lines, underground cables, substations, transformers). This clearly distinguishes it from sibling tools like find_power_plants or find_ev_charging_stations, which operate on different infrastructure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the query context ('around a location') and provides guidance on extending results via power_types for additional element types. However, it does not explicitly name alternatives or when-not-to-use cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that it filters by category/subcategory and returns coordinates, names, and metadata, which is useful. However, it does not mention potential limitations like bounding box size constraints, OSM data staleness, or behavior when no results are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by filtering and return details. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use case, return contents, and filtering semantics. Given that it's a search tool with 6 parameters and no output schema, it is reasonably complete even without capturing edge cases like pagination or max area. The absence of alternative-tool guidance is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with 100% coverage. The description adds context by explaining how the parameters relate (category + subcategories filtering within a rectangular area) but does not add significant detail beyond the schema. A baseline 3 is appropriate when schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for specific types of places within a rectangular geographic area, using OSM category and optional subcategories. This specific verb-resource-scope combination distinguishes it from siblings like find_nearby_places (likely radius-based) and explore_area (likely broader).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description effectively implies when to use this tool: when you need places by OSM category within a bounding box. It does not explicitly state alternatives or exclusions, but the rectangular-area formulation and category-filtering provide clear contextual guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the tool 'computes the central point' and 'recommends nearby venues', which are read-only behaviors. However, it doesn't disclose edge cases like no venues found or how 'optimal' is determined, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a colon separating the primary action from the supporting detail. Every word earns its place; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description reasonably explains what the tool returns ('recommends nearby venues') and the core algorithm. It lacks details on return format or failure handling, but for its simplicity and clear schema coverage, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, including descriptions for locations and venue_type with examples. The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find the optimal meeting place for multiple people coming from different locations' and distinguishes it from siblings like find_nearby_places by emphasizing the central point computation for multiple locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when multiple people come from different locations and you need a meeting point with a venue type. It does not explicitly name alternative tools or exclusion criteria, but the scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions key behaviors beyond the bare operation: results are sorted by distance, and filtering is optional. It is a read-only search tool, so there are no destructive side effects to disclose. However, it does not mention radius usage or return format, which are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action and resource, then appends filtering and sorting details. Every word contributes meaning; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool with 5 parameters and no output schema, the description covers the primary operation, filtering options, and sort order. It does not explain the result structure, but the purpose is clear enough for an agent to invoke it correctly. The absence of output schema is partially mitigated by the description's clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds marginal value by phrasing 'optionally filtered by connector type and minimum charging power', reinforcing the optional nature of those parameters. It does not add new syntax or clarify units beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Locate') with a clearly scoped resource ('electric vehicle charging stations') and adds filtering and sorting criteria. This clearly distinguishes it from siblings like find_parking_facilities or find_nearby_places, which cover different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: it is for finding EV charging stations near a location, with optional filtering by connector type and power. It does not explicitly name alternatives or mention when not to use it, but the specificity of the resource makes the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 behavior. It reveals that results include capacity, fee, and access information, and are sorted by distance, which is valuable behavioral context. It does not cover pagination or error cases, but these are not critical for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that packs essential information without redundancy. It front-loads the main verb and resource and includes valuable detail about the results, scoring a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward search with two required parameters, a fully documented schema, and a description that specifies what information is returned and how it's ordered. Although no output schema is present, the description compensates by naming result fields, making the description sufficiently complete for AI invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with 100% detail, including units, defaults, and types. The description adds little beyond confirming the location context and result attributes, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Locate' with the resource 'parking facilities', enumerating types (lots, garages, street parking) and key output attributes (capacity, fee, access) and sorting by distance. This clearly distinguishes it from broader sibling tools like find_nearby_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when the user needs parking facilities near a location, and the context of 'near a location' with distance sorting is stated. However, it does not explicitly mention when not to use it or alternatives, so it loses one point for lacking explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: returns both plants and generators, sorted by distance, and filterable. It also lists the reported attributes. It doesn't explicitly state read-only-ness, but 'Locate' and 'Reports' imply it. Minor gaps like the exclusion of facilities without output when min_output_mw is set are handled in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. It spends only two sentences to convey purpose, scope, output fields, sorting, and filtering, without redundantly repeating schema information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter read-only tool with no output schema, the description is well-rounded: it specifies the search subject (plants and generators), the key return fields (energy source, method, electrical output, operator), and behavioral details like sorting and filtering. Defaults and limits are left to the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds no new parameter-specific semantics beyond what the schema already provides; it only mentions 'filterable by source and minimum output' which is already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'locate[s] electricity production facilities' and explicitly differentiates between power plants and standalone generators, which distinguishes it from siblings like find_power_infrastructure. The verb 'Locate' plus specific resource types makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the tool searches around a location and can be filtered by energy source and minimum output. It doesn't explicitly mention alternatives or when not to use it, but the use case is well-defined and obvious for users needing power generation facilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: results are sorted by distance, the included transit modes, and the returned fields (ref, operator, network, origin, destination). It does not mention side effects, but as a query tool the read-only nature is appropriately implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the purpose and efficiently lists all relevant output details. Every clause adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the high-level return contents (stops, routes, modes, fields). It omits details about the exact response structure and edge cases, but for a query tool with a well-defined schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about sorting and output content but does not explain parameter semantics beyond what the schema already provides. No additional value is needed, but none is really given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and identifies the resource ('public transport layer') while enumerating the returned elements (stops, stations, platforms, terminals, route lines). It clearly distinguishes from siblings like find_parking_facilities and find_nearby_places by its transit-specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys that this tool is for querying public transport around a location, making its context obvious. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (PNG tile plus metadata and attribution) and the API key requirement for certain styles, which is valuable contextual behavior beyond the schema. It does not mention rate limits or error scenarios, but the key disclosures are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficiently front-loaded: it starts with the core purpose, then lists styles and key requirements, and ends with the output. Every sentence adds value, with no redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no output schema, and no annotations, the description covers the essential aspects: purpose, parameter semantics for style, authentication requirements, and return type. It lacks explicit error handling or prerequisites beyond the API key, but is otherwise complete for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with 100% description coverage, giving a baseline of 3. The tool description adds extra meaning to the style enum by explaining each style's source and whether a key is needed, which goes beyond the schema's simple description of 'Map style / layer to render'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a rendered map tile as an image, using specific verb 'Fetch' and resource 'map tile'. It is distinct from sibling tools that focus on places, geocoding, or routes, and explicitly mentions the map layer viewing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (view a map layer as an image) and gives style-specific guidance (which styles require the Thunderforest API key). It does not explicitly exclude alternative tools or name alternatives, but the context is sufficient for an agent to differentiate from spatial data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses what the tool returns (summary, turn-by-turn, geometry, waypoints) and how to control response size via steps/overview/annotations. This goes beyond the input schema and gives useful behavioral context, though it could mention error handling or route availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and outputs, and ends with actionable parameter guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers the core purpose, outputs, and response size controls. It could be more complete by mentioning potential limitations (e.g., no route found, coordinate validity), but for this complexity level it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explicitly stating that steps/overview/annotations control the response size, which is semantic guidance not present in the schema descriptions. This raises the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates route directions between two geographic points using OSRM, with specific outputs (summary, turn-by-turn, geometry, waypoints). It differentiates itself from sibling tools like find_nearby_places or geocode_address by focusing on route calculations between points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for any point-to-point route calculation scenario. It does not explicitly name alternatives or when not to use it, but the context is unambiguous and distinct from sibling tools. This qualifies as clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![myosm-mcp-server MCP server](https://glama.ai/mcp/servers/visuelconcept/myosm-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/visuelconcept/myosm-mcp-server)

Score Badge

Copy to your README.md:

[![myosm-mcp-server MCP server](https://glama.ai/mcp/servers/visuelconcept/myosm-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/visuelconcept/myosm-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/visuelconcept/myosm-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server