seat-intelligence

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

With no annotations, the description carries full burden. It discloses the return format (scores, notes, dimensions, recommendation), which is adequate for a read-only comparison tool. No side effects or permissions are mentioned, but none are expected.

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 defines the tool's action and outputs, second gives a usage example. Every sentence adds value; 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?

Given no output schema, the description adequately covers return values. The three parameters are explained in the schema. Sibling tools provide context for when to use alternatives. Minor gap: no mention of required preconditions like 'same aircraft side.'

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 each parameter having a basic description. The tool description adds contextual meaning (e.g., 'comparison of two seats on the same aircraft side by side') and examples like '14A' and '22F', going 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 specifies a unique verb ('compare') and resource ('two specific seats on the same aircraft side by side'), with clear output types (scores, notes, dimensions, recommendation). It distinguishes from siblings like 'rowhint_get_best_seats' which returns best seats overall.

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?

Explicit usage context is provided: 'Use when someone asks "Should I pick 14A or 22F on the Southwest 737 MAX 8?" or is deciding between two seats.' While not listing when not to use, the sibling tools imply alternatives for other seat-related queries.

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 the description must carry the burden. It only states 'Find the highest-rated seats' without explaining how ratings are determined, if any mutations occur, or any other behavioral traits like auth or rate 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?

The description is two sentences plus example usage, front-loading the core purpose. Every sentence adds value without waste.

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 tool with 3 parameters and no output schema, the description covers the basic purpose and usage. However, it lacks detail on what 'highest-rated' means or the output format, leaving some gaps.

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 repeats the filter possibilities (cabin class, limit) from the schema but adds no new semantic meaning beyond that.

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 finds highest-rated seats on a specific aircraft configuration, with a clear verb+resource. It also provides example queries that distinguish it from sibling tools like seat scoring or picking.

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 'Use when someone asks...' with concrete examples, providing clear usage context. However, it does not mention when not to use or alternatives among 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?

No annotations provided, so the description carries full burden. It describes the tool as a read operation ('Get a summary'), but doesn't discuss safety, idempotency, authorization requirements, or any side effects. More detail on behavioral traits would be beneficial.

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 well-structured sentences: the first defines purpose and output, the second gives usage context and secondary function. No unnecessary words, front-loaded with critical info.

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 three optional parameters, the description lists the key outputs (seats, cabin layout, facilities) and usage scenarios. It could mention response format or edge cases, but overall it's sufficient for the tool's straightforward nature.

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% (all three parameters have descriptions). The description adds one extra piece: that config_id takes precedence if both airline/aircraft and config_id are provided. This is useful but doesn't go beyond the schema substantively.

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 retrieves a summary of an aircraft configuration, listing specific details (total seats, cabin layout, best/worst seats, facility locations). It distinguishes from sibling tools by emphasizing it's for a general overview before seat selection, while siblings focus on comparisons, best seats, scores, etc.

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 says to use when someone asks about a specific aircraft or wants a general overview before seat choice, and also to discover valid config_ids. It lacks explicit 'when not to use' scenarios, but the guidance is clear and helpful.

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 exist, so the description carries the full burden. It lists return contents (comfort assessment, recline data, etc.) but does not disclose whether the operation is read-only, has authentication requirements, or side effects. The description is adequate but could explicitly state safety and read-only 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?

Two sentences with no wasted words. The first sentence states function and return contents; the second gives a concrete use case. Efficient and well-structured.

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 two simple parameters, no output schema, and no annotations, the description provides sufficient context to understand the tool's purpose and expected input. It lacks explicit output structure but covers key information categories. It is largely complete for its complexity.

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 baseline is 3. The description adds no further meaning to the parameters beyond what the schema descriptions already provide ('seat' and 'config_id' are clearly defined in schema). Thus it does not enhance parameter understanding.

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 has a specific verb ('Get') and resource ('quality score... for a specific airline seat'). It lists specific return contents and distinguishes from sibling tools like rowhint_get_best_seats and rowhint_compare_seats by focusing on a single seat's detailed evaluation. The concrete example reinforces purpose.

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 states when to use it: when someone asks about a specific seat's quality or wants to know before booking. While it doesn't list when not to use or provide alternative sibling names, the usage scenario is clear and contextually appropriate.

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 burden. It clearly explains the tool's behavior (returns seats labeled as window seats that lack actual windows) and adds context about airline booking systems and fuselage structure, but does not mention output format or potential side effects (though none expected).

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 sentences with zero wasted words. First sentence states the core function, second sentence clarifies intended usage. Information is front-loaded and each sentence earns its place.

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 simplicity (one parameter, no output schema, no annotations), the description is largely sufficient. It explains the unique value proposition clearly, though it could briefly mention the expected output format (e.g., list of seat identifiers) for full 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% (only one parameter 'config_id' with description 'Aircraft configuration ID'). The description does not add additional meaning to the parameter beyond what the schema already provides, so baseline 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 states the specific verb 'List', the resource 'window-position seats', and the condition 'no actual window', clearly distinguishing it from sibling tools like rowhint_get_best_seats or rowhint_compare_seats.

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 when to use: 'when someone asks about window seats, specifically wants to avoid windowless positions, or is choosing between window seats.' It implies exclusive use cases but does not explicitly state when not to use.

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. Mentions elicitation and returns top 3, but lacks details on side effects (e.g., read-only) or handling of ambiguous inputs.

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?

Single, front-loaded sentence with no redundancy. Every word serves a purpose.

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 it's a conversational tool, description adequately covers input, process, and output format. No output schema but mentions 'top 3 seat recommendations with notes'.

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 parameter (flight) with full schema description coverage. Description reinforces that if omitted, tool will elicit, adding value beyond 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?

Description clearly states it is a 'conversational seat picker' that asks structured questions and returns top 3 recommendations, distinguishing it from siblings like rowhint_pick_seat which expects a specific seat.

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 says to use when user hasn't specified a seat or aircraft, providing clear context for when to use. Does not name alternatives but sibling list exists.

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 burden. It discloses that the tool returns 'top picks with scores and notes, seats to avoid, aircraft info, and a confidence rating.' No side effects are mentioned, but it's a read operation and the description is sufficiently informative for a recommendation 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?

Four sentences, front-loaded with the main purpose, followed by inputs, outputs, and usage examples. Every sentence adds value with no redundancy. Excellent structure for an AI agent to parse quickly.

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 tool with 4 parameters (1 required, many enums, no output schema), the description covers inputs, outputs, and example queries. It lacks mention of error handling or data sources, but these are reasonable omissions for a straightforward recommendation 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?

Schema coverage is 100%, so baseline is 3. The description adds example values (e.g., 'UA1234') and contextual grouping of optional parameters but does not provide significant new meaning beyond the schema 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 clearly states the tool's purpose: 'Get the best seat recommendations for a specific flight.' It lists inputs and outputs. However, it does not explicitly differentiate from sibling tools like rowhint_get_best_seats, missing an opportunity to clarify unique value.

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 positive usage examples ('Use when someone says...') and calls itself the 'easiest way,' implying it's for simple flight-number queries. But it lacks explicit guidance on when not to use it or comparisons with siblings, leaving the agent to infer boundaries.

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?

Describes input and output (quality score, proximity, etc.) but does not state whether the tool is read-only, requires permissions, or has any side effects. Given no annotations, the description carries the burden and is adequate but not exhaustive.

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 that efficiently convey purpose, output, and usage context. No wasted words; front-loaded with key 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?

Covers what the tool returns and when to use it. With optional parameters and no output schema, the description is sufficient. Could be improved by noting it's a safe read operation.

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 both parameters. The description adds no new parameter details beyond the schema, so 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?

The description clearly states 'Roasts a specific airline seat' and specifies it returns a 'voice-y takedown'. It contrasts with neutral lookups, distinguishing it from siblings like 'rowhint_get_seat_score'.

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 a concrete example ('how bad is seat 31B on the United 787-9') and implies when to use it (unvarnished truth). Does not explicitly list when not to use or name alternatives, but context is clear.

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