List all window-position seats that have no actual window on a specific aircraft. These are seats labeled as window seats in airline booking systems but where the fuselage structure blocks the view. Use when someone asks about window seats, specifically wants to avoid windowless positions, or is choosing between window seats.
| Name | Required | Description | Default |
|---|---|---|---|
| config_id | Yes | Aircraft configuration ID |
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.
Add one secure layer between your agents and this server.
Tools are mostly distinct, with clear purposes like comparing seats, getting best seats, overview, score, windowless, etc. Slight overlap between get_best_seats and pick_seat, as both recommend seats but for different contexts (config vs. flight). Otherwise, each tool has a unique role.
All tools use the 'rowhint_' prefix and snake_case verb_noun pattern. Most are consistent (e.g., get_*, compare_*, pick_*), but 'help_me_pick' and 'seat_roast' break the pattern slightly with imperative phrases or noun-verb order. Overall, naming is clear and predictable.
With 8 tools, the server covers a reasonable scope for seat intelligence: overview, recommendations, specific seat info, comparison, and a conversational picker. The count is well-balanced, not too few or too many for the domain.
Core use cases are covered: best seats, specific seat scoring, comparison, windowless seats, and flight-based picks. Minor gaps include lack of a tool to list all seats on a config with full details, but the conversational picker and overview tool mitigate this. Overall, agents can accomplish key tasks without dead ends.