skyaccess

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

The description goes beyond the readOnlyHint and destructiveHint annotations by explicitly stating that it does not create, hold, modify, or cancel any booking, and that no booking exists until the customer completes it. This clarifies the side-effect boundary clearly for an agent.

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 compact: it states what is returned, the read-only safety property, and the key alternative in three focused sentences. No filler or redundant information is present.

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 one-parameter, read-only tool with no output schema, the description provides everything an agent needs: the output type, the use case, the safety semantics, and the alternative tool. Nothing critical is missing.

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 already documents the only parameter, flightId, with a clear description referencing search_empty_legs results. The tool description adds little beyond calling it 'a specific empty leg flight,' so it relies appropriately on the schema's 100% coverage.

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 uses a specific verb ('Return') and names the exact resource ('the SkyAccess booking page link') and target ('a specific empty leg flight'). It clearly distinguishes this tool from the sibling 'request_booking' by outlining its self-service 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?

It explicitly states when to use the tool: when handing a link to a customer for self-review and booking. It also gives a direct alternative instruction: 'Use request_booking instead if the customer wants a specialist to contact them.' This makes the selection logic unambiguous.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral detail about returning ranges and falling back to all suitable aircraft categories when category is omitted, but it does not disclose additional traits such as accuracy, availability, or response structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the core purpose and then add only necessary behavioral detail about filtering and default behavior. Every sentence earns its place with no redundancy or filler.

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 read-only estimation tool, the description covers the operation, return range, optional filters, and default behavior. It is slightly incomplete in that it does not clarify what 'suitable' means beyond route and group size or how the min/max range is derived, but the schema and annotations carry much of the remaining burden.

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 input schema already documents all parameters. The description lightly restates that category and passenger count are optional filters, but it does not add meaningful information beyond the schema, justifying the baseline score of 3.

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 a specific action ('Returns an indicative price range') and resource ('private charter flight between two locations'), making the tool's purpose obvious. It does not explicitly contrast itself with sibling tools like get_flight or request_booking, so it misses the top score for sibling differentiation.

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 the tool is appropriate: when an indicative price range for a charter is needed. It also explains the optional filtering behavior and the default when no aircraft category is supplied, but it does not state when to prefer a sibling tool over this one.

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?

Beyond the readOnly and idempotent annotations, the description discloses the exact response shape (same fields as search_empty_legs, with an enumerated list) and an important edge case: a not-available message if the flight is no longer published. This gives the agent useful expectations about the call's 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 three sentences, front-loads the core action, and every sentence earns its place: what it does, the returned fields, when to use it, and the stale-flight edge case. There is no redundant wording.

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 single-parameter read-only lookup with no output schema, the description is complete: it specifies the input, the return fields, the usage context, and the not-found behavior. Sibling tools and annotations cover the remaining 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?

The schema already documents flightId fully, including its source in the search_empty_legs result, and schema coverage is 100%. The description adds no new parameter meaning beyond saying 'by its id,' so the 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 uses a specific verb ('Look up') and a precise resource ('one empty leg flight by its id'), and it clearly distinguishes this tool from the sibling search_empty_legs by noting it returns the same fields for a single known flight. The purpose is unambiguous and differentiated.

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 gives a clear use case: re-check a specific flight found earlier via search_empty_legs. It implies the alternative (use search_empty_legs for finding flights) by naming that sibling, though it does not explicitly state when not to use this tool or list all alternative tools.

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?

Beyond the annotations, the description discloses meaningful behavioral context: no payment is collected, a SkyAccess specialist will contact the requester within 2 hours, and this only initiates an enquiry. This adds process-level transparency that the annotations alone do not provide.

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?

Three short sentences with the core action front-loaded. Each sentence contributes a distinct fact: the action, the follow-up behavior, and the no-payment condition. There is no redundant or filler content.

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 that there is no output schema, the description adequately explains the asynchronous response and the enquiry nature of the tool. It could say a little more about what the caller should expect immediately after submission, but the essential workflow is covered.

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 description is not required to document parameters. It adds a small amount of relevant context by noting that no payment is required, which indirectly explains the absence of a payment parameter.

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 uses a clear verb ('Submit') and a specific resource ('charter flight booking request'), and it clarifies this is an enquiry-stage action. It does not explicitly name sibling tools, so it stops short of full differentiation, but the purpose is unmistakable.

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 when to use the tool by stating that no payment is required and that a specialist will confirm availability and pricing. It does not explicitly say when to use booking_handoff or get_charter_estimate instead, leaving that distinction to inference.

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 convey read-only, idempotent, and non-destructive behavior. The description adds critical beyond-annotation context: returns up to 5 matches, enumerates returned fields, and discloses the non-obvious 'price: null' exception where flights are returned even when max_price is set and must never be presented as within the cap.

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?

Three sentences: purpose, return contents, and a crucial pricing caveat. Each sentence earns its place and the most important behavioral exception is clearly front-loaded and separated from the rest.

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?

With no output schema, the description compensates by specifying the output shape: up to 5 flights with route, departure time, price, aircraft type, seats, and booking link. Combined with the detailed input schema and strong annotations, the description gives an agent everything needed to call the tool correctly.

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 every parameter, including the max_price exception. The description mostly restates the parameter names and the null-price caveat rather than adding materially new parameter-level meaning.

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 opens with a specific verb and resource: 'Search available empty leg flights by origin, destination, date range, passenger count, and an optional max_price ceiling.' It clearly distinguishes itself from siblings by focusing on empty-leg availability rather than charter estimates, flight details, or booking actions.

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?

It explicitly states when to use the tool: 'Use this to find discounted private jet availability for a specific route.' It does not name alternatives or state when not to use it, but the sibling list and clear purpose make the intended usage sufficiently clear.

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