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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that the data is 'real-time' and that chart preparation status is included, which tells the agent results are live and state-dependent, but it says nothing about failure modes (invalid/not-found PNR), auth or rate limits, or how the response is structured.

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 front-loaded sentence led by the verb and resource, followed by a tight enumeration of returned data points. The 'S4 65 LOWER BERTH' example is short and clarifies output format 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?

With no annotations and no output schema, the description is the only source of behavioral and return-value context, and it only names data categories without describing shape or error behavior. Adequate for an agent to decide to call it, but thin on what it will get back and when it will fail.

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?

There is a single parameter with 100% schema coverage, so the schema already defines 'pnr' as a 10-digit reservation number with an example. The description adds nothing about the parameter beyond what the schema documents, 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 (check) and a specific resource (Indian Railways PNR status) and enumerates exactly what data comes back — manifest, coach/berth, confirmation probability, chart status — which implicitly separates it from siblings like get_live_running_status and get_vacant_berths_post_chart. It stops short of naming any sibling 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?

Usage is only implied: you need a PNR, therefore you call this. There is no statement of when to prefer it over check_seat_availability or get_vacant_berths_post_chart, and no note about pre- vs post-chart relevance despite mentioning chart preparation.

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

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

With no annotations, the description carries the full burden; it usefully discloses the upstream source (PRS) and that the output is a 14-day continuous calendar rather than a single-date snapshot. It does not clarify whether the required 'date' parameter anchors the start of the window, nor does it mention permissions, rate limits, or data freshness.

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, front-loaded with the verb and the key scoping facts (14-day continuous, PRS, classes, quotas). 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?

For a 6-parameter, no-annotation, no-output-schema tool, the description covers source and window but leaves the response shape and the multi-date/date-parameter relationship unexplained. Adequate but with notable gaps for a forecasting 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%, so baseline is 3; the description still adds value by enumerating class codes including 3E and quota codes including LD, which the schema examples omit. It does not resolve how 'date' interacts with the 14-day window, which is the main semantic 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?

Names a specific verb and resource ('Fetch ... seat availability calendar forecast') plus a precise scope (14-day continuous, across travel classes and quotas, from PRS). This clearly separates it from siblings like search_trains or get_vacant_berths_post_chart, which concern different 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?

The '14-day continuous ... calendar' framing and 'official ... from PRS' hint at when this is the right tool (pre-booking, multi-date forecast) versus post-chart vacancy, but no sibling is named and no when-not/exclusion is stated. Usage is inferable rather than specified.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It usefully states that results are real-time and limited to today's cancellations, including fully and partially cancelled categories, but it does not describe permissions, response structure, rate limits, or empty-result behavior.

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

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

The description is a single, front-loaded sentence with no redundant or filler text. Every part contributes to clarifying the resource, freshness, time scope, and cancellation categories.

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 no-parameter, no-output-schema tool, the description gives enough context to understand what the tool returns: a real-time list of today's cancelled trains, split into fully and partially cancelled categories. It could be stronger with explicit usage guidance or return-format detail, but the low complexity makes the current description largely adequate.

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 has zero parameters, so there is no parameter semantics burden. The description correctly avoids discussing nonexistent inputs, and the empty input schema is consistent with the description.

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

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

The description states a specific verb and resource: get today's cancelled Indian Railways trains. It also scopes the data to real-time, today-only, and distinguishes fully cancelled from partially cancelled trains. The uniqueness of the resource makes it clearly distinguishable from sibling tools like get_live_running_status or check_pnr.

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

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

The description implies the tool is for users asking about today's train cancellations, but it does not explicitly state when to use it versus alternatives. No exclusions or related-tool routing guidance is provided, so the agent must infer usage from the purpose statement.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Check' strongly implies a read-only diagnostic operation, and the description names what is inspected, but it does not clarify side effects, whether it makes network calls, auth requirements, latency, or what the response contains.

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

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

The description is a single, front-loaded sentence that names the action and the three inspected areas. Every phrase contributes to tool selection, with 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 zero-parameter health/status tool with no output schema, the description gives enough information to select it and understand its broad scope. The main remaining gap is that it does not characterize the return value, but with no arguments and a clearly diagnostic purpose, this is a minor omission.

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 has zero parameters, so there is no parameter semantics to explain and the baseline score of 4 applies. The description does not need to compensate for undocumented inputs.

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

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

The description uses the specific verb 'Check' with a clear resource, 'irctc.dev Rail Engine health,' and enumerates three target areas: health, offline corpus status, and in-memory index performance. This is clearly distinct from the sibling tools, which are all train/PNR/station queries, though it does not explicitly name a sibling to differentiate itself.

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 word 'Check' implies a diagnostic or status-inspection use case, so the intended usage is reasonably inferable. However, the description does not state when an agent should call this tool, such as when other Rail Engine calls fail or when corpus/index status is relevant, and there are no explicit exclusions or 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?

No annotations exist, so the description carries the full burden; it does disclose the payload contents (delay, last crossed station, platforms, ETA/ETD), which is valuable given there is no output schema. It omits behavioral traits that matter: data freshness/refresh cadence, what happens for trains not currently running or not yet departed, and whether the optional date changes the live semantics.

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 enumerated return fields earn their place because no output schema exists to convey them.

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 2-parameter live-lookup tool with no annotations and no output schema, the description covers purpose and returns adequately. The remaining gap is edge-case behavior (train not running, stale data, date vs 'live' interaction), which an agent would need to call this reliably.

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 both train_no and date fully documented including formats and a default, so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond what the schema states, so baseline 3 applies.

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

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

Specific verb ('Get') and resource ('real-time live running GPS status of any Indian Railways train'), plus an enumeration of the returned data. The word 'live/real-time' implicitly contrasts with static siblings like get_train_schedule and get_station_timetable, but no sibling is named, so differentiation is left to inference.

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

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

The phrase 'real-time live running status' implies you should use it while a train is en route, but the description never states when to prefer it over get_train_schedule or get_station_timetable, nor any prerequisite such as the train having departed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup and lists some returned fields, but it does not mention error behavior for invalid codes, rate limits, authentication, or whether results are cached. For a simple lookup this is adequate but incomplete.

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?

It is a single efficient sentence with the primary action front-loaded. Every clause earns its place by naming the lookup key and the returned information. It could be slightly tighter but is well structured.

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

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

There is no output schema and no annotations, so the description must compensate. It names three returned fields (station name, state, railway division), which is useful, but it does not describe the full response shape or failure cases. For a one-parameter lookup this is minimally adequate.

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 schema already defines station_code with examples such as "NDLS". The description adds no format rules, case sensitivity, or validation beyond what the schema provides, so 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: get detailed station information by station code. It also names the returned fields (name, state, division). It does not explicitly distinguish itself from the sibling search_stations, but the by-code lookup scope is clear.

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 phrase 'by station code' implies this is a single-record lookup rather than a search, which gives some usage guidance. However, the description never says when to use this instead of search_stations or get_station_timetable, and it lists no alternatives or exclusions.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose scope (all trains, station-level, single date, includes through/arriving/departing), which implies a read-only query, but it says nothing about whether results are scheduled vs. real-time, ordering, result volume, or paging — meaningful gaps for an unannotated 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?

A single sentence with the core operation front-loaded and the parenthetical alias placed at the end for disambiguation. No filler and nothing to trim.

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 tool with fully documented schema, this is nearly complete — the agent knows the scope and inputs. The only shortfall is that, with no output schema, the description never indicates what fields the timetable entries contain or how many results to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both station_code and date formats (YYYY-MM-DD / DD-MM-YYYY) spelled out in the schema. The description only restates that a station and a date are required, adding no format or semantic detail beyond the schema, so baseline 3 applies.

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

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

The description names a specific verb and resource ('Get all trains passing through, arriving at, or departing from a station'), and the parenthetical 'station timetable / arrivals & departures board' removes ambiguity. It implicitly separates itself from the train-centric sibling get_train_schedule by being station-scoped, though it never names that 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?

Usage is inferable from the phrasing — an agent would pick this for an arrivals/departures board rather than a train's schedule — but there is no explicit when-to-use, when-not, or pointer to alternatives like get_train_schedule or get_live_running_status.

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

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

No annotations, so the description carries the full burden; it signals the response is 'quick ... basic details', implicitly distinguishing it from live/real-time tools like get_live_running_status. However, it never states that it is a read-only lookup, how it behaves for an invalid train number, or whether running-day data can vary — meaningful gaps for a zero-annotation 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?

One well-formed sentence with the resource and returned fields front-loaded and no filler. It could be slightly tighter ('quick train basic details' is redundant with 'official train name...'), but it is efficient.

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 lookup with no output schema, enumerating the returned fields compensates well and tells the agent what it will get back. Missing only edge-case behavior (invalid numbers, static vs. live data scope) to be 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 description coverage is 100% and the single train_no parameter already documents its 4-5 digit format with an example. The description adds no further parameter 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?

Clear verb+resource: retrieves basic train details by number, and enumerates the fields returned (name, type, origin, destination, running days, distance). It does not explicitly contrast with search_trains or search_trains_by_name, so sibling differentiation is only implicit via 'by train number'.

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 by the phrase 'by train number' — the agent must infer it should be used when a numeric train ID is known rather than a name or route. No alternatives (search_trains_by_name, search_trains, get_live_running_status) are named or excluded.

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

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

No annotations are provided, so the description carries the full behavioral burden. It signals the data source ('official IRCTC') and that multiple class/quotas are computed by default, but says nothing about whether fares are live or static, whether any authentication or rate limits apply, or how the breakdown is structured.

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 zero filler: the action, the scope (classes, quotas, origin/destination), and the authoritative source are all packed in without 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?

All required inputs are documented and there is no output schema, so the description should ideally hint at what the 'breakdown' contains (base fare, reservation charge, GST, etc.) and its likely shape per class. It names the concept but not the returned structure, leaving a moderate gap for a 5-parameter 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%, so all five parameters, their defaults, and example values are already documented in the schema. The description reinforces the class-code set (1A, 2A, 3A, 3E, SL, CC, 2S) and quota concept but adds no syntax or format meaning beyond the schema, making the baseline 3 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?

States a specific verb ('Calculate') plus resource ('official IRCTC train fare breakdown') and enumerates the covered classes and quotas between stations, so the agent knows exactly what is returned. It does not explicitly differentiate from siblings, though none of the listed siblings (PNR, availability, schedule) overlap with fare calculation.

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 by the verb and resource – there is no explicit 'use this when…' or 'do not use this for…' guidance, and no note on prerequisites such as whether the train must exist or the quota must be valid. An agent can infer the context from the name, but nothing is stated.

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

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

No annotations are provided, so the description carries the burden, and 'Get' reasonably signals a read-only lookup. It adds value by disclosing the shape of the result (halts, timings, durations, distance), but says nothing about whether the data is scheduled vs. live, coverage of days of operation, or what happens for an invalid train number.

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 core action and then a compact enumeration of returned data. No preamble or filler; it could only be improved by adding a short routing clause rather than by trimming.

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

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

With no output schema and no annotations, the description compensates well by listing the fields the caller will receive. Minor gaps remain (time format, timezone/day-of-week behavior, error semantics), but for a one-parameter lookup 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 100% and there is a single required parameter whose schema entry already gives the format and an example ("12557"). The description adds no additional meaning about train_no, which is acceptable given the schema does 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?

Starts with a specific verb ('Get') and resource ('full train route schedule') and enumerates what is returned: intermediate halts, arrival/departure timings, stop durations, and distance in km. That enumeration differentiates it in practice from get_live_running_status or get_station_timetable, though it never names a sibling 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?

The use case (fetch the static route/timetable of one train by number) is strongly implied by the field list, so an agent can infer when to reach for it. There is no explicit when-to-use statement, no exclusions, and no pointer to get_live_running_status for real-time position, which is the most likely confusion point.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: the data is real-time, sourced from online reservation charts, and only valid post-chart-preparation. However, it does not say what happens if the chart is not yet prepared, whether data is scoped per train/date, or what the response contains.

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 with the key qualifier ('after chart preparation') front-loaded and no filler. The trailing jargon ('Current Booking and TTE allocation onboard') is dense but still conveys who uses the data.

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 4-parameter read tool with no annotations and no output schema, the description establishes purpose and timing but leaves gaps: no statement of what happens pre-chart, no hint at return shape (per-class vacancy counts?), and no linkage to the sibling availability tool. Adequate but not 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 description coverage is 100%, so all four parameters (date, train_no, class_code, boarding_station) are already documented with formats and defaults. The description adds no parameter-level meaning such as how boarding_station affects the returned vacancy pool, so baseline 3 applies.

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

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

Specific verb ('Find') plus resource ('real-time vacant berths and seats') with a clear temporal scope ('after chart preparation'). It implicitly separates itself from check_seat_availability by emphasizing post-chart data from reservation charts, but never names that sibling, so an agent must infer the distinction.

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

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

The phrase 'after chart preparation' and 'Current Booking and TTE allocation onboard' implies the usage context, but there is no explicit when-to-use versus when-to-use-alternative guidance. An agent cannot tell from the text whether to prefer check_seat_availability before the chart is prepared.

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

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

With no annotations, the description carries the full burden, and "Autocomplete" does signal partial/fuzzy matching and that multiple results may come back. However, it says nothing about result limits, ranking, case sensitivity, or empty-result behavior for a lookup 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?

One sentence, front-loaded with the verb and resource, with the examples placed where they clarify the input domain. Zero waste.

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

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

For a simple one-parameter lookup with no output schema, the definition covers what the tool is and what input it takes. It omits what comes back (a list of station code/name pairs) and how partial matches are ranked, which would help an agent consume the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is fully documented, so the schema does the heavy lifting. The description's examples ("NDLS", "delhi", "patna") mostly repeat the schema's own example rather than adding format or matching semantics.

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 and resource ("Autocomplete search Indian Railways stations") and scopes the input domain to station code or partial city name, which an agent can distinguish from general train search siblings. It doesn't explicitly name the near-neighbor get_station_by_code, so it stops 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?

The word "autocomplete" plus the partial-name examples imply the discovery/browse use case, but there is no explicit statement of when to prefer this over get_station_by_code or search_trains. Usage context is only inferable, not stated.

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

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

No annotations exist, so the description carries the full burden, and it does disclose what the response contains (departure/arrival times, duration, distance, running days, fare estimates) in lieu of an output schema. It omits limits, pagination, result caps, and what happens for invalid or ambiguous station codes.

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 with the verb and scope front-loaded followed by the returned fields; 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 3-parameter read-only lookup with full schema coverage, the description covers purpose and return content adequately. The only gaps are edge-case behavior and any routing guidance against the many sibling lookup 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 coverage is 100% with per-parameter descriptions and examples, so the schema already defines from/to/date fully. The description adds the semantic that both are station codes but never mentions the optional date parameter or its format.

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 (search) and resource (trains) plus the exact scoping mechanism: two Indian Railways station codes. This implicitly separates it from search_trains_by_name and get_train_by_number, but no sibling is named 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?

Usage is only implied by the phrase 'between any two Indian Railways station codes'; there is no statement of when to prefer this over search_trains_by_name, get_train_schedule, or get_live_running_status, and no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses partial-match behavior and gives examples, but it does not describe result limits, case sensitivity, pagination, or what the response contains.

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 efficient sentence with the core action and matching mode front-loaded. The examples add clarity without bloating the definition.

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

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

For a simple one-parameter search tool with no output schema, the description is sufficient to invoke it correctly. It leaves out return-shape and result-limit details, which are minor but would help an agent understand what to expect.

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 single parameter is already documented as a train name with a two-character minimum. The description adds partial-match semantics and examples, but no additional formatting or matching details beyond the schema.

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

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

States a specific verb and resource: search Indian Railways trains by train name query. The partial-match examples (“Rajdhani”, “Shatabdi”, etc.) make clear this is name-based lookup, distinguishing it from get_train_by_number.

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

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

The description implies when to use it by specifying name-query partial matching, but it does not explicitly contrast with sibling tools such as search_trains or get_train_by_number. An agent can infer the use case, but alternatives are not routed.

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