Paytm Travel

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds non-obvious behavior beyond that: the fare is repriced server-side and the response includes a Paytm booking link, which an agent would not infer from annotations alone.

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 compact sentences, with the core action and output front-loaded in the first. The second sentence is caller-oriented context rather than agent guidance, so it earns slightly less than a fully front-loaded description would.

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 enumerated, and annotations carry the safety semantics. What remains thin is token sourcing and pairing constraints, but for a two-parameter read tool this is close to sufficient.

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 0% for two required token parameters, so the description must compensate. It partially does, mapping the tokens to an 'onward + return flight pair', but never explains token provenance, format, or that the two must belong to the same itinerary — leaving a real gap.

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 ('Computes the combined round-trip fare for a chosen onward + return flight pair'), plus two secondary behaviors (repricing, returning a total and booking link). This is clearly distinct from sibling tools like fare_calendar, get_fare_family, and search_flights without needing to name them.

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 triggering condition: 'Used by the flight results card when both legs are selected,' which tells the agent the tool only applies once both an onward and a return leg exist. It does not name alternatives or state when NOT to use it (e.g., one-way itineraries), so it falls short of explicit routing 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds substantive behavior beyond that: the result is fare-per-date rather than flight listings, and roundtrip also returns the return leg. It omits any range limits, caching/pricing freshness, or pagination behavior, so it is strong but not exhaustive.

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-loads what the tool returns, then formats, then routing to search_flights. The trailing sentence about the card placement is longer than needed and partly decorative, but it does encode real routing context rather than 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?

An output schema exists, so return-value documentation is not required, and the description covers purpose, formats, trip types and the sibling alternative. What's missing is operational context such as any maximum range length or fare-freshness caveats, which matter for a date-range calendar query.

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 are already documented, and the schema itself supplies the IATA examples (DEL, DXB) and YYYY-MM-DD format. The description restates those conventions rather than adding new semantics (e.g. whether cabin affects which cheapest fare is returned, or how trip_type pairs with start/end dates). 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 and resource ('shows a Paytm fare calendar: the cheapest flight fare for every date in a range') and explicitly disambiguates from the closest sibling by saying it 'lists no individual flights; requests to show or find flights are served by search_flights.' An agent can route correctly 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?

Gives explicit when-to-use ('spot the cheapest days to fly', cheapest *dates/days*) and when-not ('requests to show or find flights are served by search_flights'), plus the alternative. It even explains the intended UI relationship to the search_flights card, which tells the agent when a calendar result is expected.

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, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: it runs an Azure OpenAI call inside the server, makes no bus-details calls, tolerates an empty line, and only re-fetches the route when the search_context handoff is absent. It does not mention latency, token cost, or failure behavior of the LLM 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?

Front-loaded with the core action and kept to three dense sentences, with the search_context handoff highlighted. There is mild redundancy between 'from the search payload already fetched (no bus-details calls)' and the later statement that no second search is needed.

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 the description covers the call flow and dependency ordering well. For an 18-parameter tool, however, it leaves the input contract almost entirely undocumented, which is a meaningful completeness gap even if it is not the description's only job.

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 0% across 18 parameters, so the description must carry the burden and largely does not. It only illuminates search_context (the preferred handoff from search_buses); required inputs like trip_refs, cards, source, destination, date, and the many filter parameters are left entirely unexplained in both schema and description.

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

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

States a precise verb and resource: it builds one differentiating summary line per bus for the results card, using Azure OpenAI inside the server. It also distinguishes itself from siblings by noting it renders no card of its own and that it consumes search_buses output rather than making its own searches.

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

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

Gives a clear call context ('used by the bus results card after it renders') and a preference rule ('prefers the search_context that search_buses returned, so no second search is needed'), plus the fallback condition ('re-fetches the route only when that handoff is missing'). It stops short of stating explicit exclusions or when not to call it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: what the sheet contains, that booking/payment and seat maps are deliberately excluded, and that a Checkin hand-off link is involved. It stops short of describing pagination or latency, but the safety-critical surface is well covered.

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 resource and its contents, then usage, then required/optional params. Every sentence carries information, though the middle sentence is dense enough that a reader must parse several clauses to extract the routing rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the description still covers contents, required/optional inputs, and scope exclusions. It is nearly complete for invocation; the only omission is any mention of the booking_deeplink parameter, which the schema carries on its own.

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 meaning the schema does not: trip_ref must be 'the opaque tripRef from the prior search_buses card, matched exactly,' and it frames summary and booking_url by their origin on the card. It omits booking_deeplink entirely, though the schema documents it.

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 ('Shows the Bus Details sheet for one trip from search_buses') and enumerates the payload it surfaces: amenities, pickup/dropping points, cancellation slabs, rating, CTA. It explicitly positions itself relative to search_buses, so an agent can distinguish it from the search sibling 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?

Names the trigger conditions ('source for amenities, boarding/dropping points, cancellation policy, or details for a specific bus, including a tap on a bus card in the widget') and rules out an unnecessary alternative call ('The tripRef from the card is enough, without a new search_buses call'). It also bounds scope with 'No seat map or payment in chat — booking continues on Paytm Checkin'.

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 give read-only/idempotent/openWorld=false, and the description layers on traits those annotations cannot express: token expiry, exact character-for-character matching, that a retyped or merged value fails, that a short offerRef is legitimate rather than an error or internal id, that a round trip requires BOTH tokens, and that errors require a fresh search_flights. This is materially more than the structured fields provide.

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

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

Purpose and the two accepted token forms are front-loaded, and most sentences carry non-obvious operational detail. It is long for a two-parameter tool and has some redundancy, re-explaining the short-token rationale in two separate places, but it avoids boilerplate and every paragraph adds usable guidance.

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-shape explanation is not owed. The description covers the remaining agent-facing gaps: how to obtain and pass the input, error/expiry recovery, the handoff to get_flight_review with the exact argument mapping, and that one result answers later fare questions about that flight.

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 already document the long-token/short-offerRef duality, so the baseline is 3. The description still adds operational meaning the schema does not: the short form is deliberate widget behavior (not a mistake), values are matched exactly, and return_offer_token is mandatory for round trips even though the schema marks it optional with an empty default.

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 first sentence names a concrete verb and scope ('Fare family / branded fare selector for ONE specific flight') and the description enumerates the exact user phrasings it answers (fare families, branded fares, 'what do I get for more'). It explicitly contrasts itself with get_flight_details (policy detail) and get_flight_review (continuation), so an agent can separate it from siblings without opening a 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?

Timing is stated precisely: 'typically straight after search_flights or when the traveller taps the fare CTA in the results widget', with a named exclusion ('Policy detail ... comes from get_flight_details instead') and a named follow-on ('Continue ... leads to get_flight_review'). It also says when NOT to re-call: 'A repeat call for the same flight re-renders the same widget ... only a different flight needs a new call.'

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, so the safety profile is covered. The description goes further by disclosing value-validation behavior that annotations cannot express: exact character-for-character matching, expiry, rejection requiring a fresh search, and that an onward token is invalid for the return leg. This is genuinely additive, though it omits any rate-limit or error-response detail.

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 usage before the input rules, and each sentence carries distinct information (contents, triggers, token forms, failure modes, expiry). It is dense and slightly long, but the only mild redundancy is restating that the search summary lacks these details.

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 values, and it instead covers what the schema cannot: when to call, which token forms are valid, round-trip handling, and expiry behavior. Nothing an agent needs to invoke 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 coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: the short `offerRef` is ~30 characters, a short value is a legitimate input rather than an internal id, the two tokens resolve identically, and matching is exact so retyped or merged values fail. This clarifies the accepted value forms in ways the schema description only gestures at.

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 ('Fare options and travel policies for one flight') and enumerates the concrete contents (multi-fare upsell, baggage, cancellation, reschedule tabs). It also explicitly separates itself from search_flights by noting the summary 'carries none of these', so an agent can route 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?

Gives explicit trigger conditions: right after search_flights, or when the traveller taps Fare options in the widget, and states the identifiers already returned are enough without a new search. It effectively names search_flights as the prerequisite alternative rather than leaving it 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, so the safety bar is already met. The description adds real behavioral context beyond that: the review call refreshes the fare before handoff, the total originates from this call, and the review page always precedes the Paytm handoff. It stops short of describing latency or failure modes, so 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?

Leads with what the page shows, then usage, then parameters — well front-loaded and dense with non-redundant facts. It is long, and the handoff-ordering point ('review page comes before any handoff') overlaps with the earlier 'refreshes the fare before handoff' sentence, costing it a point.

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 7-param tool with an output schema and full annotation coverage, the description supplies everything else an agent needs: workflow position, token semantics, the recommended-fare fallback, and round-trip handling. Return values can be left to 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?

Despite 100% schema coverage, the description adds meaning the schema does not: offer_token may be the long signed token or the short offerRef and "a short value is valid, not an internal id", it must be matched exactly, and omitting price makes the tool fetch the recommended best-value fare. It also explains price/fare_name are used verbatim and that Saver vs Flexi map to different Paytm ids.

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

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

Specific verb+resource: shows the flight details/review page for a selected fare, and enumerates what it renders (itinerary, fare breakdown, refundability, Book link). It explicitly positions itself relative to siblings (after get_fare_family, before Paytm handoff), so an agent can distinguish it from get_flight_details and get_fare_family 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?

Names the exact triggering utterances ("continue, review, see flight details for a chosen fare, or book after picking a fare") and the fare-family Continue CTA that lands here. It also states what is NOT needed (no new search or fare-family call to settle on a fare), giving both when-to-use and when-not.

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 safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuine context beyond that: the relay mechanism, the sandbox limitation, and that the server selects the ingest endpoint. However, it says nothing about auth, retries, what happens on failure, or why the operation is non-idempotent, which matters for a write tool.

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 that are front-loaded with the core action and rationale. Nothing is padded, though the final clause about the server choosing the endpoint and accepting a batch is slightly redundant with the opening.

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. But this is a non-idempotent write tool with an opaque string body and an undefined headers object at 0% schema coverage, and the description does not close that gap. It is minimally sufficient for an agent that already knows the Signal batch format, but not self-contained.

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 0% for both required parameters. The phrase 'accepts a Signal analytics batch' loosely maps 'body' to the batch payload, but gives no format, encoding, or structure detail. The 'headers' parameter is entirely unexplained, and its role (auth, content type) is left to inference.

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 specific verb and resource: it 'sends the results cards' interaction analytics to Paytm's first-party Signal ingest.' It also explains the relay rationale (the card sandbox cannot reach the ingest), so an agent can tell this is a telemetry proxy rather than a search tool. It does not explicitly contrast with any sibling, but the sibling set (flight/bus search tools) is unrelated, so differentiation is moot.

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

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

Usage is only implied: 'The cards' analytics script calls this' suggests it is invoked by the analytics script rather than directly by an agent. There is no explicit statement of when to call it, prerequisites, or what to do instead. Adequate context but no actionable routing 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description layers substantial extra behavior on top: ambiguity returns needsDisambiguation with city options instead of a guess, invalid filters are rejected rather than ignored, ratings under 15 reviews are hidden not negative, filters that match nothing open a second results card, and booking happens off-chat via bookingUrl/bookingDeeplink.

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?

Purpose and scope are front-loaded, and most sentences carry operational rules. It is nonetheless a dense block with some repetition (the no-booking constraint is stated twice, and city-disambiguation is restated at length), which costs it the top mark.

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, and the description still covers the tricky edge cases: disambiguation re-call with source_city_id/destination_city_id, filter rejection, empty-filter results, and where booking completes. Nothing an agent needs to invoke 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?

With 100% schema coverage the baseline is 3, but the description adds decision rules the schema does not encode -- notably that bus_type should stay at climate level unless the traveller named a berth ('a berth they did not name narrows the search wrongly') and the exclusive end / no-midnight-crossing semantics for departure windows.

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?

Opens with a specific verb+resource ('Searches live Paytm bus routes') and enumerates the result-card contents, plus an explicit scope statement ('One-way, domestic, search only -- no seat selection or booking'). It is clearly distinguishable from siblings like search_flights (same posture, different domain) and get_bus_details (per-trip questions).

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: get_bus_details answers per-bus amenities/boarding/cancellation questions 'without a new search', while refining filters is 'a new search with the changed filters and the same route and date'. It also states the mandatory-args precondition and that missing values must come from the traveller, not a guess.

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 the description adds substantive behavior: nearby airports excluded server-side and counted in search.excludedAlternateAirports, invalid filter values rejected with an error, round-trip pair validity rules (no overlap, ≥2h buffer), international itineraries only as pre-stitched combos, and that every filter is echoed in structured_content.search.

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-loads purpose and filters before deep sections, and nearly every sentence carries actionable constraint detail (buckets, airports, budget, refinement). It is nonetheless very long and could be tightened, with some redundancy between the schema descriptions and the prose transport of the same rules.

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 restated; the description instead covers the complex behaviors an agent needs — date resolution, time-window mapping, airport exclusion, budget scope, and refinement semantics. Nothing material 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 coverage is 100% (baseline 3), but the description adds real meaning beyond it: time_slot buckets with no night slot and outbound-only scope, depart_before exclusivity with worked examples, midnight-crossing rule, return-leg equivalents, and that max_price is the COMBINED both-legs total on round trips.

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?

Opens with a specific verb+resource+output: 'Searches live flights on Paytm and shows an interactive results card (airlines, logos, timings, stops, fares).' It explicitly claims the 'show/find/list flights' intent and distinguishes itself from fare_calendar, get_fare_family, and get_flight_details, so an agent can route 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 trigger phrasing ('show me flights HYD to BLR'), an explicit exclusion ('fare_calendar on its own covers cheapest dates and lists no flights'), and named alternatives for fare-family and policy questions. It also states that refining results is a new search with changed filters, not a pointer to suggestion chips.

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