Calculate the road toll for trucks on European roads. Supports all countries in Europe.
Scored across 2 tools
The two tools serve completely different purposes: calculate_toll performs route cost computation, while get_quota reports session quota. There is no realistic way to confuse one for the other.
Both tools follow the same snake_case verb_noun pattern (calculate_toll, get_quota), giving a predictable and consistent naming scheme.
Two tools is thin for a server covering toll calculation across 40+ countries; useful auxiliary operations like listing supported countries or validating vehicle parameters are absent, though the single calculation tool does carry substantial capability via detail levels.
The core lifecycle—compute a toll route and check remaining quota—is covered, including rich detail levels and an info_url for follow-up. Minor gaps exist (no country/vehicle metadata lookup or batch calculation), but agents can work around them.
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 48; origin + via + destination must not exceed 50) | |
| 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' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden, and it does so well for outputs: it enumerates every response field and exactly what each detail level adds, including geometry, lookup traces and formula variables. It omits operational behavior such as auth requirements, rate limits, or failure modes for unsupported routes, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in one sentence, followed by a dense but justified field inventory that substitutes for the missing output schema. There is mild redundancy where the detail=detailed/full semantics restate the schema's own descriptions, but no filler sentences overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a nested vehicle object, the description supplies the return-value structure that would otherwise be missing, covering all detail levels and nested segment fields. What remains absent (auth, error handling) is secondary for a read-style cost estimator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by spelling out what 'detailed' and 'full' actually return (segments, geometry, source_url, matched_geofence, formula_vars, lookup_trace) and by noting that origin/destination gain lat/lon at full detail — information the terse schema descriptions do not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource ('Calculate European road toll costs') and narrows scope to heavy trucks/commercial vehicles across 40+ countries. The only sibling, get_quota, is functionally unrelated, so no meaningful disambiguation is required. An agent can immediately tell what this tool produces.
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?
Usage is implied rather than stated: the tool clearly belongs to toll-cost estimation, but there is no explicit 'use this when…' clause, no exclusions (e.g. non-European routes, passenger vehicles), and no prerequisites or limits. The detail-level explanation partially guides parameter choice but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_toll1 field changedInput schema / properties / via / descriptionPrevious value: -"Optional intermediate waypoints (max 15)"New value: +"Optional intermediate waypoints (max 48; origin + via + destination must not exceed 50)"calculate_tollget_quota
Add one secure layer between your agents and this server.