TollCalc MCP
Server Details
Calculate the road toll for trucks on European roads. Supports all countries in Europe.
- Status
- Healthy
- Uptime
- 99.8% over 66 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2024-11-05
- URL
TDQS
Scored across 2 tools
calculate_toll performs route toll computation while get_quota reports session quota — two entirely separate purposes with no overlap. An agent cannot reasonably confuse them.
Both tools follow a clean verb_noun snake_case pattern (calculate_toll, get_quota). Fully predictable and consistent.
Two tools is thin for a server covering 40+ countries and a rich calculation domain; helper operations like listing supported countries or validating vehicle parameters have no entry point. The single calculation tool is powerful, but the surface feels minimal.
calculate_toll covers the core domain thoroughly with tiered detail levels, including segments, geometry, and formula traces. Minor gaps exist: no tool to enumerate supported countries/toll schemes or to validate vehicle/weight/axle inputs before a call.
Available Tools
2 toolscalculate_tollAInspect
Calculate European road toll costs for heavy trucks and commercial vehicles. Supports 40+ countries. Response fields (all detail levels): origin, destination (resolved place names), total_toll_eur (float), total_distance_km, toll_km, toll_free_km, countries (array with country, country_name, total_km, toll_km, toll_eur), info_url (link to view this route calculation in the TollCalc web app, including the planned route on an interactive map — share with colleagues or open in browser). With detail=detailed: countries also include segments (road, type, km, toll_eur). With detail=full: segments also include geometry, source_url, matched_geofence, formula_vars (all resolved formula variables: km, road_type, weight, axles, emission_class, co2_class, computed rate variables like tollRate, weightAxleClass, effective rate per km), and lookup_trace (all table lookups performed during calculation with their results); origin/destination include lat/lon coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| via | No | Optional intermediate waypoints (max 498; origin + via + destination must not exceed 500) | |
| detail | No | Response detail level. compact (default): total + per-country summary. detailed: adds per-segment costs without geometry. full: adds routing debug info and geometry. | compact |
| origin | Yes | Start point: city/address (e.g. 'Munich, Germany') or 'lat;lon' (e.g. '48.1374;11.5755') | |
| vehicle | Yes | Vehicle parameters | |
| destination | Yes | End point: city/address or 'lat;lon' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and substantially does so by enumerating response fields for all detail levels, including country summaries, segments, geometry, formula variables, and lookup traces. It does not, however, discuss side effects, auth requirements, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded, and the long response-field enumeration is justified because there is no output schema. The dense prose could be more structured with bullets, but every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested vehicle object, five parameters, and no output schema, the description supplies detailed return-shape information across compact, detailed, and full modes. An agent can call this tool and understand what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the effect of the detail parameter on the response, but adds no syntax or constraints beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Calculate European road toll costs for heavy trucks and commercial vehicles', with scope '40+ countries'. This clearly distinguishes it from the only sibling, get_quota, which is unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but gives no explicit when-to-use, when-not-to-use, prerequisites, or alternatives. Since the only sibling is unrelated, the omission is less harmful, but the guidance is still absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quotaAInspect
Check remaining free-tier quota for this MCP session. Without authentication, 10 free requests are available per session. Pass an API key via Authorization: Bearer header for plan-based quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that without authentication, only 10 free requests are available per session, and that passing an API key changes behavior to plan-based quota. This is beyond what annotations (none) provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then key usage details. Every sentence is informative and no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description covers the essential context: what it does and authentication impact. Lacks output format but sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description cannot add meaning beyond the schema. However, it explains the return concept (quota info) without detailing format. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Check remaining free-tier quota for this MCP session', which is a specific verb-resource pair. It clearly distinguishes from the sibling tool 'calculate_toll' by focusing on quota.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: to check quota. Also explains authentication requirements and the difference between free and plan-based quota, guiding the agent on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
calculate_toll1 field changed- changed
Input schema / properties / via / descriptionPrevious value: -"Optional intermediate waypoints (max 48; origin + via + destination must not exceed 50)"New value: +"Optional intermediate waypoints (max 498; origin + via + destination must not exceed 500)"
1 tool update
- Changed
calculate_toll1 field changed- changed
Input schema / properties / via / descriptionPrevious value: -"Optional intermediate waypoints (max 15)"New value: +"Optional intermediate waypoints (max 48; origin + via + destination must not exceed 50)"
2 tool updates
- First observed
calculate_toll - First observed
get_quota
Related MCP Servers
- AlicenseNot gradedqualityBmaintenancePerplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.2Apache 2.0
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs119 npmMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.164 npm1MIT

industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.