SlickTrip

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds real behavioral context beyond that: the watch keeps searching and alerts when the fare clears the bar, a bucket_id is returned, and confirmation is required before creating. It doesn't cover how alerts are delivered or any limits on concurrent watches.

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 tight sentences, front-loaded with the exact use case and example, followed by the return value, the confirmation requirement, and the exclusion. No filler; every clause carries routing or behavioral 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 an 18-parameter creation tool with a full-coverage schema and an output schema (so return values need not be explained), the description covers the core intent, the alternative path for fixed dates, and the confirmation step. It is a little thin on what happens after creation (alert cadence, output schema fields like bucket_id aside), but nothing essential to calling it correctly 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?

Schema description coverage is 100%, so all 18 parameters are already documented in the schema, including months vs start_date/end_date and the price bar. The description only gestures at the flexible-date window and price bar, adding no syntax or format detail beyond what the schema provides, so the 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?

The description gives a concrete verb+resource ('flexible-date watches' / bucket list) and grounds it with a realistic example ('tell me when New York to Tokyo drops under $700 this winter'). It explicitly names the siblings it is not for (search_flights, track_flight with fixed dates), so an agent can distinguish it 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?

States when to use it (flexible dates, price-bar alerts over months or a date window), when not to (fixed dates go to search_flights then track_flight), and adds an operational prerequisite ('Confirm first'). Both routing conditions and the alternative path are 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?

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=true), so the description is free to add the operational behavior: an ongoing search across months/date window that alerts when a stay clears the per-night bar, plus the returned bucket_id and the confirm-first requirement. It stops short of stating alert frequency, duration of the watch, or auth/quota constraints.

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 dense sentences plus a short directive, front-loaded with the use case before the exclusion. Efficient, though the parenthetical sibling pointer and 'Confirm first' fragment make it slightly cluttered.

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, yet the description usefully notes it returns a bucket_id. Given annotations plus a fully documented 11-param schema, the definition is essentially complete for correct invocation; only alert cadence and lifetime of the watch are 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 coverage is 100% with 11 well-documented parameters, so the schema carries the burden and a 3 is the baseline. The description adds only light semantics — 'stays of the given length' (nights) and 'the per-night bar' (max_price_per_night) — without clarifying the months-vs-date-window exclusivity that the schema already documents.

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 and resource — creating a flexible-date hotel watch — and immediately scopes it to 'a place or one named hotel'. It distinguishes itself from fixed-date alternatives by naming search_hotels and track_hotel, so an agent can route correctly 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?

Explicitly says when to use it (flexible dates, watch a place or one hotel) and when not to ('Not for fixed dates (search_hotels, then track_hotel)'), naming the exact alternative tools and the sequence. The 'Confirm first' instruction adds a procedural prerequisite.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful non-annotation context: the result is a set of sellers (airline direct and agencies) each with price and an external checkout link, which sets expectations for an open-world read. It does not add auth, rate-limit, or freshness/caching details, so it falls 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?

Three tight sentences: purpose first, then the prerequisite constraint, then the exclusions. Every clause carries routing or prerequisite information, and nothing is repeated from the schema beyond necessary framing.

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?

Annotations cover the safety profile, the output schema covers return values, and the single parameter is fully documented in the schema. Combined with the description's explicit prerequisites and alternatives, an agent has everything needed to invoke this 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?

With 1 parameter at 100% schema description coverage, the schema already documents itinerary_id, and the description largely restates it (one-way from search_flights, round trip from search_return_flights). The only added nuance is the word 'complete', which is already implied by the schema wording, so the 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 verb+resource: retrieving the sellers offering a chosen itinerary, with each seller's price and checkout link. It explicitly names the sibling tools it derives from (search_flights, search_return_flights) and the one it is not (track_flight), so an agent can distinguish it 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?

Gives an explicit trigger ('when the traveler wants to book flights they have chosen'), an explicit exclusion ('not for an outbound alone – choose a return first'), and an alternative for a different intent ('not a price watch (track_flight)'). The when/when-not/alternative triad is fully covered.

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, and non-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: it explains the resolution granularity (one airport vs. all airports in a city) and that the returned code is meant to be fed into origin/destination fields. It stops short of describing result size or fallback behavior on no match.

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 compact sentences, front-loaded with the usage trigger, then the behavior, then the exclusion. No filler and nothing redundant with structured fields.

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?

Although an output schema exists (so return shape needn't be documented), the description still conveys the practical payload semantics an agent needs: the code to use, and the airport set a city code covers. With fully documented params and annotations, nothing essential 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?

Schema coverage is 100% so the baseline is 3, and the description goes beyond it by clarifying that 'query' accepts a place name or a code and by describing how the query is interpreted (single airport, whole city, or code-to-coverage). It adds meaning not present in the schema's field titles.

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 and resource ('matches a place name or code') and the concrete output ('returns the code to pass as origin or destination'), which cleanly separates it from siblings like flight_lookup and search_flights. An agent can identify its role 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?

Explicitly says when to use it ('before searching' when unsure of a code) and when not to ('Not needed for well-known codes like JFK or LHR'), with a concrete example. This is close to ideal routing guidance for a lookup/resolution 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety and idempotency are covered. The description adds 'No fares' and lists returned fields, but does not describe auth needs, rate limits, or other behavioral traits beyond annotations; the added context is minimal and partly redundant with the output 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 sentences, front-loaded with the primary use case and immediately followed by output content, exclusions, and alternatives. Every clause earns its place with no 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?

Given output schema exists and annotations cover the safety profile, the description provides purpose, usage, alternatives, and limitations ('No fares'). An agent has everything needed to call it correctly and distinguish it from siblings.

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 notes that the flight_number parameter (or a route search result) is needed for seat_availability or track_seats, which is usage context, but it adds no syntax or format meaning 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?

States a specific verb and resource: which flights operate a route on a date, and lists the returned attributes (departure/arrival times, carrier, aircraft, stops). Explicitly distinguishes from search_flights (prices) and price_calendar (whole month), so an agent can select it without opening sibling schemas.

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 explicit when-to-use conditions (traveler wants flights on a route/date, or needs a flight number for seat_availability or track_seats) and when-not-to-use conditions (not for prices, not for a whole month) with named alternatives. No guidance is left 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not: text alerts only work if a phone is verified on the site. It does not mention caching or refresh behavior, but that is minor given the annotations and output 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?

A single sentence, front-loaded with the usage trigger before the field enumeration, with no filler. The trailing colon-list is long but every item maps to real returned data, so it 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?

With an output schema present, the description need not document return values, and it instead spends its words on the trigger, the contents, and the phone-verification prerequisite for text alerts. Nothing an agent needs to call this correctly 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 tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description misleads about inputs, and the field list it does give describes the response rather than arguments.

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 enumerates exactly what the tool returns — name, member since, working alert channels, plan and its free limit, and watched-item counts — which lets an agent distinguish it from update_account and the list_tracked_* siblings. The verb is only implicit (carried by the name 'get'), so it falls just short of a full verb+resource 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?

It gives two concrete triggers: 'before offering text alerts' and 'when the traveler asks about their account'. That is clear usage context, but no when-not guidance or explicit routing to update_account as the alternative is provided.

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/openWorld/non-destructive, so the safety profile is covered. The description adds real context beyond them: the link lands the user 'without running a search', the track_url 'starts tracking on arrival', and the bucket list 'saves on arrival' — side effects on the destination site. It does not explain link expiry or auth requirements in detail, hence 4 rather than 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?

A single dense sentence, but front-loaded with the usage condition and then the behavior, so an agent reads the decisive information first. It is longer than ideal and the parenthetical enumeration is heavy, but every clause carries signal.

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 26 parameters, a 100%-covered schema, and an output schema present, the description only needs to cover purpose, trigger, and the net effect of the link. It does all three, so the definition is complete enough to call correctly; minor gaps around what the returned link looks like are covered by the 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 description coverage is 100%, so the baseline is 3, but the description genuinely adds meaning the schema lacks: the `kind` enum is only described as 'Which page to land on' in the schema, while the description explains what each kind produces (a configured flights search, a saved bucket list, etc.). That mapping is not recoverable from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('builds a link that lands them fully configured') and enumerates exactly what the link can target, matching the four values of the `kind` enum: flights search, bucket list, hotel search, seat tracker. An agent can distinguish this from siblings such as share_link or track_flight 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?

It gives an explicit triggering condition: 'Use when the traveler wants to continue on slicktrip.com, or the account is not connected.' That is clear when-to-use guidance. It stops short of naming alternatives or when-not (e.g., when the account IS connected and an in-app search is preferred), so it is not a full 5.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context on top: the result is a multi-seller list including the hotel's own site, each entry carries a stay total and a link that leaves the app to open the seller's checkout — which is exactly the openWorld behavior an agent should anticipate. It does not mention auth requirements or result limits, so it stops 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?

Three sentences, each load-bearing: trigger, payload description, input provenance, then the sibling exclusion. The purpose and the 'when' are front-loaded before any detail.

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 the description need not explain return fields, yet it still characterizes the result well enough to set expectations. Trigger, inputs, provenance, and sibling differentiation are all present for a simple two-parameter read 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% and both properties are already documented as coming from search_hotels, so the description's 'Takes the search_key and hotel_id from search_hotels' largely repeats the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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 names a specific action (retrieve every seller quoting a given hotel for the searched dates), the resource (hotel booking sellers), and the payload shape (stay total plus a checkout link per seller). It also distinguishes itself from the near-named sibling booking_options and from track_hotel by explicitly disclaiming price watching.

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 opens with an explicit trigger ('Use when the traveler wants to book a hotel from search_hotels'), states the prerequisite source for both inputs, and names an exclusion ('Not a price watch (track_hotel)'). An agent knows both when to call it and when not to.

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, openWorldHint and destructiveHint false, so the safety profile is covered. The description adds the data-provenance dependency (both arguments must come from a prior search_hotels call) and the routing constraint on booking links, but no rate limits, caching, or failure modes. Since an output schema exists and annotations handle safety, this is a genuine but modest addition.

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 tight sentences, front-loaded with the trigger condition before the alternatives and prerequisites. The mid-sentence enumeration of returned fields is slightly list-heavy but every item is differentiating information, not 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 no prose, annotations cover the safety profile, and the description covers trigger, prerequisites, and the two adjacent siblings. Nothing an agent needs to call this correctly 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?

Schema description coverage is 100% and both param descriptions already say 'from search_hotels', so the description's 'Takes the search_key and hotel_id from search_hotels' largely repeats the schema. It adds the useful implicit constraint that these are search-scoped, not global IDs, but no format or validity details. 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?

Names a specific verb+resource (fetch details/photos/rooms/rating for ONE hotel) and enumerates the payload returned, so the agent knows exactly what it gets. It explicitly distinguishes itself from hotel_price_calendar (prices across dates) and hotel_booking_options (links).

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?

States the trigger condition ('traveler asks for details, more information, photos, rooms or description of one hotel'), the alternative to use for dates/prices, and the sibling for booking links with a gating condition ('call that only when they say book'). Prerequisites for both params are given.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real context beyond them: the call requires a signed-in account and spans months of results, which is not derivable from the 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?

Three short sentences with no filler; the user-intent trigger is front-loaded, then the prerequisite, then the next step. 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?

Covers the intent, prerequisite chain and follow-up action, and an output schema exists so return values need not be explained. Only minor gap is the lack of explicit differentiation from the sibling price_calendar 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 description coverage is 100%, so the schema already documents hotel_id, start_month and end_month (including defaults and formats). The description only restates the hotel_id source, adding no new syntax or semantics. 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 verb+resource+scope: 'one hotel's nightly price by check-in date across a span of months', and frames the user intent ('when is this hotel cheapest'). This clearly distinguishes it from hotel_details, hotel_booking_options and the generic price_calendar 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?

Gives a clear trigger phrase, a required prerequisite ('Needs a hotel_id from search_hotels'), and a follow-up workflow ('Then search_hotels with the chosen dates to track it'). It does not, however, explicitly contrast with the sibling price_calendar, leaving some ambiguity for an agent choosing between the two calendars.

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=false, so safety is covered. The description adds value beyond that by disclosing the shape of the result (settings, best deals so far) and, critically, that the bucket_id it returns is the handle consumed by update_bucket_list, remove_bucket_list and share_link. It says nothing about pagination beyond the schema's limit, which is a minor 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?

One sentence, front-loaded with the action and resource, with no filler. Every clause carries information an agent needs: scope, payload, and the id's downstream consumers.

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, yet the description still sketches them usefully. Combined with annotations covering the safety profile and the schema covering 'limit', the definition is essentially complete; only ordering/pagination nuance is left implicit.

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% and the single 'limit' parameter is fully documented there (1-200, newest first). The description mentions no parameters at all, so it adds nothing on top of the schema; 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?

States a specific verb ('see') and resource (flight and hotel bucket lists) scoped to the signed-in account, and enumerates the returned payload (settings, best deals, bucket_id). It also distinguishes itself from update_bucket_list, remove_bucket_list and share_link by naming them as consumers of the id it produces.

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?

'Use to see ... on the signed-in account' gives a clear condition for invoking it, and pointing at the three sibling tools that take the bucket_id supplies real routing context. There is no competing list tool to exclude, so no explicit when-not guidance is required, but none is offered either.

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 the safety profile is covered. The description adds real value beyond that: it is scoped to the signed-in account, it discloses that each itinerary is shown as current price versus price at tracking start, and it surfaces the IDs needed by mutation tools.

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 front-loaded sentence that opens with the usage verb and then lists return contents without filler. The enumerated list is dense but every item is informative, though the sentence is on the long side for a one-parameter list tool.

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?

Output schema exists so return values need not be explained, yet the description still calls out the account scoping, the price-comparison semantics, and the downstream ID handoff — precisely the context an agent needs to route and chain correctly. Nothing material 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?

Schema description coverage is 100%, so the single 'limit' parameter (1-200, newest first, default 50) is fully documented in the schema. The description adds no further parameter guidance such as pagination or default-ordering notes, so the 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 verb and resource ('see the flight price alerts on the signed-in account') and then enumerates the exact contents returned: route, dates, cabin, alert settings, price deltas, and the search_key/fid identifiers. It also names the sibling tools that consume those identifiers, so the agent knows how this read tool fits the tracked-flights workflow.

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 opening clause 'Use to see...' gives a clear when-to-use context tied to the signed-in account, and mentioning stop_tracking_flight/update_flight_tracking implies the follow-up workflow. There is no explicit statement of when not to use it or a direct pointer to list_tracked_hotels/list_tracked_seats as alternatives, so it falls short of a 5.

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, closed-world, non-destructive), so the bar is lower; the description still adds value by scoping results to the signed-in account and disclosing the comparison semantics (current price vs. price when tracking began). It does not mention pagination or ordering beyond what the limit param implies.

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 front-loaded sentence with no filler; the purpose comes first and the field inventory follows. It is somewhat dense in its enumeration but 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?

With an output schema present, the description needn't document return values, yet it still previews them and links to the downstream update/stop tools. Annotations plus the 1-param schema leave nothing an agent needs 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?

Only one parameter and its schema description is fully covered (default 50, range 1-200, newest first). The prose adds no parameter detail, which is acceptable given the schema does the work, so the 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 verb and resource ('see the hotel price alerts on the signed-in account') and enumerates what the listing contains: stay dates, guests, current vs. starting price, and the tracking_id/hotel_id. The 'hotel' qualifier and account scoping cleanly separate it from list_tracked_flights and list_tracked_seats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'Use to see...' establishes the context of use and the trailing clause implicitly routes the agent to the update and stop tools by naming the IDs they consume. It never states exclusions or an explicit alternative (e.g., when to prefer this over hotel_booking_options), so it falls short of a 5.

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 useful context beyond that: results are scoped to the signed-in account, and the tracking_key it returns is the handle the update/stop tools take, which tells the agent how to chain calls.

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?

One sentence, front-loaded with the 'Use to see...' intent and no filler. It is dense and slightly run-on with its comma-separated field list, but 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?

An output schema exists, so listing return fields is not strictly required, and annotations cover the safety profile; the description still fills the remaining gaps (account scoping, tracking_key handoff). Nothing essential for correct invocation 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?

Schema description coverage is 100% and the single 'limit' parameter is fully documented in the schema (1-200, newest first). The description adds nothing about the parameter, so the baseline 3 for schema-carried semantics 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 verb and resource ('see the seat alerts on the signed-in account') and enumerates the returned fields (flight, departure, cabin, watched seats, open status). This cleanly separates it from the sibling list_tracked_flights and list_tracked_hotels, which cover different tracked entities.

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 context ('seat alerts on the signed-in account') and implicitly routes the agent onward by noting the returned tracking_key is what the update and stop tools consume, which is a real workflow hint. It stops short of an explicit when-not or a named 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety profile is covered. The description adds the two-month scope and the workflow handoff to search_flights, but does not mention pagination or output-shape caveats beyond what the output schema presumably provides.

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 clauses, front-loaded with the use case, followed by the natural next step and the exclusion. No 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?

Given 10 parameters, full schema coverage, and an output schema, the description supplies the missing decision context (when to use it vs search_flights) and the scope of results. It leaves raw parameter semantics to the schema, which is acceptable here.

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 parameters (origin/destination syntax, month, cabin, travelers, etc.) are fully documented in the schema. The description adds no parameter-level detail, which is the expected baseline when the schema does all 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?

States a specific user question ('when is it cheapest to fly') and the concrete output: cheapest fare per departure day across ~two months. Clearly distinguishes itself from search_flights by contrasting the calendar view with bookable itineraries.

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 routes the agent: use this for cheapest-day discovery, then call search_flights for the chosen day, and 'Not for a specific date' gives the negative condition.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine non-structured context: no authentication required, and that results are alerts SlickTrip actually sent (a sent-history feed) rather than computed-on-demand prices. It leaves the freshness window (how far back "recent" reaches) undefined.

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?

One tightly packed sentence plus a short negating clause: the usage trigger, the data source, the category breakdown and the no-auth note all land up front with no 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?

With an output schema present, return values need no explanation, and the description correctly focuses on source, categories and auth. The only meaningful gap is the undefined recency window, which an agent would need to interpret "freshest" or set user expectations.

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 takes zero parameters, so the baseline is 4; there is no argument syntax for the description to clarify. It does usefully enumerate the category dimension of the result, which is the only knob-like concept here, but that belongs to the output rather than the input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (the freshest price-drop alerts SlickTrip actually sent) and scope (by category: flights, hotels, seats, flexible routes), and explicitly contrasts itself with search tools. An agent can distinguish it from search_flights/search_hotels/price_calendar 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?

It gives a concrete usage trigger ("any deals right now?") and an exclusion ("Not a search"), plus the precondition that no account is needed. It does not name a specific sibling to use instead when the user wants a targeted search, so it falls just short of the full when/when-not/alternative triad.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description adds genuinely new behavioral context: the action cannot be undone and the caller should confirm first, which is a workflow requirement not encoded in the 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?

A single front-loaded sentence carrying purpose, parameter provenance, irreversibility, and a confirmation cue. No filler and nothing 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?

For a one-parameter destructive tool with annotations covering safety and an output schema covering returns, the description supplies the missing prerequisites and reversibility warning. Only the absence of alternative-tool routing keeps it from being fully complete.

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's description already states it comes from list_bucket_lists, so the description largely repeats the schema. It adds no format, type, or validation detail beyond provenance. 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 names a specific action on a specific resource (stop a bucket list) and its title matches 'Remove a bucket list'. The verb 'stop' is slightly softer than the actual destructive removal, but the reference to bucket_id from list_bucket_lists anchors it clearly against siblings like add_flight_bucket_list and update_bucket_list.

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 gives a clear precondition (obtain bucket_id from list_bucket_lists) and an operational instruction ('confirm first'), which is more than most definitions offer. It does not explicitly contrast itself with update_bucket_list or the add_* siblings, so it stops short of full when/when-not guidance.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds behavior annotations do not: results are ordered with nonstop carriers first, and it returns the airline codes that the airline filters consume. It does not discuss result size or pagination, but with an output schema present that gap is minor.

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 that front-loads the usage trigger, then the returned resource, then the exclusion. No filler, nothing repeated from the schema or annotations.

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 two-parameter read-only lookup with full schema coverage and an output schema, the description supplies exactly the missing piece: when to call it and how the output orders carriers. Nothing needed 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 description coverage is 100% and both parameters are richly documented in the schema itself (airport vs city codes, underscore joining, find_places fallback). The description adds no parameter-level meaning beyond what the schema already provides, 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?

States a specific resource ('the carriers on the route') and a clear scope, and explicitly contrasts itself with a fare search. An agent can distinguish it from search_flights, flight_lookup, and booking_options 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?

Gives two explicit triggers ('when the traveler asks who flies a route, or before filtering by airline') and one explicit exclusion ('Not a fare search'). This is textbook when-to-use / when-not-to-use guidance.

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, openWorldHint and destructiveHint=false, so safety is covered. The description still adds real behavioral context: results come back priced cheapest-first, include itinerary_ids consumed by track_flight/search_return_flights and a search_url, and that unknown fields are left empty because 'nothing is guessed'. It stops short of covering pagination or error/empty-result behavior, so not 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 dense sentences, front-loaded with the usage trigger and ending with the exclusion clause; every clause carries information. It is long but not padded given 19 parameters and multiple modes, though the middle 'or ... or ...' construction takes some parsing.

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 19-parameter, multi-mode search tool with full schema coverage, output schema present, and rich annotations, the description covers the remaining gaps: mode selection, field-population strategy, override precedence, and the return artifact (itinerary_ids, search_url). Nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema does not: legs overrides origin/destination/dates, and query backfills any empty field while unknown fields stay empty. These interaction rules are genuinely beyond the per-field schema text.

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 names the specific verb and resource and enumerates the callable modes (one way, round trip, flexible dates, several airports, multi-city). It also explicitly marks the sibling tools it is not (price_calendar, add_flight_bucket_list), so an agent can distinguish it 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 opens with an explicit 'Use when the traveler wants flights for known dates' trigger, describes how to populate fields for each mode, and closes with explicit exclusions routing to price_calendar and add_flight_bucket_list. This is when-to-use plus when-not-to-use plus named 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 already declare the safe read-only, idempotent, non-destructive profile, so the description is free to add real value: results are ordered 'cheapest first,' filter semantics 'match the site,' and the response carries hotel_ids, a search_key, and a search_url. It stops short of describing pagination or result-count behavior beyond max_results.

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 dense sentences, front-loaded with the usage gate and the exclusion, then output shape, then filters. The mid-sentence filter and return enumerations are list-like but each maps to real capability; nothing redundant, though slightly packed.

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 16-parameter search tool with an output schema and full annotation coverage, the description supplies the routing decision, the return contents, and the downstream keys needed to chain into track_hotel and hotel_price_calendar. Nothing an agent needs to select or invoke it 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?

Schema description coverage is 100%, so every parameter including the enum values, amenity lists, and bounds is already documented in the schema. The description's filter summary ('price, stars, guest rating, property kinds, amenities, free cancellation, hotels or vacation rentals, sort') mirrors the schema without adding semantics, so the 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 verb (search) and resource (hotels) with an explicit scope gate: 'the traveler wants a place to stay for known dates.' It also names the sibling it is not for (add_hotel_bucket_list for flexible months), so the agent can route 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?

Gives an explicit when ('known dates') and an explicit when-not with the alternative named ('Not for flexible months (add_hotel_bucket_list)'). The downstream handoff to track_hotel and hotel_price_calendar is also spelled out.

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, openWorld, non-destructive), so the bar is lower. The description adds stateful behavior beyond that: it consumes an outbound itinerary_id, returns complete itineraries with the trip total, and flips 'needs_leg' to false once the trip is whole, which tells the agent about the tool's role in a multi-step flow.

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 tight sentences with zero padding. The most important fact (when to call it, and after what) is front-loaded, and each subsequent sentence adds a distinct piece of context.

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 an 11-param tool with full schema coverage and an output schema, the description covers sequencing, prerequisites, scope of filters, and the multi-leg flow. Nothing an agent needs to invoke it correctly is missing, and the return-shape mention is a harmless reinforcement of the 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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying filter scope ('Filters apply to the leg being chosen') and characterizing itinerary_id as an outbound or partial multi-city id, which the schema states only generically.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('search return flights') and anchors it to a sibling: 'Use after search_flights'. It distinguishes the tool from the plain flight search by its role as the second leg, so an agent can tell them apart 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?

It gives explicit sequencing ('Use after search_flights'), conditions for use ('when the traveler wants a specific return, or the next leg of a multi-city trip'), a repetition rule ('once per remaining leg'), and an exclusion ('Not needed for an outbound watch'). When-not guidance is present alongside the when.

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 cover the safety profile (readOnly, idempotent, open-world), and the description adds material context beyond them: the live seat map is a paid lookup and requires a signed-in account. Auth and cost prerequisites are exactly the kind of disclosure annotations cannot convey.

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?

Front-loaded with the action ('Use to see...'), followed by a dense but useful output list and two short routing sentences. Every sentence earns its place, though the parenthetical about the paid lookup is slightly compressed.

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, and the description still covers purpose, prerequisites, alternatives and exclusions for a 6-parameter tool. Nothing an agent needs to invoke it correctly 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?

Schema description coverage is 100%, so flight_number, origin, destination, depart_date and the cabin enum are already fully documented inline, including fallbacks like find_places. The description only restates 'needs the flight number, route and date', adding no syntax or constraint beyond the schema; 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 verb and resource with scope: see which seats are open right now on one flight, and it enumerates the returned detail (seat numbers by row, window/aisle/middle/exit counts, pairs). It distinguishes itself from siblings by naming track_seats and explicitly excluding prices.

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?

Explicit routing: use this for current availability, then use track_seats to be notified when a seat opens, and 'Not for prices' rules out price_calendar. The condition that selects each alternative is stated rather than implied.

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, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds real value beyond that: it discloses what the call surfaces (itinerary or bucket list plus current price) and the downstream intent (starting one's own watch). It omits anything about resolution failure on a bad/expired code, which is the only remaining behavioral 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?

Three tight sentences, with the trigger condition front-loaded ahead of the exclusion. Only the 'Takes the link or its code' clause is wasted, since it duplicates the schema description. No other 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, yet the description still characterizes the payload (itinerary/bucket list + current price). With annotations covering safety and the schema covering the single argument, an agent has everything needed to select and invoke this 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% and the single parameter's description already spells out 'a slicktrip.com/share/<code> link, or just the code.' The description's 'Takes the link or its code' restates that verbatim and adds no format, validation, or normalization detail. Baseline 3 is correct when the schema carries the full parameter burden.

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 ('open a shared trip') bound to a concrete trigger artifact (a slicktrip.com/share link) and says what comes back: the itinerary/bucket list plus its current price. It also explicitly names the sibling it is not (share_link), so an agent can separate ingest-a-link from create-a-link without reading 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?

Gives an explicit invocation condition ('Use when the traveler pastes a slicktrip.com/share link') and an explicit exclusion ('Not for making a link (share_link)'). The when-to-use and the alternative are both stated, not inferred.

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 the write/idempotent/non-destructive profile, and the description adds genuinely new context: the link is public, exposes the itinerary and price but "nothing about the account", and is "made once and reused". The privacy scope and reuse behavior are exactly the kind of detail annotations cannot express. It stops short of 5 only because it never says whether an existing link is returned or regenerated on a repeat call.

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 front-loaded sentence opening with the usage trigger, with every clause carrying information (resource, output, privacy, idempotency). It is dense rather than padded, though the length makes it slightly harder to scan than a two-sentence split would be.

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 covers privacy, durability and the two input sources well. The one real gap is that both parameters are optional, so nothing tells the agent what happens when neither bucket_id nor search_key is supplied.

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%, and the two parameters are documented in-schema with explicit cross-references to list_bucket_lists and list_tracked_flights. The description adds no parameter-level meaning, so the 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?

The description states a specific verb (share) plus the two resource types it accepts (a tracked route or a flight bucket list) and the artifact it produces (a public slicktrip.com link). That is well beyond a tautology, but it never distinguishes itself from the sibling tool shared_trip, leaving the agent to infer the boundary.

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?

"Use when the traveler wants to share a tracked route or a flight bucket list" gives an explicit trigger condition that maps cleanly onto the two optional inputs. There is no statement of when NOT to use it and no named alternative (e.g. shared_trip) to route against, so it stops short of a 5.

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 destructiveHint=true and idempotentHint=true, so the irreversible nature is partly covered. The description still adds actionable context beyond that: the irreversibility is stated in plain language and paired with a 'confirm first' instruction the agent can act on, though it says nothing about what state remains after removal (e.g., whether the route disappears from list_tracked_flights).

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 that front-loads the purpose, then nests the two mutually exclusive scoping options, ending with the safety caveat. No filler and nothing an agent must read past to find the core action.

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 only two parameters, full schema coverage, an output schema, and annotations carrying the mutation/ idempotency profile, the description covers everything an agent needs: what it does, the two modes, the identifier source, and the irreversibility warning. Nothing material 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?

Schema description coverage is 100% – both search_key and fid are fully documented in the schema, including that fid preserves the route while targeting one itinerary. The description repeats the sourcing of both params without adding format or validation detail, 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?

The description names a specific verb ('stop price alerts') plus a precise resource and two levels of scope: a whole tracked route via search_key, or a single itinerary via fid. That scope distinction is exactly what separates it from siblings like update_flight_tracking (modify) and stop_tracking_hotel/stop_tracking_seats (other resources).

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 tells the agent where both identifiers come from (list_tracked_flights) and the consequence ('Cannot be undone; confirm first'), which is clear operational context. It stops short of explicitly naming the alternative to use when the intent is to edit rather than end tracking, so it is not a full 5.

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 flag destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description goes beyond them by stating the action is irreversible and instructing the agent to confirm first, which is meaningful guidance for an agent acting on a user's behalf.

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 that front-loads the action and scope, then adds the consequence. No wasted words and the parenthetical identifier hints are tightly embedded.

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 destructive two-parameter tool with full schema coverage, annotations, and an output schema, the description supplies everything an agent needs: action, scope options, identifier source, and the confirmation requirement.

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, and the description adds where tracking_id comes from and clarifies that hotel_id narrows the scope to one hotel. That provenance detail is useful orientation beyond the schema's own per-field text.

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+resource: stop price alerts for a tracked stay or a single hotel within it. It clearly separates itself from track_hotel and update_hotel_tracking by naming the termination action and the two possible scopes.

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 context for when to call it (ending alerts on a tracked stay) and points to list_tracked_hotels as the source of tracking_id. It does not explicitly contrast with update_hotel_tracking or track_hotel, but the destructive framing makes the distinction inferable.

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 destructive=true, idempotent=true and readOnly=false, so the safety profile is mostly covered. The description still adds value beyond them: it states the action cannot be undone and requires confirmation, which the hints do not convey. Nothing is claimed that conflicts with the 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 short sentences, front-loaded with the action and followed by the parameter source and the irreversibility warning. No filler or repetition.

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 one-parameter destructive tool with an output schema, the description covers what it does, where the parameter comes from, and the crucial irreversibility/confirm step. An agent has what it needs to call it correctly; only cross-references to the sibling stop/update tools are 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 description coverage is 100% for the single tracking_key parameter, and the schema already names list_tracked_seats as its origin, so the description largely restates structured data. Baseline 3 applies; no additional format or validation detail is supplied.

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+resource (stop the seat alert) and scopes it to one flight, which separates it from stop_tracking_flight and stop_tracking_hotel by resource. It does not name those siblings explicitly, but the resource word 'seat' plus the tracking_key reference makes the domain 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?

Gives clear context: use it to cancel a seat alert, and it points to list_tracked_seats as the source of the required tracking_key. It also adds a prerequisite ('confirm first'), which is real operational guidance. It stops short of naming the related stops/update tools for the other tracking types.

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 cover safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower; the description still adds real behavioral context: alerts fire to the account's channels, alert_rule=any alerts on every move, and the traveler-confirmation gate. It doesn't state permissions beyond the confirmation requirement or what happens on repeat tracking of the same itinerary.

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?

Front-loaded with purpose and the confirmation gate, then organized by trip type, then alert behavior. It is dense and uses fragments, but every clause carries routing or behavior information; the 'any hears every move' phrasing is slightly compressed at the cost of readability.

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 tracking-creation tool with five parameters and a full output schema, the description supplies the precondition (traveler confirmation), the trip-type routing that determines the required itinerary_id, and the alert-channel semantics. Nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning the schema lacks: itinerary_id semantics differ by trip type (a one-way id watches that outbound with its cheapest return, a complete id tracks the exact pairing), and it explains how target_price_usd overrides alert_rule in operational terms.

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 and resource ('start price alerts on an itinerary') and immediately scopes it with the precondition 'from a search, after the traveler confirms'. It is clearly distinguishable from siblings like update_flight_tracking, stop_tracking_flight, and list_tracked_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?

Gives explicit per-trip-type routing rules for which source tool to pull itinerary_id from (search_flights vs search_return_flights), which is real 'when to use' guidance. It lacks an explicit exclusion such as 'use update_flight_tracking to change an existing alert' or a note on duplicate alerts.

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 cover the safety profile (non-destructive, idempotent, open-world), and the description adds a genuinely useful side-effect disclosure: alerts are pushed to the account's channels when the price drops. It stops short of saying how channels are chosen or how failures surface, but it exceeds the annotation baseline.

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, no waste. Usage and prerequisite are front-loaded, and the consequence (alerts to account channels) follows immediately after.

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 and annotations covering safety and idempotency, the description only needs to cover prerequisites and post-call behavior, which it does. A brief note on what a repeated call does (idempotent re-tracking vs duplicate alert) would round it out.

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 hotel_id, search_key, search_url, alert_rule, target_price_usd, text and email are already fully documented in the schema. The description adds nothing about parameter syntax or defaults, so the 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 verb and resource: 'start price alerts on one hotel'. The word 'start' implicitly separates it from update_hotel_tracking and stop_tracking_hotel, but no sibling is named explicitly, so an agent must infer the boundary.

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?

Clear conditions: the hotel comes 'from search_hotels for those dates' and the action happens 'after the traveler confirms'. It gives no explicit exclusions or alternative tools (e.g. add_hotel_bucket_list, update_hotel_tracking), so routing is implied rather than spelled out.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and idempotency profile is covered. The description adds genuine context beyond that: alerts are delivered to the account's channels when a watched seat opens, which tells the agent what the tool actually does over time.

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 action and purpose. The first sentence is long but each clause (modes, seats_together option) carries information; the second earns its place by describing alert delivery. No padding.

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 ten-parameter tracking-creation tool with an output schema, the description covers the action, the confirmation precondition, the seat-selection modes, and the alert behavior. Return values need not be described since an output schema exists. Minor gap: no explicit relationship to sibling tracking tools.

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 ten parameters including seat naming, seat_type, and seats_together. The description restates seats/seat_type/seats_together in prose but adds no syntax or format detail beyond the schema, so the 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?

The description states a specific verb and resource: 'start seat alerts on one flight,' which distinguishes creation from stop_tracking_seats and update_seat_tracking by the word 'start.' It does not name a sibling explicitly, so it falls short of the 5 reserved for explicit 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?

It gives an explicit precondition ('after the traveler confirms') and describes the two watch modes (named seats vs seat type), which is clear context. However, it never routes the agent away from seat_availability or toward update_seat_tracking, and offers no when-not guidance, so the usage story remains implied rather than complete.

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, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds real value beyond them: 'Only the fields given change' clarifies partial-update semantics, 'Phones are verified on the site, not here' discloses a prerequisite path, and 'Confirm first' is a behavioral instruction absent from 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?

Four short sentences, front-loaded with the actionable scope and with zero filler. 'Confirm first.' is clipped and slightly ambiguous on its own, but it is placed last where it functions as a closing instruction.

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 no explanation, and with annotations covering safety the description supplies the remaining essentials: editable fields, partial-update behavior, verification prerequisite, and a confirmation cue. It does not cover error behavior or permission requirements, which is the only real 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 description coverage is 100%, so all four parameters are already documented, and the description largely restates them ('default alert channels (email, text)', 'applied to everything already watched'). It adds the framing that channels apply to new alerts by default, but no syntax, defaults, or edge-case behavior beyond the schema, so the baseline 3 holds.

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 and resource ('change the display name, or the default alert channels') and enumerates exactly which account fields are editable. Read against siblings like update_bucket_list and update_flight_tracking, an agent can immediately tell this one mutates account-level name/alert preferences rather than trip data.

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?

'Use to change...' and 'Confirm first.' set clear usage context, and 'Phones are verified on the site, not here' rules out an adjacent action an agent might otherwise attempt. There is no explicit when-not or named alternative (e.g., get_account for reads), but the operating context is 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 flag destructiveHint=true and idempotentHint=true; the description adds the non-obvious side effect that changing the search discards deals found so far, which is genuinely useful beyond the annotations. A confirmation requirement is also surfaced. It does not detail permissions or the response shape.

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?

Front-loaded with the action and a compact enumeration, then two short constraint sentences. Every sentence earns its place; the field enumeration is slightly long but substitutes for scanning the schema.

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 and rich annotations, the description's job is mostly update semantics and side effects, both of which it covers. Missing only explicit routing to sibling tools, which is minor given the dense 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 coverage is 100% across 19 parameters, with rich per-field descriptions (units, ranges, flight vs hotel applicability), so the baseline is 3. The description's field list ('price bar, months or date window, nights, stops, airlines, preferred weekdays, name, guests, stars, channels') broadly maps to but does not enrich the schema, and 'guests' loosely corresponds to the 'adults' property.

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 (edit) and resource (bucket list) and enumerates the editable facets, so the agent knows exactly what this tool mutates. It does not explicitly differentiate from the add_*_bucket_list siblings, relying on 'edit' to imply an existing list, which keeps it just short of a 5.

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 operating context: only supplied fields change, a changed search resets prior deals, and 'Confirm first' signals a prerequisite. It does not name sibling alternatives (e.g., use add_flight_bucket_list to create), so it stops at 4.

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 (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds two pieces of context the annotations do not: that omitted fields are preserved, and that user confirmation is required before applying. It omits error behavior for an unknown search_key, 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?

Three short sentences, front-loaded with purpose, followed by the partial-update rule and the confirmation requirement. No filler; 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?

With an output schema present, return values need no explanation, and annotations cover idempotency and safety. The description supplies the partial-update and confirmation semantics, but does not signal the prerequisite that the route must already be tracked or point to track_flight/stop_tracking_flight as the alternatives.

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 search_key, the email/text flags, alert_rule enum values, and the target_price_usd total semantics. The description only names the categories of fields in prose, adding no syntax or constraint detail beyond what the schema provides; baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('change how a tracked route alerts') and enumerates the mutable surfaces (alert rule, target price, email/text channels). It clearly distinguishes updating an existing tracked route from the sibling tools that create or remove one, though it never names those siblings explicitly.

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?

'Only the fields given change' and 'Confirm first' give real operational guidance about partial updates and confirmation, which is more than most definitions offer. However, there is no explicit when-to-use guidance relative to siblings like track_flight (add) or stop_tracking_flight (remove), so usage context is only implied.

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, destructiveHint=false, and idempotentHint=true, so the mutation/safety profile is covered. The description adds meaningful context beyond them: 'Only the fields given change' clarifies partial-update semantics, and 'Confirm first' signals a required user-confirmation step. It stops short of noting permission needs or the response shape.

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 zero filler. The editable-field enumeration is front-loaded and the partial-update plus confirmation constraints follow immediately, so an agent gets the essentials in the first read.

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 annotations cover the safety/idempotency profile. The partial-update rule and confirmation requirement fill the remaining gaps for a 6-param mutation tool, though permission requirements and error behavior are left 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 every parameter including the nuances of alert_rule vs target_price_usd and the verified-phone requirement for text. The description's field list merely mirrors the schema and adds no format or constraint detail, so the 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 verb (change) and resource (how a tracked stay alerts), and enumerates exactly which attributes are editable: alert rule, target price, email/text channels, name. This cleanly separates it from the siblings track_hotel (create), stop_tracking_hotel (delete), and update_flight_tracking/update_seat_tracking (different resource).

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?

Establishes clear context ('Use to change how a tracked stay alerts') and adds a behavioral usage instruction ('Confirm first'). However, it never names alternatives or states when NOT to use this tool (e.g. use track_hotel to start tracking, stop_tracking_hotel to end it), leaving that routing to inference.

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