Skip to main content
Glama

Dodávky Znojmo

check_availability

Zkontroluje dostupnost vozidel v zadaném období a spočítá celkovou cenu pronájmu včetně DPH 21%. V ceně je zahrnuto 500 km/den, nadlimit 3,50 Kč/km.

Input Schema

NameRequiredDescriptionDefault
toYesDatum konce pronájmu (YYYY-MM-DD)
fromYesDatum začátku pronájmu (YYYY-MM-DD)
vehicle_idNoID konkrétního vozidla (nepovinné)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does add real value by disclosing the pricing rules (21% VAT, 500 km/day included, 3.50 CZK/km over-limit), but it never states that the call is read-only, what the response contains, or whether the quoted price is per vehicle or aggregate.

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 tight sentences with the core capability front-loaded and the pricing policy following as supporting detail. Nothing is redundant or padded.

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, the description should clarify what 'dostupnost' returns — a boolean, a list of available vehicles, or a price quote — especially given the optional vehicle_id. It is adequate for a simple check but leaves the return shape and the no-vehicle_id behavior ambiguous.

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% and all three parameters are documented in the schema, so the baseline is 3. The description's mention of 'zadaném období' loosely maps to from/to but adds no format or semantics beyond what the schema already provides, and it says nothing about what happens when vehicle_id is omitted.

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 states a specific verb and resource: it checks vehicle availability for a given period and computes the total rental price including 21% VAT. That is clearly distinct from create_booking, get_fleet_info, and calculate_load_compatibility, though the description never names a sibling to reinforce the distinction.

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?

Usage is only implied — 'v zadaném období' suggests this is the pre-booking availability/price check, but the description never says when to use it instead of create_booking or get_fleet_info, nor does it state any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources