easygroupflights

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context: the offer_id has a hard 30-minute TTL after the originating search. It omits what the API returns for an expired id, but for an annotated read tool this is solid.

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 the identity and payload of the resource, followed by the one operational constraint. No filler or restated boilerplate.

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?

An output schema exists, so return values need not be spelled out (though the description helpfully previews them), and annotations carry the safety profile. The remaining gap is error/TTL-expiry behavior, but the definition is otherwise sufficient for correct invocation.

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 the single parameter is fully documented, so the schema does the heavy lifting — baseline 3. The description's only added nuance is that the id must come from a recent search, which overlaps with the 30-minute TTL statement rather than expanding on the parameter itself.

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?

States a specific verb (gets/returns) and resource (one fare/offer by offer_id) and enumerates what comes back: per-person price, flights, booking link, validity window. The phrase 'from a recent flight search' cleanly separates it from egf_search_flights and the prepare_* siblings.

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 supplies a concrete usage window — 'Works for 30 minutes after the search' — which tells the agent exactly when this tool is callable. It stops short of naming an alternative for expired/absent offer_ids or pointing at egf_prepare_flight_offer for new offers.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real value beyond them by describing the informational nature of the response (service coverage, fare differences, post-quote process, contact path) and reinforcing "Submits nothing" so the agent knows no state change occurs.

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?

A single sentence, front-loaded with the core purpose and ending on the disambiguating "Submits nothing." Every clause conveys distinct content, 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?

An output schema exists, so return values need not be explained, and the one optional parameter is fully documented in the schema. For a low-complexity informational tool, the description supplies everything needed to select and call it 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 coverage is 100% with the enum documented as "Which market to describe. Defaults to en." The description only echoes "for one market" and adds no syntax, fallback, or behavior detail beyond the schema, so the baseline of 3 applies.

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?

Names a specific verb (Describes) and resource (easygroupflights) and enumerates the exact content covered: who it serves, fare differences, post-quote flow, and human contact. This clearly separates it from the action-oriented siblings (search, prepare, request, send), which an agent can see without opening any schema.

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 clause "Submits nothing" tells the agent this is an informational read, not a transaction, which implicitly routes transactional needs to the prepare/request/send siblings. However, no sibling is named and there is no explicit statement of when to prefer this over egf_get_offer or egf_search_flights.

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 readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuinely new behavior: it returns a confirmation_token valid for 15 minutes, states what the result contains, and reassures that nothing is sent.

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?

A single dense sentence with the preview-and-no-send guarantee front and center; every clause earns its place. Slightly awkward phrasing ('Checks an email that would send') but no 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?

With an output schema present, return values need not be re-explained, and the description adds the token validity window and the no-side-effect guarantee. For a 7-param tool it is complete enough, though it could name the follow-up send step.

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?

Every parameter is already documented at 100% schema coverage, so the schema carries the semantics. The description only alludes to 'who it goes to', adding no syntax or format detail beyond the structured fields, so baseline 3 applies.

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?

States a specific action (checks/prepares an email offer) on a specific resource (a fare from a flight search), and describes what it returns (recipient, offered fare, confirmation_token). It distinguishes itself from the write path only implicitly via 'Nothing is sent' rather than by naming the send sibling.

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 token plus 'Nothing is sent' implies this is a preview/dry-run step that precedes an actual send (likely egf_send_flight_offer), but neither the alternative nor the when-to-use condition is named explicitly. Usage is inferable but not stated.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavior: the 10-seated-traveller eligibility rule, the 15-minute token lifetime, and the explicit assurance that nothing is dispatched. It omits what happens after the token expires or whether the token is the handoff to the write step.

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, zero filler, and the eligibility condition and no-side-effect guarantee are front-loaded where an agent will read them. Nothing is redundant.

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 an output schema present, return values need not be explained, and the description still flags the token semantics. Given 20 parameters at full schema coverage and rich annotations, the definition is sufficient, though the handoff to egf_request_group_quote remains unstated.

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 20 parameters, including the infant-lap rule and perpendicular fields like youths_ages. The description only adds the aggregate '10 or more seated travellers' rule, which is a modest semantic gain over the schema baseline.

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?

States a specific verb (checks/prepares) and resource (group flight enquiry) plus the key scope condition (10 or more seated travellers) and the output (a brief plus confirmation_token). The closing 'Nothing is sent' implicitly separates it from the write siblings egf_request_group_quote and egf_send_flight_offer, but no sibling is named, so differentiation relies on inference.

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?

Usage is only implied: the 10+ seated-traveller threshold and 'nothing is sent' suggest this is the dry-run step before egf_request_group_quote, but the description never says when to use it versus that sibling or what to do with the token. No prerequisites or exclusions are stated.

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 (non-read-only, open-world, non-destructive, not idempotent), the description discloses that delivery goes to a human specialist by email, the expected turnaround of about 2 hours, and that it neither books nor charges. These are substantive behavioral facts an agent cannot infer from the structured fields.

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 tight sentences with no filler, front-loading what the tool does and following with the key constraint and the no-charge clarification. Every clause carries 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?

For a single-required-param write tool with an output schema present, the description supplies the missing flow context (prepare-then-send), the async human turnaround, and the side-effect boundaries. Nothing an agent needs to invoke it correctly is absent.

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 parameters are already documented, giving a baseline of 3. The description adds flow-level meaning by stating the confirmation_token must originate from the prepare call and that it is the only input taken, which helps the agent chain the two tools correctly.

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?

States a specific verb (sends) and resource (a prepared group flight enquiry), and the word "prepared" plus "confirmation_token from preparing it" clearly distinguishes it from the sibling egf_prepare_group_quote. An agent can tell this is the send step of a two-phase flow without opening the schema.

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 establishes the precondition that a prepare step must have run first ("Takes only the confirmation_token from preparing it") and clarifies the outcome boundary (returns confirmation, not a price, books or charges nothing). It does not explicitly name egf_prepare_group_quote as the required precursor, so the routing is left slightly 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 cover safety (readOnly, idempotent, openWorld), so the bar is lower, and the description adds genuinely useful behavior: results are cheapest-first, each offer_id is valid for only 30 minutes, and results are paginated. It does not mention rate limits or caching, keeping it short of a 5.

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, zero waste: the first front-loads purpose and result shape, the second handles pagination. Every clause 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?

An output schema exists, so return values need not be re-explained, yet the description still summarizes them usefully alongside the critical 30-minute offer_id validity and pagination contract. Only the absence of routing guidance to sibling tools leaves a gap.

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 the baseline is 3, but the description adds real value by explaining that the cursor must be replayed with the same route and dates — a constraint the schema's cursor text does not convey. It still adds nothing on limit or passengers 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?

States a specific verb (Searches), resource (live public fares), and scope (1 to 9 travellers), plus what is returned (per-person prices, carriers, stops). An agent can immediately tell this is the search entry point among siblings like egf_get_offer and egf_prepare_flight_offer.

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?

Gives clear pagination usage (pass next_cursor back as cursor with the same route/dates) but never states when to use this tool versus alternatives such as egf_prepare_group_quote for parties larger than 9 or egf_get_offer to fet up an offer. Usage is implied rather than routed.

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=false, openWorldHint=true, idempotentHint=false, so the safety profile is partly covered. The description adds the crucial real-world effect that it 'sends a real email' to an external party and produces an actionable 'formal offer they can accept', which an agent needs to know is not a dry run. It does not discuss failure modes, but that is largely handled by the schema.

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 tight sentences with no filler; the purpose and the 'real email' warning are front-loaded, and the workflow dependency follows immediately.

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 an output schema present, return values need not be described, and the schema covers token expiry and idempotency. What remains is a prerequisite and the fact a real external email is dispatched, both of which are stated; only edge-case failure behavior is absent.

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%: both confirmation_token (with its 15-minute validity) and idempotency_key (with its retry semantics) are fully documented in the schema. The description adds only that the token comes from the preparation step, which is a marginal gain over the schema, so the 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?

Specific verb+resource ('Emails a prepared flight offer to the traveller') that clearly distinguishes it from the sibling egf_prepare_flight_offer by the word 'prepared' and the explicit dependency on the token from preparation. An agent can tell the send step apart from the prepare step without opening either schema.

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 line 'Takes only the confirmation_token from preparing it' establishes the prerequisite (egf_prepare_flight_offer must run first) and the sequencing. It stops short of stating when NOT to use it or naming alternatives outright, so it is clear context rather than explicit routing.

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