Calculate the road toll for trucks on European roads. Supports all countries in Europe.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 2 of 2 tools scored.
The two tools are completely distinct: calculate_toll performs toll calculations, while get_quota checks API quota usage. There is no overlap or possibility of confusion.
Both tools follow a clear verb_noun pattern (calculate_toll, get_quota), providing a predictable and consistent naming convention.
With only 2 tools, the server is on the thin side, but the narrow domain of toll calculation justifies this. The primary tool is comprehensive, and get_quota is a useful utility. Slightly over-scoped would be adding unnecessary tools.
The calculate_toll tool covers the full lifecycle of toll calculation with multiple detail levels (basic, detailed, full) and supports many countries. There are no obvious missing operations within the stated domain, and get_quota covers the API quota aspect.
calculate_tollAInspectCalculate 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 15) | |
| 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 provided, the description carries the full burden of behavioral disclosure. It explains in detail what the tool returns, how detail levels affect the response, and even mentions the info_url for sharing. It does not explicitly state side effects or read-only status, but for a calculation tool this is less critical. The description adds significant behavioral insight beyond a simple summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence contributes useful information, especially around response fields and detail levels. It is front-loaded with the core purpose, then structured logically from general to specific. The length is justified by the complexity of the tool, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, 3 detail levels) and no output schema, the description is exceptionally complete. It fully describes the response structure, the meaning of each detail level, and even includes examples and URL behavior. This leaves the agent well-equipped to understand what the tool does and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters already well-described. The description adds some extra context for the 'detail' parameter by enumerating exact field differences at each level, and for origin/destination via examples. However, it does not add substantial new semantic meaning for most parameters beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Calculate European road toll costs for heavy trucks and commercial vehicles.' It names the resource (European road tolls) and the target audience (heavy trucks/commercial vehicles). This distinguishes it from the sibling tool 'get_quota', which is evidently about quota checking.
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 gives clear context for when to use the tool (toll calculation in Europe) and implicitly excludes other uses by specifying vehicle types. It does not explicitly mention the alternative 'get_quota', but the sibling is clearly unrelated, so the context is sufficient for an agent to select this tool for toll calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quotaAInspectCheck 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
