FlightSeatmap

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

Annotations already indicate it's a write (readOnlyHint=false) and not idempotent. Description adds context about email notification, support for various preferences, and the prerequisite. Lacks details on rate limits or duplicate handling, but adequate.

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, no redundancy. First sentence conveys core purpose; subsequent sentences add essential context. Every 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?

Covers key points: creation, notification, preferences, authentication, prerequisite. Missing return value (e.g., alert ID) and conditional parameter dependencies (e.g., specific_seat required for 'specific' preference). Still strong given no output schema.

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 provides 100% parameter descriptions. Description lists some preference examples (window, aisle, exit row, etc.) but not all enum options. Adds minor context beyond schema, e.g., 'specific seat' and 'adjacent seats' but does not fully compensate for schema's already rich 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 it creates a seat alert for a specific flight with email notification. It differentiates from sibling tools like delete_seat_alert, list_seat_alerts, and search_flight by specifying the action and prerequisite.

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 notes that authentication is required and the flight must already exist, instructing to use search_flight first if not. Does not explicitly mention when not to use or compare with alternatives like find_best_seats, but provides clear context.

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?

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that authentication is required, which is useful beyond annotations. However, it does not elaborate on the behavior (e.g., error states, cascading effects) beyond what is 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 clearly states the action, second provides actionable prerequisite. No wasted words, front-loaded 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 the single parameter, presence of annotations, and no output schema, the description covers all necessary aspects: action, prerequisite, and authentication. It is complete for the tool's 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?

With 100% schema description coverage, the baseline is 3. The description does not add any additional meaning about the alert_id parameter (e.g., format, validation) beyond what the schema already provides.

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 action (delete a seat alert) and the resource (by its ID). It distinguishes from siblings by referencing list_seat_alerts for finding the ID, making the purpose unambiguous.

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 tells users to use list_seat_alerts to find the alert ID, providing essential context for when this tool is applicable. It implicitly suggests not using it without an ID, but does not mention alternative deletion methods or when not to use it.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the content of the returned list (complementary servers covering award flights, delays, lounges), providing behavioral context beyond annotations.

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?

Extremely concise: two sentences with no fluff. The first sentence immediately states the core purpose, making it easy for an agent to quickly understand the tool's 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 the tool has no parameters and no output schema, the description provides sufficient context about what the tool returns (list of servers) and their categories. It could mention response format or how to interpret the list, but the current level is adequate for a simple discovery 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?

With zero parameters and 100% schema coverage, the description adds no parameter semantics, but none are needed. The baseline of 4 is appropriate as the description has nothing to add 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's purpose: discovering and listing other flight/travel MCP servers. It uses specific verb 'discover' and resource 'other flight & travel MCP servers', and distinguishes itself from all sibling tools which deal with seat alerts or flight searches.

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 states when to use (to discover additional MCP servers) and gives examples of what those servers cover (award flights, delays, lounges). While it doesn't explicitly say when not to use, the context and sibling tools make it clear this is for server discovery only, not for direct flight operations.

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?

Annotations already declare readOnlyHint=true, so safety is known. Description adds that it returns a ranked list and interactive seatmap, which is helpful. However, it does not disclose that results are live (openWorldHint=true) or any ranking methodology. Behavior is partly transparent but lacks depth.

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 totaling 22 words, front-loaded with the core action and output. Every word is meaningful, with no redundancy or fluff. 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?

Lacks output schema, so description must explain return values. It adequately states 'ranked list' and 'interactive seatmap with recommended seats highlighted'. Missing details on error handling or no-match scenarios, but overall sufficient for a search 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. Description does not add new parameter meaning beyond the schema; it only echoes that preferences are matched. No extra value for parameters beyond what schema already provides.

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 verb 'find' and resource 'best available seats', specifying user preferences like window, aisle, extra legroom, etc. It distinguishes from siblings like get_seatmap (which just returns a seatmap) and get_seat_info (specific seat details).

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?

No explicit guidance on when to use this tool versus alternatives. It implies use when matching preferences, but doesn't contrast with interactive_seat_finder or get_seatmap, nor does it state when not to use it. Usage context is only implicit.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds value by explicitly stating that the tool returns characteristics, availability, pricing, and also renders an interactive seatmap. This goes beyond the annotations to provide actionable behavioral context.

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 only two sentences long, directly states the purpose, and is front-loaded with the core action. Every word adds value 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?

Without an output schema, the description sufficiently covers return content (characteristics, cabin class, availability, pricing) and the seatmap rendering. It is complete for a read-only tool, though it could mention the response format or structure.

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 restates examples for flight_number and seat_number (e.g., '12A') but does not add new semantics beyond what the schema already provides.

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 verb 'get' and the resource 'detailed information about a specific seat', listing specific data elements (characteristics, cabin class, availability, pricing) and an additional action (renders interactive seatmap). This distinguishes it from siblings like get_seatmap (renders only) and get_seat_reviews (reviews only).

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 no guidance on when to use this tool versus alternatives such as find_best_seats, get_seat_reviews, or interactive_seat_finder. There is no mention of prerequisites or exclusion criteria.

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?

Discloses caching behavior and return format (both text and visual seatmap). Annotations already indicate readOnly and non-destructive, so description adds valuable context.

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 states purpose, second gives usage guidance. No waste, perfectly 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?

No output schema, but description hints at return values (seats, classes, availability) and caching. Combined with annotations, it is fully complete for this 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% with good descriptions; description does not add extra meaning beyond what schema already provides for the two parameters.

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?

Clearly states 'Get the seat map for a flight', specifying the verb and resource. Mentions 'seats, cabin classes, characteristics, and availability', distinguishing it from siblings like get_seat_info or find_best_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?

Explicitly says 'Returns cached data — for fresh/updated data, use search_flight', giving a clear when-not-to-use and alternative tool.

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?

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds specific behavioral details: it shows ratings, comments, seat number, cabin, and helpfulness votes, and notes that it's free and requires no authentication. This provides meaningful context beyond annotations.

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 long and front-loaded with the core purpose. Every sentence adds value: the first states the action and optionality, the second lists return fields and essential context (free, no auth). 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?

The tool has no output schema, so the description compensates by listing what the response includes: ratings, comments, seat number, cabin, helpfulness votes. Given the tool's simplicity (2 parameters, no nested objects), the description is complete and sufficient for an agent to understand the tool's behavior.

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 both parameters (flight_number, seat_number) are described in the schema. The description mentions optional filtering by seat, which maps to the seat_number parameter, but adds no additional meaning beyond the schema. Baseline score 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 'Get user-submitted reviews for a flight, optionally filtered to a specific seat.' It uses a specific verb (Get) and resource (reviews) and distinguishes this from sibling tools like get_seat_info (seat specs) and find_best_seats (recommendations).

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 mentions 'Free — no auth required' and optional filtering, but does not explicitly state when to use this tool versus alternatives (e.g., when to choose get_seat_reviews over get_seat_info). The usage context is implied but lacks exclusion criteria.

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?

Annotations already indicate read-only and non-destructive behavior. The description adds value by mentioning interactivity and recommendation behavior, which goes beyond annotations.

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, front-loaded with key information, 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?

While the tool is well-described, it lacks explanation of the return format (e.g., what the interactive seatmap looks like in output). Given no output schema, the description should clarify this.

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 does not add further meaning beyond what the schema provides, so baseline score 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 the tool recommends best seats and renders an interactive seatmap, specifying its purpose and distinguishing it from siblings like find_best_seats and get_seatmap.

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 'Good default when the user wants help finding a seat but hasn't specified preferences,' providing clear usage context. However, it doesn't explicitly state when not to use it.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds value by detailing the returned fields (priority, days until flight, last check time) and authentication requirement. No contradiction with annotations.

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, front-loaded with the main purpose, followed by details. Every sentence provides value, with 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?

The description covers the key aspects of the tool, including what it lists and the authentication requirement. Without an output schema, the description sufficiently explains the expected return values. It is complete enough for a simple 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?

The tool has no parameters, so the description is not required to add parameter details. Baseline of 4 is appropriate as the description adds no parameter info but doesn't need to.

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 seat alerts (active and inactive) and specifies the information shown (seats, priority, days until flight, last check time). This distinguishes it from siblings like create_seat_alert and delete_seat_alert.

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 mentions 'List all your seat alerts' and 'Requires authentication,' providing clear context. It implicitly differentiates from create/delete siblings, but does not explicitly state when not to use it or mention 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?

Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds value by detailing credit consumption, auth requirements, and fresh seatmap retrieval, clarifying the non-idempotent, state-changing nature.

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 four sentences, each serving a clear purpose: purpose, auth, paid plan, and usage cost. No wasted words, and the key point 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?

Given 2 parameters, no output schema, and moderate complexity (auth, credits), the description covers prerequisites, credit usage, and return type (interactive seatmap). It is largely complete, though additional details on return format could be useful.

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%, and both parameters are well-described in the schema. The description does not add new information about parameters 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 clearly states 'Search for a flight and get fresh seatmap data,' using a specific verb and resource. It distinguishes from sibling tools like 'get_seatmap' and 'find_best_seats' by emphasizing the search aspect and freshness.

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 context: requires signed-in account via OAuth, paid plan for new flights, and uses a search credit. It implies when not to use (e.g., if no credits or not signed in) but does not name specific alternatives to compare.

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