swiss-road-mobility-mcp

Server Quality Checklist

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

Latest release: v0.5.4
Disambiguation5/5
Each tool targets a distinct aspect of Swiss road mobility: sharing, charging, traffic, counting, parking, classification, geocoding, and aggregated views. No two tools have overlapping purposes; even closely related tools (e.g., find vs search sharing, find vs status chargers) are clearly separated by their descriptions.
Naming Consistency4/5
All tools share the 'road_' prefix, which is good. However, the naming pattern is not uniform: some use verb_noun (find_sharing, classify_road) while others use noun_noun (sharing_providers, charger_status, traffic_situations). This slight inconsistency prevents a perfect score.
Tool Count5/5
With 15 tools, the server is well-scoped for its purpose—covering sharing, charging, traffic, counting, parking, classification, and geocoding. Each tool earns its place, and the count feels natural for the domain's breadth.
Completeness5/5
The tool surface appears complete for a read-only mobility data aggregation server. It covers all major phases (health check, search, status, planning, aggregation) and sub-domains, with no obvious missing operations like update or delete (which are out of scope).
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond annotations: it states 'No API key required – completely open data!' (authentication), 'Cache TTL: 5 minutes' (freshness), and explicitly describes the output as 'JSON with nearby Park & Rail facilities sorted by distance, including total spaces and capacity by category.' This complements the readOnlyHint and openWorldHint annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is adequately structured with the main purpose front-loaded, but it includes some extraneous elements like 'Phase 3 tool' and the French quote. While not overly verbose, it could be more concise by removing marketing language and focusing on essential operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return format and data source, but it omits crucial input details such as the required latitude/longitude parameters and optional radius/limit. Given the tool's moderate complexity (4 parameters, output schema), the description is incomplete for a user unfamiliar with the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% per context, the tool description must compensate by explaining parameters, but it does not. It only implies location ('near Swiss train stations') without mentioning latitude/longitude, limit, or radius_km. Users are left to infer from the tool's purpose, which is insufficient for a parameter-dependent search tool.
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 Park & Rail parking facilities near Swiss train stations.' It specifies the resource (Park & Rail facilities), the action (find), and the scope (near Swiss train stations, SBB-operated). This distinguishes it from siblings like road_find_sharing or road_find_charger, which serve different mobility needs.
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 by mentioning 'near Swiss train stations' and 'the link between road and rail,' but it does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling comparisons or 'use when' guidance is given, limiting the score to adequate but not great.
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?
Annotations already set readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds behavioral details: data is updated live, cache TTL of 2 minutes, and data source (ASTRA VMZ-CH). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured with clear sections: purpose, data source, complement info, requirements, details, and return format. Every sentence adds value, though some redundancy exists (e.g., data source repeated).
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?
The tool has 3 input parameters (though nested) and an output schema. The description adequately covers the return structure but lacks parameter details. Given the complexity and that output schema exists, it is reasonably complete but could include parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Context signals show schema description coverage is 0%, meaning the description does not explain the parameters. The description only lists return fields, not input parameters like 'limit', 'active_only', or 'filter_type'. With 0% coverage, the description should compensate but fails to do so.
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 starts with a specific verb 'Get' and resource 'current Swiss traffic events: accidents, roadworks, congestion.' It clearly states what the tool does and differentiates it from sibling 'road_find_sharing' by saying 'shows WHY a road is currently blocked.'
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 explicitly compares to 'road_find_sharing' to indicate when to use this tool: 'while road_find_sharing shows WHERE vehicles are available, this tool shows WHY a road is currently blocked.' It also mentions a prerequisite: 'REQUIRES: OPENTRANSPORTDATA_API_KEY environment variable.' However, it does not provide explicit when-not-to-use scenarios.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's safe. The description adds that it performs full-text search and returns JSON with locations and availability, but does not discuss rate limits, pagination, or other behavioral details.
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 with no wasted words: a clear purpose statement, scope, use case, example, and return format. Well-structured and front-loaded.
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 3 parameters, an output schema, and strong annotations, the description covers essential aspects: purpose, when to use, return format. It lacks parameter documentation but the schema fills that gap. Some missing details like pagination, but overall adequate.
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 description covers the search_text parameter implicitly by mentioning 'by name or address' and giving an example, but it does not detail limit or provider_id. The schema provides good descriptions for all parameters, compensating somewhat. Given 0% schema coverage according to context, the description should do more, but it partially meets the need.
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 searches for shared mobility stations by name or address, with a specific scope (Swiss stations). It distinguishes from siblings like road_find_sharing by focusing on name/address search rather than coordinates.
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 explicitly says it's useful when the station name is known but not the coordinates, providing clear context. However, it does not mention when not to use it or suggest alternative tools for other scenarios.
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?
Annotations already declare readOnly, idempotent, and nondestructive. The description adds behavioral context: it uses GWR-based registry, returns EGAID/EGID, and explains that missing addresses may not be officially registered. This enriches understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points, and front-loaded purpose. While somewhat lengthy, it earns its length by providing valuable context without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers return fields, data source, registry details, and usage tips. It is complete enough for an agent to understand and use the tool correctly, especially with the existing output schema.
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 has detailed parameter descriptions (in German), so baseline is 3. The tool description reinforces address format examples but does not add new parameter-specific information 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 tool converts Swiss addresses to GPS coordinates using the official federal registry. It uses specific verbs ('Convert') and distinguishes from general geocoders by emphasizing verified, legally registered addresses.
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 implies it's for Swiss addresses and notes it's a Phase 4 tool with no API key, but does not explicitly state when not to use or name alternatives like sibling tools. It gives contextual hints about data authority but lacks explicit exclusion criteria.
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?
Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable context: parallel aggregation of data sources, optional traffic data based on API key configuration, and the fact that no extra key is needed beyond Phase 2. This clarifies the tool's behavior beyond the annotations.
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 structured with a clear lead sentence, bullet-like list of aggregated items, usage context, data sources, and return format. Every sentence serves a purpose, and the length is appropriate for the tool's complexity. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, data sources, key requirements, optional features, and return shape (JSON fields). Given the tool's complexity and the presence of an output schema, the description provides sufficient context for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. While the schema has German descriptions, the tool description does not explain parameter meanings in English. It mentions radius for EV and sharing in the narrative but omits park_rail_radius and does not clarify that latitude/longitude are required. The description adds little value for understanding parameters.
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 aggregates multiple mobility data sources into one call, using specific verbs like 'Get a complete mobility picture' and listing all data types. It explicitly distinguishes from siblings: 'Instead of calling 5 different tools, get everything at once.'
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 recommends the tool for demos and comprehensive mobility queries. It implies use when a broad overview is needed, but does not explicitly exclude cases like single-source queries. The sibling tool names provide implicit alternatives, but the description could benefit from direct 'when not to use' 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?
Annotations already declare readOnly, idempotent, non-destructive. Description adds context: uses official federal register, returns EGID/EGAID, and is a Phase 4 tool. No contradictions.
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?
Well-structured with clear sections, bullet points for return data, and concise sentences. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations and output schema, description covers purpose, data source, return format, and use cases. Complete for a reverse geocoding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (context signal), meaning description does not describe input parameters. The tool description only mentions 'GPS coordinates' generically, not latitude, longitude, limit. Agent must rely solely on schema for parameter meaning.
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 uses strong verb 'Find' and specific resource 'nearest official Swiss addresses for given GPS coordinates'. Clearly distinguishes from sibling 'road_geocode_address' (address→coordinates vs coordinates→address).
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?
Description states useful application ('enriching mobility data') and notes 'Phase 4 tool – no API key required', but lacks explicit when-not-to-use or comparison to alternatives among siblings.
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?
Annotations already show readOnlyHint=true and non-destructive. The description adds valuable beyond-annotation context: data update every minute, cache TTL (site table 24h, measurements 1 min), and the need for an API key. This clarifies performance and dependency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear lead sentence, bullet-like details, and sections for use cases, requirements, and output fields. While slightly lengthy, the information is well-organized and front-loaded, ensuring key points are immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all necessary aspects: input requirements (latitude, longitude, radius), output fields (site_id, name, flow, speed), data source, update frequency, and API key registration. It is fully sufficient for correct 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 has well-described parameters with examples (e.g., 'latitude: 47.3769 for Zurich HB'). Since schema coverage is high, the description does not need to repeat them. However, it adds no additional meaning beyond 'finds nearby stations', earning a baseline 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 clearly states the tool returns real-time vehicle counts and speeds at Swiss traffic measurement stations. It emphasizes live, per-minute data and distinguishes from sibling tools like road_traffic_situations (incidents) and road_counter_sites (static station info) by focusing on real-time traffic flow.
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 explicit use cases (e.g., 'How busy is the A1 near Zurich right now?') and contextual details like data sources and update frequency. However, it does not explicitly mention when to avoid this tool or suggest alternatives, only implying it's best for real-time traffic queries.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. It adds value by describing the output (JSON sorted by distance, real-time status, plug types, power, operator) and noting the data source is open and free. No contradictions 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?
The description is well-structured with a brief intro, source attribution, analogy, and bullet-pointed return fields. It is concise yet informative, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in context signals), the description covers the essential aspects: data source, search capability, real-time status, and output fields. It is complete for a tool that finds chargers, including information about open data and no authentication.
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 description mentions parameters only indirectly (e.g., 'real-time availability' maps to include_details). The input schema itself has detailed descriptions for each parameter (range, examples, defaults). Since schema description coverage is 0% (meaning the top-level description doesn't list parameters), the tool description adds little beyond the schema's own 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 clearly states the tool finds EV charging stations near a location in Switzerland, specifies data source (ich-tanke-strom.ch), and includes key details like real-time availability, plug types, and charging power. The analogy to a car's navigation feature reinforces the purpose. It is well-differentiated from siblings like road_charger_status.
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 usage context: searching for nearby charging stations with open data. It mentions no API key required and real-time status. However, it does not explicitly differentiate from sibling tools like road_charger_status for checking a specific station's status, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds extensive behavioral context beyond annotations: it outlines the parallel workflow, lists data sources (with no API key required), describes the return format, and explains the process. Annotations already indicate readOnlyHint=true, and the description is consistent with that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a summary but is excessively verbose, repeating data sources twice and including a multi-step workflow that could be condensed. While structured, it contains unnecessary repetition, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multimodal planning with multiple data sources), the description covers all necessary aspects: input parameters, workflow, data sources, return format, and a use case. The output schema exists, so return values are further clarified. The description is complete for an agent to understand the tool.
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 provides detailed descriptions for each parameter (in German), including constraints and examples. The description does not add significant new semantic information beyond the schema; it only reinforces examples. Baseline 3 is appropriate given 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 clearly states that the tool plans a multimodal trip with a specific sequence (Drive → Park & Rail → Train → Destination). It distinguishes itself from sibling tools by emphasizing it combines all data sources into a complete door-to-door plan, and provides a concrete use case example.
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 includes a workflow and a use case ('I'm in Dietikon with a car...'), giving clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative sibling tools for simpler tasks, so it lacks complete exclusion criteria.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by specifying the return format (JSON with providers, vehicle types, app links) and geographic scope (Switzerland). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences and a bullet for return value. The analogy 'Like checking the About page' is helpful but adds a bit of extra text. Overall, it is front-loaded and efficient.
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 parameters and existing annotations, the description covers the purpose and output. It mentions the return format and scope. Since output schema exists (context signals), the description is sufficiently complete for this simple listing tool.
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?
Input schema has no parameters, so baseline is 4. The description does not need to explain parameters, and it adds no additional semantic value beyond what the schema provides (which is empty).
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 lists all shared mobility providers in Switzerland, using the verb 'List' and specifying the resource. It distinguishes from siblings like road_find_sharing and road_search_sharing which are for searching or finding specific providers.
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 implies this tool is for a broad overview of providers, like an 'About' page. However, it does not explicitly state when to use this vs. siblings (e.g., for specific searches or status checks). The context signals make it clear, but explicit guidance would improve it.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it returns real-time status (free/occupied/out of service) and that it covers all Swiss charging points. No contradictions. However, it could mention rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and well-structured, with a clear first sentence stating purpose. It uses bullet points for return values. Slightly redundant with schema but not excessive. Could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), the description sufficiently covers what the tool does, how to use it, and what results to expect. It mentions the output format (JSON with status categories) and workflow dependency (road_find_charger). No gaps observed.
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 provides a detailed description for the station_ids parameter, including an example and the default behavior (empty for overall statistics). The tool description does not add new parameter-level semantics beyond restating these two modes. Schema coverage is 0% by metric, but the schema itself is good, so the tool description adds minimal extra value.
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 explicitly states 'Check real-time availability of EV charging stations' and distinguishes two modes (specific IDs or overall statistics). It also references a sibling tool (road_find_charger) for obtaining IDs, clarifying the tool's role versus related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly advises 'Use road_find_charger first to get station IDs, then use this tool to check their current status.' This tells the agent when to invoke the tool and provides a clear worklow step. It also explains the two distinct use cases (specific stations vs. overall statistics).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds behavioral context by detailing the return format (JSON with road segments and specific fields like road name, type, surface, etc.) and data source (geo.admin.ch / swisstopo), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and emojis, front-loading the main purpose. It is slightly verbose but every sentence adds value, providing use cases and output details. Could be slightly more concise, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple classification dimensions), the presence of output schema (mentioned), annotations, and sibling tools, the description is complete. It covers purpose, data source, use cases, and return structure, leaving no major gaps for an AI agent to understand 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 provides detailed descriptions for all parameters (latitude, longitude, limit, tolerance) in German. The description does not add new meaning beyond listing the classification categories returned, but it does not repeat parameter details. With 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it classifies roads at a location using the official Swiss road network (swissTLM3D), listing specific categories like road type, functional class, surface, etc. It distinguishes from sibling tools, which focus on different functions (e.g., chargers, traffic, sharing).
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 explicit use cases (e.g., 'Is this a motorway or a local road?') and notes that no API key is required for Phase 4 tools. It does not explicitly state when not to use it, but the sibling tools cover different domains, making the context clear.
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?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by naming the specific endpoints tested and the return format (JSON with status), which goes beyond annotations without contradiction.
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 three sentences, front-loaded with the main purpose, followed by specific details and return format. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with 0 params, existing annotations, and an output schema, the description provides all necessary context: purpose, endpoints tested, and return type. It is fully adequate for agent use.
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?
No parameters exist, so schema coverage is 100%. The description adds context by explaining what the tool checks (endpoints), fulfilling the baseline expectation for a parameterless tool.
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 'Check the health of all road mobility data sources', specifies the endpoints (sharedmobility.ch, ich-tanke-strom.ch), and distinguishes from sibling tools like road_find_sharing or road_traffic_situations that serve different purposes.
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?
Explicitly states 'Useful for diagnosing connection issues', providing a clear use case. However, it does not include explicit 'when not to use' or direct alternatives, though the sibling list implicitly differentiates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavior: no API key required, data source (sharedmobility.ch), returns grouped JSON with availability and booking links. No contradictions with annotations.
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 well-structured, front-loading the purpose and using bullet points for the return value. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter object with 6 fields, all described in schema) and presence of output schema, the description fully covers necessary context: purpose, geographic scope, data source, real-time nature, and return format.
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 0% (description doesn't repeat parameter details). However, the input schema already has thorough descriptions for each parameter (latitude, longitude, pickup_type, etc.). The tool description adds no extra meaning beyond the schema, so baseline score 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 finds shared mobility vehicles and stations near a location in Switzerland, listing specific vehicle types (bikes, e-bikes, etc.) and comparing it to a mobility app. This distinguishes it from siblings like road_find_charger or road_search_sharing.
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 for checking nearby shared mobility options in Switzerland with real-time data. However, it lacks explicit when-not-to-use instructions or mention of alternatives like road_search_sharing for broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: 'without real-time data', 'site table cached for 24 hours (rarely changes)', and required API key. No contradiction with annotations.
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?
Description is concise (5 sentences) with clear structure: purpose statement, caching note, requirement, and bulleted return fields. Every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (simple list tool), with annotations and output schema, the description covers purpose, usage, behavioral notes, and return format comprehensively. No gaps.
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 0%, but the schema itself has adequate descriptions for parameters (latitude, longitude, radius_km, limit). The description does not add extra semantics for input parameters beyond what's in the schema; it focuses on output. Baseline 3 is appropriate as schema covers inputs sufficiently.
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 verb 'List', the resource 'Swiss traffic counting stations', and the scope 'near a location (without real-time data)'. It further distinguishes from sibling tools by mentioning this is to discover stations before querying road_traffic_counters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to discover available stations before querying road_traffic_counters', providing clear when-to-use and alternative. Also mentions caching duration and required environment variable for registration.
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:

[![swiss-road-mobility-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-road-mobility-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/swiss-road-mobility-mcp)

Score Badge

Copy to your README.md:

[![swiss-road-mobility-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-road-mobility-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/swiss-road-mobility-mcp)

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/malkreide/swiss-road-mobility-mcp'

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