orbit

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

No annotations are provided, so the description carries the burden. It does not explicitly state read-only behavior, permissions, or side effects. The description implies a non-modifying query, but lacks explicit transparency on safety or limits.

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 sentences, concise and front-loaded with the main purpose. Every word contributes to understanding the tool's function and behavior, with no redundancy or fluff.

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 simple two-parameter tool with no output schema, the description sufficiently explains what the tool does, what it returns (free slots and prices), and the effect of the optional parameter. No additional context is needed.

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?

Input schema has 100% coverage with descriptions for both parameters. The description adds value by explaining the default behavior when 'roomIds' is omitted (checks all active rooms), which is a meaningful extension beyond the schema's description.

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 the tool checks availability of slots (vormittag, nachmittag, ganztags) in rooms with standard prices for a given date. It distinguishes itself from sibling tools like list_rooms (listing rooms) and quote_booking/request_booking (booking actions) by being a read-only availability query.

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 explains the default behavior (all rooms when roomIds omitted) and implies use for checking availability before booking. However, it does not explicitly exclude other contexts or compare to siblings, but the clarity of purpose provides adequate guidance.

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

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

With no annotations, the description carries full behavioral disclosure. It clarifies the binding nature, token requirement, and immediate slot reservation. However, it could elaborate on error cases (e.g., invalid token) or confirmation behavior, but still provides adequate transparency.

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 concise with two substantial sentences that front-load the core purpose and prerequisites. Every sentence provides essential context without redundancy, making it highly efficient.

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 (11 parameters, no output schema), the description covers its purpose, prerequisites, and usage flow well. It lacks explicit mention of return value, but overall it is sufficiently complete for an agent to use effectively.

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 baseline is 3. The description adds value by explaining authentication prerequisites and referencing list_rooms/list_services for IDs, which goes beyond the schema's basic descriptions.

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 it creates a binding booking with real conditions, immediately reserving the slot. It distinguishes itself from sibling tools like check_availability, quote_booking, and request_booking, making the purpose crystal clear.

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 provides explicit guidance: use check_availability before, quote_booking for price, and request_booking if no token. It also mentions the required API token and where to create it, leaving no ambiguity about when to use this tool vs alternatives.

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

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

No annotations provided, so description carries burden. It discloses that future rooms are visible but not bookable, which adds behavioral clarity. No mention of read-only, but implied.

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 sentences: first enumerates return fields, second adds a critical behavioral note. No unnecessary words.

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?

Despite no output schema, description sufficiently explains return fields and the bookableFrom nuance, making it complete for a list tool.

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?

Only one optional parameter (category) with schema description coverage 100%. Description does not add extra meaning beyond the schema; it does not mention filtering by category.

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 it lists active rooms with specific attributes (capacity, floor, equipment, standard prices) and distinguishes from siblings by focusing on room info, not availability or booking.

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 implies when to use: to view room details. Siblings are distinct (check_availability, list_services, etc.), but no explicit when-not-to-use or alternative names given.

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

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

No annotations are provided, so the description carries full burden. It discloses that services with `isAccompaniment: true` are exclusive and can trigger a room discount, adding behavioral context beyond a simple list. However, it does not explicitly state that the tool is read-only, which is implied by 'listet' (lists).

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: the first states the main purpose and examples, the second adds an important behavioral nuance. No wasted words, front-loaded with the core function.

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, the description adequately explains the tool's return (list of services with prices and the `isAccompaniment` property). It could mention the output format (e.g., array of objects) but is sufficient for a simple list tool with sibling context.

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?

The input schema has zero parameters, and schema description coverage is 100%. The description does not need to add parameter details but provides value by explaining what the returned data includes (standard prices, `isAccompaniment` property). Baseline for 0 parameters is 4.

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 the tool lists all bookable additional services with standard prices, provides examples (catering, moderation, workshop accompaniment), and highlights a specific property (`isAccompaniment`). This distinguishes it from sibling tools like `list_rooms` or `check_availability`.

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 implies when to use the tool (to get a list of services before quoting or booking) but does not explicitly state when not to use it or name alternatives. It provides clear context for the tool's output but lacks usage exclusions.

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

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

With no annotations, the description fully discloses key behaviors: best-price logic, 30% weekend surcharge, catering flat rates, and personalization based on account discounts. This is comprehensive for a pricing tool, leaving no hidden 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?

The description is concise, with two sentences that front-load the core purpose and then add necessary context. No redundant information.

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 8 parameters, no output schema, and moderate complexity, the description covers the essential calculation logic and input sources. It does not describe the output structure, but for a pricing tool the focus on behavior is appropriate. Slight gap in output expectations.

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 parameters are already described. The description adds value by explaining where to find room and service IDs (list_rooms, list_services) and hints at the relationship between duration and start/end time constraints. However, it does not elaborate on individual parameters beyond the schema.

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 the tool calculates a non-binding total price using the real pricing engine, with specific details on logic (best price, weekend surcharge, catering). It distinguishes itself from manually calculating using list_rooms, effectively differentiating from siblings.

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 explicitly recommends using this tool instead of manually computing prices from list_rooms. It provides context on when personalization occurs (with API token) and where to obtain room/service IDs. However, it does not explicitly state when NOT to use it, such as for binding quotes.

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

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

The description highlights key behavioral traits: the request is non-binding, does NOT reserve the slot, the team reviews it, and confirmation is sent via email to the contact address. Since no annotations are provided, this clarity is essential.

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 minimal yet complete: two sentences plus a cross-reference to sibling tools. Every sentence adds unique value and the key point (non-binding) is front-loaded.

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?

Despite no output schema, the description covers prerequisites, parameter sourcing, and result (email confirmation). However, it does not specify what happens if the request fails or the format of the response status. Given the tool's simplicity, it is nearly complete.

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%, but the description adds significant context: room IDs from list_rooms, service IDs from list_services, and for multi-day durations all rooms book GANZTAGS. It references external tools and explains behavioral constraints beyond the schema.

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 the tool makes an 'UNVERBINDLICHE Buchungsanfrage' (non-binding booking request) to the Orbit-Team. It explicitly distinguishes itself from siblings like check_availability, quote_booking, list_rooms, and list_services by advising to use them for prerequisites.

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 provides explicit guidance: 'Prüfe vorher mit check_availability, ob die gewünschten Slots frei sind, und nenne dem Menschen den Preis aus quote_booking.' It tells when to use this tool (after checking availability and quoting) and implies not to use it for checking or quoting.

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