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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key behaviors: this is a paid service (~$15-25 per person per flight) that performs automated check-in 36 hours before departure. However, it doesn't mention potential limitations like availability constraints, refund policies, or error conditions, leaving some behavioral aspects unclear.

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 perfectly concise and front-loaded: the first sentence states the core purpose, and the second sentence adds crucial behavioral context (cost, timing, benefit). Every sentence earns its place with no wasted words, making it highly efficient for an AI agent.

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 3 parameters, 100% schema coverage, and no output schema, the description provides strong contextual completeness. It clearly explains what the tool does, its cost and timing, and distinguishes it from similar tools. The main gap is the lack of output information, but given the schema coverage and clear purpose, this is largely sufficient for effective 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 description coverage is 100%, so the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline of 3 when the schema does the heavy lifting, but no extra value is added.

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 specific action ('Add Early Bird Check-In'), the target resource ('an existing reservation'), and the outcome ('automatically checks you in 36 hours before departure for a better boarding position'). It distinguishes this tool from siblings like 'check_in' by specifying this is a paid, automated service rather than manual check-in.

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 clear context for when to use this tool: for existing reservations to secure better boarding positions via automated check-in. However, it doesn't explicitly state when NOT to use it (e.g., for new bookings, which would use 'book_with_points') or name specific alternatives among the siblings, though the context implies it's distinct from regular 'check_in'.

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 the full burden of behavioral disclosure. It mentions that the tool 'book[s]' (implying a write/mutation operation) and 'requires logged-in account' (hinting at authentication needs), but it lacks details on critical behaviors: whether booking is reversible, what happens on failure, rate limits, or what the output looks like. For a mutation tool with zero annotation coverage, this is insufficient.

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: two sentences that cover the core functionality and a key requirement. Every sentence adds value—the first defines the tool's purpose, and the second states an essential prerequisite. There's no redundant or wasted text, though it could be slightly more structured for clarity.

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 (8 parameters, mutation operation, no annotations, no output schema), the description is incomplete. It doesn't explain the booking process outcome, error handling, or how points are applied. For a tool that performs a significant action like flight booking, more context is needed to guide the agent effectively, especially without annotations or output schema to fill 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 description coverage is 75%, with most parameters well-documented in the schema (e.g., airport codes, dates, trip type enum). The description adds minimal value beyond the schema, only implying that 'username' and 'password' relate to 'logged-in account' requirements. It doesn't explain parameter interactions (e.g., how 'returnDate' works with 'tripType') or provide additional context, so the baseline 3 is appropriate given the schema does most of the work.

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: 'Search for flights and book using Rapid Rewards points. Shows points pricing for all fare classes.' It specifies the verb ('search and book'), resource ('flights'), and mechanism ('using Rapid Rewards points'). However, it doesn't explicitly differentiate from sibling tools like 'search_flights' or 'checkout' beyond mentioning points usage.

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 some usage context: 'Requires logged-in account' indicates a prerequisite, and the mention of 'Rapid Rewards points' implies this is for loyalty program members. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_flights' (which might not handle booking) or 'checkout' (which might not handle points). The guidance is implied rather than explicit.

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 carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool cancels reservations, specifies outcomes based on fare types (Wanna Get Away fares get travel funds valid 12 months, Anytime/Business Select fares are fully refundable), and implies a mutation operation. However, it does not cover aspects like error handling, authentication needs, 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 highly concise and front-loaded, consisting of two sentences that directly convey the tool's purpose and key behavioral details. Every sentence earns its place by providing essential information without redundancy or fluff, making it efficient and easy to parse.

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 (a mutation operation with no annotations and no output schema), the description is somewhat complete but has gaps. It covers the action and fare-specific outcomes, but lacks details on return values, error conditions, or side effects. For a cancellation tool with no structured output, more context on what to expect post-execution would be beneficial.

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 100% description coverage, so the schema already documents all parameters (confirmationNumber, firstName, lastName, confirm). The description does not add any parameter-specific details beyond what the schema provides, such as explaining how parameters interact or their impact on behavior. The baseline score of 3 is appropriate since the schema handles the heavy lifting.

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 specific action ('Cancel a Southwest reservation') and distinguishes it from sibling tools like 'change_flight' or 'get_reservation' by focusing on cancellation rather than modification or retrieval. It specifies the resource type (Southwest reservation) and the verb (cancel), 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 implies usage for cancelling Southwest reservations but does not explicitly state when to use this tool versus alternatives like 'change_flight' or provide exclusions. It mentions fare-specific outcomes (e.g., travel funds vs. refunds), which hints at context, but lacks direct guidance on prerequisites or when-not-to-use scenarios.

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 the full burden of behavioral disclosure. It states that modifications involve fare differences (pay/receive credit), which hints at financial implications, but does not cover other critical aspects like authentication needs, rate limits, error handling, or what the tool returns. For a mutation tool with zero annotation coverage, this is insufficient.

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 with the core purpose in the first sentence. The second sentence adds valuable context about fare policies without redundancy. Both sentences earn their place, making it 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 the tool's complexity (mutation with 7 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to explain behavioral traits like what happens on success/failure, return values, or prerequisites. The fare difference note is helpful but insufficient for a tool that modifies bookings.

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 schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description does not add any parameter-specific details beyond what the schema provides, such as explaining interactions between parameters (e.g., how new dates relate to route changes). Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Modify an existing Southwest booking.' It specifies the verb ('modify') and resource ('Southwest booking'), but does not explicitly differentiate it from sibling tools like 'cancel_flight' or 'get_reservation' beyond the general action. The mention of fare differences adds context but not sibling distinction.

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. It mentions that Southwest doesn't charge change fees, which is useful context, but does not specify prerequisites, exclusions, or compare it to siblings like 'cancel_flight' or 'select_flight' for booking modifications.

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 carries the full burden of behavioral disclosure. It adds useful context about the timing constraint ('Check-in opens exactly 24 hours before departure') and the return values ('Returns boarding group (A/B/C) and position number'), but it doesn't cover other behavioral aspects like error conditions, authentication needs, or rate limits. This is adequate but has gaps for a tool with no 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 front-loaded with the core purpose, followed by timing and return details in just two sentences. Every sentence earns its place by providing essential information without redundancy, making it highly 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 the tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, timing, and return values, which are crucial for usage. However, it lacks details on error handling or prerequisites, leaving some gaps in contextual understanding.

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 schema already documents all three parameters thoroughly. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema. According to the rules, with high schema coverage, the baseline score is 3 even without parameter info in the 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 specific action ('Check in online for a Southwest flight'), identifies the resource ('a Southwest flight'), and distinguishes it from siblings like 'get_boarding_pass' or 'get_reservation' by focusing on the check-in process. It provides a complete, unambiguous purpose statement.

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 clear context for when to use this tool ('Check-in opens exactly 24 hours before departure'), which helps time its invocation appropriately. However, it doesn't explicitly state when NOT to use it or mention alternatives among the siblings, such as how it differs from 'get_boarding_pass' or 'get_reservation'.

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 the full burden of behavioral disclosure. While 'complete a flight booking' implies a write operation that likely creates a reservation and charges payment, the description doesn't disclose important behavioral traits like whether this is an irreversible transaction, what permissions are required, what happens on failure, or what the response contains. For a payment and booking tool with zero annotation coverage, this is a significant gap.

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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides critical sequencing guidance. No wasted words, front-loaded with the main action, and appropriately sized for the tool's complexity.

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 this is a complex payment and booking tool with 13 parameters (11 required) and no annotations or output schema, the description is incomplete. While it provides good purpose and usage guidance, it lacks critical behavioral context about what happens during execution (transaction processing, confirmation generation, error handling) and what the agent should expect as a result. The schema handles parameters well, but the overall context for this significant operation needs more disclosure.

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 schema already documents all 13 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide formatting examples beyond what's in schema descriptions, or clarify why certain fields are required. Baseline 3 is appropriate when schema does the heavy lifting.

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 with a specific verb ('complete a flight booking') and resource ('flight booking'), and distinguishes it from siblings by mentioning it should be used 'after selecting a flight with select_flight'. This provides clear differentiation from tools like 'book_with_points' or 'search_flights'.

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 this tool ('Use after selecting a flight with select_flight'), providing clear sequencing guidance. This helps the agent understand this is a later step in the booking workflow, distinguishing it from initial search/selection tools and alternative booking methods like 'book_with_points'.

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 carries the full burden of behavioral disclosure. It describes key behaviors: retrieving boarding passes with boarding group/position, optional PDF saving, and the prerequisite of being checked in. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if the passenger isn't checked in, leaving some behavioral aspects unclear.

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 extremely concise with just two sentences that are front-loaded with the core functionality. Every word earns its place: the first sentence states the primary action and key output details, while the second covers the optional PDF saving and prerequisite condition. There's zero wasted text.

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, no annotations, and no output schema, the description is adequate but has clear gaps. It covers the core purpose and prerequisite well, but doesn't describe the return format (what the boarding pass data looks like), error handling, or authentication needs. The context about boarding group/position helps, but more behavioral context would be beneficial given the lack of structured metadata.

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 schema already documents all parameters thoroughly. The description adds minimal semantic context by mentioning 'boarding group and position (e.g. A32, B15)' which relates to the output, not parameters, and 'Optionally saves as PDF' which hints at the optional 'savePath' parameter. This provides some value but doesn't significantly enhance parameter 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's purpose with specific verbs ('retrieve', 'saves') and resources ('boarding pass'), distinguishing it from siblings like 'get_reservation' or 'check_in' by focusing on boarding pass retrieval with boarding group/position details. It explicitly mentions the optional PDF saving capability, which further differentiates its functionality.

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 clear context for when to use this tool by stating 'Must be checked in first', which implies it should be used after check-in. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools, though the context suggests it's for boarding passes rather than reservations or check-ins.

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 the full burden of behavioral disclosure. It describes a read-only comparison operation but doesn't mention any behavioral traits like rate limits, authentication requirements, response format, or error conditions. For a tool with 5 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves.

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, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does (compare fare classes) and includes key details (specific classes, prices, benefits, route) in a compact format. Every element 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 complexity of a fare comparison tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral aspects, usage context, and output format. The agent cannot fully understand how to use this tool effectively without guessing about its behavior and results.

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 80%, so the schema documents most parameters well. The description adds minimal value beyond the schema by implying the tool compares fares across all Southwest classes, but it doesn't explain parameter interactions or provide additional context like how 'passengers' affects pricing or what 'benefits' entail. With high schema coverage, the 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 the tool's purpose: comparing Southwest fare classes with prices and benefits for a route. It specifies the exact fare classes (Wanna Get Away, Wanna Get Away+, Anytime, Business Select) and mentions both prices and benefits. However, it doesn't explicitly differentiate from sibling tools like 'search_flights' or 'get_flight_details', which might also provide fare information.

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. It doesn't mention prerequisites, exclusions, or how it differs from sibling tools such as 'search_flights' or 'get_flight_details'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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. While it indicates this is a read operation ('Get detailed information'), it doesn't disclose behavioral aspects like authentication requirements, rate limits, error conditions, or what happens if the flight isn't found. For a tool with 4 required parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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, efficient sentence that front-loads the core purpose and provides specific examples of what information is retrieved. Every word serves a purpose with zero waste, 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?

For a read-only lookup tool with 4 required parameters, 100% schema coverage, and no output schema, the description provides adequate basic context about what information is returned. However, without annotations or output schema, it lacks details about authentication, error handling, and return format that would be helpful for complete understanding.

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 all 4 parameters well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, so it meets the baseline of 3 for adequate coverage when schema does the heavy lifting.

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 specific action ('Get detailed information') and resource ('about a specific Southwest flight'), with explicit examples of what information is included ('status, stops, duration, gate, and aircraft type'). It distinguishes this read-only lookup tool from sibling tools like 'search_flights' (which finds flights) or 'get_reservation' (which retrieves booking 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?

The description implies usage for retrieving details of a known specific flight, but doesn't explicitly state when to use this versus alternatives like 'search_flights' (for finding flights) or 'get_reservation' (for booked flights). No guidance is provided on prerequisites or exclusions, leaving usage context somewhat implied rather than clearly defined.

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 the full burden of behavioral disclosure. It mentions checking account details but does not describe authentication behavior (e.g., how username/password are used, fallback to env vars), rate limits, error handling, or response format. For a tool with authentication parameters and no annotations, this is a significant gap in 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 a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place by specifying what is checked (balance, tier status, progress), making it highly concise 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 the complexity (authentication parameters, no annotations, no output schema), the description is incomplete. It lacks information on authentication behavior, response format, error cases, and how it differs from sibling tools. For a tool that interacts with user accounts, this leaves critical gaps for an agent to use it 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 description coverage is 100%, so the schema already documents both parameters (username and password) with details on env var fallbacks. The description does not add any meaning beyond this, such as explaining why these parameters are needed or their impact on the check. Baseline 3 is appropriate as the schema handles the heavy lifting.

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: checking Rapid Rewards account balance, tier status, and Companion Pass progress. It specifies the verb ('check') and resource ('Rapid Rewards account'), but does not explicitly differentiate it from sibling tools like 'get_reservation' or 'get_boarding_pass', which might also involve account access. This makes it clear but not fully sibling-distinctive.

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. It does not mention prerequisites (e.g., authentication needs), exclusions, or comparisons to sibling tools like 'get_reservation' that might overlap in account-related queries. This lack of context leaves the agent without clear usage direction.

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 carries the full burden of behavioral disclosure. It states it's a lookup/read operation and specifies the return data, but lacks details on error handling (e.g., invalid inputs), authentication needs, rate limits, or whether it's idempotent. For a tool with no annotations, this leaves significant gaps in understanding its operational 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 a single, efficient sentence that front-loads the purpose and key details (parameters and returns) without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise 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 the tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and return data but lacks behavioral context (e.g., error cases) and doesn't fully compensate for the absence of annotations or output schema, leaving the agent with some uncertainty about execution.

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 clear descriptions for each parameter (e.g., '6-character booking confirmation number'). The description adds minimal value beyond the schema by mentioning the parameters in context but doesn't provide additional semantics like format examples or constraints. Baseline 3 is appropriate since the schema already documents parameters well.

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 specific action ('Look up an existing Southwest reservation'), the required identifiers ('by confirmation number and passenger name'), and the return data ('flight details, fare type, and booking status'). It distinguishes from siblings like 'get_flight_details' or 'search_flights' by focusing on retrieving a specific reservation rather than general flight information or search capabilities.

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 usage when you have a confirmation number and passenger name to retrieve reservation details, but it doesn't explicitly state when to use this tool versus alternatives like 'get_flight_details' (which might not require passenger info) or 'search_flights' (for broader queries). No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.

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 carries full burden for behavioral disclosure. It states what the tool returns (flights with fare options and pricing) but doesn't mention important behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, pagination, error conditions, or what happens with invalid parameters. For a search tool with 7 parameters, this leaves significant gaps.

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 perfectly concise - two sentences that efficiently convey the core functionality and return value. Every word earns its place with no redundancy or unnecessary elaboration. It's front-loaded with the primary purpose immediately clear.

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 search tool with 7 parameters and no output schema, the description is adequate but incomplete. It covers the basic purpose and return format but lacks behavioral context (authentication, errors, limits) and doesn't explain the relationship between fare options mentioned and the fareType parameter. Without annotations or output schema, the agent has insufficient information about the full 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 description coverage is 100%, so the schema already documents all 7 parameters thoroughly with descriptions, formats, enums, and requirements. The description adds minimal value beyond what's in the schema - it mentions fare options (Wanna Get Away, Anytime, Business Select) which aren't in the schema, but doesn't explain how these relate to the 'fareType' parameter. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('Search for available Southwest Airlines flights'), identifies the resource ('between two airports'), and distinguishes from siblings by specifying it returns flights with fare options and pricing. This differentiates it from tools like 'get_fares' or 'get_flight_details' which likely retrieve specific fare/flight data rather than performing a search.

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. It doesn't mention prerequisites, when to choose this over 'get_fares' or 'select_flight', or any constraints like availability windows. The agent must infer usage from the tool name and description alone.

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 the full burden of behavioral disclosure. The description mentions it's used 'to proceed with booking,' implying a mutation step, but doesn't clarify if this is a reversible action, what permissions are required, whether it commits to a booking, or what happens after selection. For a tool with no annotations and apparent booking implications, this is a significant gap.

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 with zero waste. The first sentence states the purpose, and the second provides usage context, both front-loaded and efficiently worded.

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 annotations, no output schema, and a tool that appears to be a mutation step in booking (implied by 'proceed with booking'), the description is minimally adequate. It covers purpose and workflow but lacks details on behavioral implications, error conditions, or what the tool returns, leaving gaps for an agent to understand the full 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?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond implying a connection to 'search_flights' results, which the schema's 'flightIndex' description already covers. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Select a flight') and resource ('from search results'), with a specific purpose ('with a specific fare type'). It distinguishes from siblings by mentioning 'search_flights' as a prerequisite, but doesn't explicitly differentiate from other booking-related tools like 'checkout' or 'book_with_points'.

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 clear context by stating 'Use after search_flights to proceed with booking,' which indicates the prerequisite and workflow position. However, it doesn't specify when NOT to use this tool or name explicit alternatives among siblings like 'book_with_points' or 'checkout' for different booking scenarios.

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