orbit

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

With no annotations, the description fully carries the behavioral disclosure burden. It explains the tool checks availability and includes prices, and describes the default behavior. Lacks details on error handling or response format, but sufficient for the tool's simplicity.

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, no fluff, well-structured with the action and important defaults 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?

Given the simplicity of the tool (2 params, no output schema), the description is fairly complete. It mentions slots, prices, and default room filtering. Could be improved by hinting at the return structure, but not necessary for basic use.

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% with each parameter described. The description adds value by explaining default behavior (all active rooms when roomIds omitted) and that prices are included, enhancing understanding 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 checks room availability for a given date, including slot types (morning, afternoon, full day) and standard prices. It distinguishes from siblings like create_booking (booking) and list_rooms (listing rooms).

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 when to use the tool (to check availability for a date) and notes the default behavior when roomIds are omitted. However, it does not explicitly provide when-not-to-use scenarios or compare to siblings.

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 provided, the description discloses key behaviors: creates a binding booking, reserves slots immediately, and requires authentication via API token. It does not detail error cases or persistence guarantees, but the core mutation action is well described.

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 and front-loaded. Every sentence adds essential guidance: purpose, prerequisites, process, and sibling differentiation. No fluff or redundancy.

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 11-parameter creation tool with no output schema or annotations, the description covers core aspects: prerequisites, input sources, and usage flow. It lacks details on return values and error handling, but overall it provides sufficient context for correct invocation.

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 description adds no extra semantic value beyond what the schema already provides. The schema's descriptions are thorough (e.g., 'Raum-IDs aus list_rooms'), so the description only minimally repeats this information.

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 creates a binding booking ('Erstellt eine VERBINDLICHE Buchung') with real conditions and immediate slot reservation. It distinguishes itself from the sibling 'request_booking' tool, which is for non-binding requests.

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?

Explicitly tells when to use: after checking availability with 'check_availability' and pricing with 'quote_booking'. It also states the prerequisite of an API token and provides the alternative 'request_booking' when no token is available. Room and service IDs are sourced from sibling tools 'list_rooms' and 'list_services'.

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 full burden. It discloses that future rooms are visible but not bookable, and lists the returned attributes. While it does not explicitly state read-only nature, the context clearly indicates a non-destructive operation.

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 that are front-loaded with purpose and packed with relevant details. No unnecessary words, and the second sentence adds an important behavioral nuance.

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 sufficiently explains the return content (capacity, floor, equipment, standard prices per time slot) and covers behavioral context (future rooms visibility). No critical gaps for a listing tool with one optional parameter.

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 only parameter (category) is fully documented in the schema. The description does not add extra meaning beyond what the schema already provides. With 100% schema coverage, baseline 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?

Title 'Räume auflisten' and description explicitly state listing active rooms with specific attributes (capacity, floor, equipment, standard prices per slot). Clearly distinguishes from sibling tools like check_availability or create_booking by focusing on room listing and static data.

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?

Description implicitly advises using this tool to obtain room details before booking, and highlights that rooms with future bookableFrom are visible but not yet bookable. However, it lacks explicit instructions on when to use this tool versus alternatives like check_availability.

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 adds behavioral info: services with isAccompaniment are exclusive and can trigger discounts. No destructive or auth details are needed for a read-only list tool.

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 short front-loaded sentences, each essential. No wasted 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?

Given no parameters and no output schema, the description sufficiently explains what the tool returns and a key behavioral constraint. It could mention pagination or order, but not necessary for a simple list.

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?

No parameters exist, schema coverage is 100%. The description adds meaning beyond schema by explaining the isAccompaniment field and its implications, which is useful context beyond the empty 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 it lists bookable additional services with examples (Catering, Moderation, etc.) and distinguishes from sibling tools like list_rooms. The verb 'Listet' and resource 'Zusatzservices' are specific.

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?

While no explicit when-to-use or alternatives are given, the purpose is so clear that usage context is evident. The description implies use when a list of services is needed, and siblings like check_availability or create_booking cover different actions.

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 responsibility. It discloses non-obvious behavior: best-price logic, weekend surcharge (+30%), catering flat rates, and personalization via API token (company pass or individual discount). This adds value beyond the schema.

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 a single paragraph of moderate length with front-loaded key information. It is efficient and avoids redundancy, though a more structured layout (e.g., bullet points) could improve scanability.

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 no annotations, the description provides sufficient context: it lists input sources (list_rooms, list_services), explains pricing logic, and mentions authentication/profiling. It is complete enough for an agent to invoke the tool without additional explanation.

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% with descriptions for each parameter, but the description adds relational context: room IDs come from list_rooms, service IDs from list_services, and that 'participants' is required for per-person catering (though schema allows null). This additional meaning helps the agent use parameters correctly.

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 an informal total price using the real pricing engine, including best-price logic, weekend surcharge, and catering flat rates. It differentiates from list_rooms by advising against manual calculation, making purpose specific and distinct 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 says to use this tool instead of manually calculating prices from list_rooms, and specifies that room IDs come from list_rooms and service IDs from list_services. While it lacks explicit when-not-to-use scenarios, the guidance is clear and action-oriented.

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 the full burden. It discloses the non-binding nature and that the team verifies and confirms via email. However, it does not mention any return value, error handling, or potential side effects (e.g., whether a request record is stored).

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 two concise sentences in German, front-loading the key concept (non-binding request) and immediately providing actionable guidance. Every sentence contributes essential information with no redundancy.

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 good coverage of prerequisites and purpose, the description omits what the function returns (e.g., a request ID, confirmation status). Since there is no output schema, the description should ideally explain the return value or success behavior. This gap reduces completeness.

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 adds value by explicitly stating that room IDs come from list_rooms and service IDs from list_services, and that price should be obtained via quote_booking. This contextualizes the parameters beyond their schema definitions.

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 a non-binding booking request ('UNVERBINDLICHE Buchungsanfrage') and explicitly distinguishes it from creating a confirmed booking. It references sibling tools like check_availability and quote_booking, providing context on the overall workflow.

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 instructs to check availability with check_availability and quote the price from quote_booking before requesting, and directs to list_rooms and list_services for IDs. However, it does not explicitly state when NOT to use this tool, leaving room for ambiguity.

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