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

With no annotations provided, the description carries the full transparency burden. It clearly discloses the data source (SBB PRM), the limitation (no vehicle/wagon-level accessibility), and the scoping (endpoint stations only), preventing users from over-trusting the 'accessible' label.

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 two sentences: a direct purpose statement and a compact note with a necessary caveat and alternative. Every sentence 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?

An output schema is present, so return-value details are covered structurally. The description addresses purpose, limitations, and data source, making it sufficiently complete for a 3-parameter tool with a clear use case.

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

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

The input schema already describes all three parameters with 100% coverage, so the description does not need to repeat them. The description adds no extra syntax or format details beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific action: find connections and annotate them with station-level accessibility info. The scope (station-level, endpoint stations only) is explicit and distinguishes it from generic connection tools like get_connections and from wagon-level alternatives.

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 alternative for wagon-level accessibility: SBB's official 'Reisende mit Handicap' service. The opening sentence implies this is the station-level route-finding tool, but it does not explicitly name sibling tools like get_connections or state when to prefer this over them.

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 provided, the description carries the full burden of behavioral disclosure. It excellently discloses that the bike-allowed status is a 'heuristic only,' details assumptions per train category (S/RE vs IC/EC/ICE vs buses/trams), and advises verification on sbb.ch/velo. This is thorough and honest about limitations.

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 concise and front-loaded with the primary purpose in the first sentence. The subsequent heuristic explanation is directly relevant and earns its place, providing necessary caveats without unnecessary verbosity. Every sentence adds value.

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?

The description is complete for the tool's complexity. It explains the core behavior (annotating legs with bike heuristics), discloses limitations, and the output schema presumably covers return values. No critical information 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%, with all three parameters (from_station, to_station, limit) already documented in the input schema. The description adds no additional parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description states a specific verb+resource+scope: 'Find connections and annotate each leg with a bike-allowed heuristic.' This clearly distinguishes it from sibling tools like get_connections (which likely just finds connections) and accessible_route (focused on accessibility). The purpose is unambiguous and concrete.

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 usage for bike-related routing queries by explaining the heuristic's behavior and providing a verification note. However, it does not explicitly mention when to use this tool over alternatives or provide exclusions. The context is clear but lacks explicit 'use instead of' 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?

No annotations are provided, so the description carries the full burden. It discloses data sources (opendata.ch + SBB) and scope (home to work, active disruptions), but doesn't elaborate on return format, pagination, freshness, or potential side effects. For a read-only snapshot this is acceptable but not rich.

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

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

The description is compact and front-loaded, containing a clear headline, a practical usage example, and a data-source note in just two sentences. No wasted words.

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 two-parameter tool with an output schema, the description covers purpose, usage, and data context. It could add nuance about what 'next connections' means or how disruptions are prioritized, but the essential context is present.

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 parameters already described as starting and ending points. The description adds the directional 'home → work' framing but no additional syntax or format details, 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?

Description clearly states what it does: 'Daily commute snapshot: next connections home → work plus any active disruptions.' It uses a specific resource (commute) and differentiates from siblings by explicitly combining connections and rail-traffic information.

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?

Provides explicit when-to-use context: 'Use this tool for a quick morning sanity-check.' It doesn't name alternatives or say when not to use it, but the combination of connections and disruptions makes the use case clear.

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 burden of behavioral disclosure. It reveals that the tool returns one or more canonical station records and can disambiguate, which adds value beyond an obvious search. However, it does not explicitly mention read-only behavior, result limits, or error handling, though the presence of an output schema covers return expectations. Overall, the description gives sufficient behavioral context for a non-destructive search 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?

The description is two sentences long, front-loaded with the core purpose and followed by concise usage guidance. Every sentence earns its place with no redundancy or unnecessary 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?

For a simple one-parameter tool with an output schema, the description fully covers purpose, usage context, and relationship to sibling tools. It is complete and self-sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% and the parameter description already covers name fragments and language support. The tool description adds the concepts of partial matching and disambiguation, but these are largely implied by the schema's 'fragment' wording. Thus the description offers marginal additional semantic value 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?

The description clearly states the verb (Search) and resource (Swiss public transport stations) with a scope qualifier (by name or partial name). It also distinguishes itself from sibling tools by explicitly mentioning its role as a resolver before get_connections or get_stationboard and its disambiguation capability for similar station names.

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

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

The description provides explicit when-to-use guidance: resolve place names before calling specific sibling tools (get_connections or get_stationboard) and disambiguate similar names. This gives clear context and names alternatives, meeting the 'explicit when/when-not/alternatives' criterion.

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 transparency burden. It reveals a useful behavior: 'Station names are resolved by the upstream API, so common spellings work directly.' It also implies a temporal scope via 'upcoming' and 'from now.' It does not disclose error handling or limits beyond schema, but for a read-only tool, this is adequate.

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 two concise paragraphs. The first sentence states purpose; the second provides usage context and examples. Every sentence earns its place, with no redundancy or filler. Structure is front-loaded with the core function.

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 5 parameters and an output schema present, the description sufficiently covers purpose, usage scope (Switzerland), and a key behavioral quirk (station name resolution). It does not describe potential failure modes or return value structure, but the output schema likely handles that. Minor gaps exist but are not critical given the tool's simplicity.

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 adds value by explaining that station name parameters accept common spellings, reducing ambiguity for from_station and to_station. The examples also illustrate how date/time interpret relative requests, though schema already covers syntax. Overall, it enhances parameter understanding 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?

The description starts with a specific verb and resource: 'Find upcoming train, tram, bus, or boat connections between two stations.' It clearly distinguishes the tool's scope from sibling tools like get_stationboard (which likely focuses on a single station's departures) by emphasizing connections between two named places.

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 states when to use the tool: 'Use this tool when the user asks for travel options between two named places in Switzerland' with concrete examples. It also clarifies that station names are resolved upstream, preventing unnecessary pre-resolution via find_station. No alternatives are mentioned, but the guidance is clear and actionable.

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 provided, the description carries the full burden for behavioral disclosure. It conveys that results are 'currently active' and cites the SBB feed, providing some context. Yet it omits details like response format (though output schema exists), potential latency, or any limitations beyond 'active' status. It is adequate but not rich.

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 extremely concise—two well-structured sentences that front-load the purpose, provide usage triggers, and mention the source. Every sentence adds value, and there is 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 simple two-optional-parameter tool with an output schema, the description is complete. It clarifies the temporal scope ('currently active'), geographic scope ('Swiss network'), and provides practical example queries. It paints a full enough picture for an agent to select and invoke the tool correctly.

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

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

The input schema has 100% coverage for both parameters (limit and scope) with detailed descriptions. The tool description itself does not add any extra parameter semantics or examples, so the baseline of 3 is appropriate.

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

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

The description states a clear action with a specific resource: 'Return currently active rail-traffic disruptions on the Swiss network.' It mentions the scope ('Swiss network') and distinguishes itself from sibling tools focused on stations, connections, and stationboards.

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

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

The description provides explicit use-case examples ('are there any disruptions today?', 'is the line to X working?'), giving clear context for when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of 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?

No annotations are provided, so the description carries the full burden. It only explains the metric (average daily passengers) but does not disclose whether data is historical/live, authentication needs, error handling, or an explicit read-only statement. The 'Return' verb implies read-only, but lacks context that would help an agent anticipate 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 two sentences, front-loaded with the core purpose and followed by usage guidance. No redundancy or filler; every sentence 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?

For a simple one-parameter tool with an output schema, the description covers purpose and usage triggers. However, it lacks caveats about data recency or station name matching, and there are no annotations to fill those gaps. It's reasonably complete but not perfect.

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

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

The input schema fully describes the 'station' parameter with an example, giving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states what the tool does: returns average daily passenger count ('how busy a Swiss station typically is'). It uses a specific verb ('Return') and resource, and it is distinguishable from sibling tools like get_stationboard (which provides schedules) and get_connections (which provides routes).

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 second sentence gives explicit triggers: 'Use this tool when the user asks "how busy is X?", "is it a major station?", or wants context for travel-time/connection planning.' This provides clear context but does not name alternatives or explicitly state when not to use, so it falls just 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?

No annotations are provided, so the description carries the transparency burden. It discloses that departures are live, which is useful, but does not mention potential limitations like delays, cancellation status, or data source. For a simple read-only tool this is adequate but not rich.

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 two sentences, front-loaded with the core purpose, and contains no redundant wording. Every clause contributes meaning.

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?

The tool is simple, has full schema coverage, and an output schema describing return values. The description covers the main use case and constraints, making it complete for its complexity level.

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

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

The schema already fully describes both parameters with examples and defaults, so the description adds no extra parameter context. This matches the baseline of 3 when schema coverage is high.

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

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

The description clearly states the tool shows next departures from a station, using specific verbs and a resource. It distinguishes itself from siblings like get_connections by noting it applies when the user has no target destination in mind.

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 usage triggers are provided ('what's leaving from <station>?') along with a clear contrast to destination-based queries. This gives the agent actionable guidance on when to select this tool over 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?

With no annotations provided, the description carries the full burden of explaining behavior. It does so by specifying that it reports fixed facilities (a read-only operation) and enumerates what those facilities are. It does not discuss edge cases or data caveats, but the scope is clearly a non-destructive lookup, and the description adds value beyond the tool name.

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 exactly two sentences: the first states the tool's function, the second provides usage guidance and examples. Every sentence adds value, with no redundancy or fluff, making it appropriately concise and front-loaded.

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

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

For a single-parameter tool with an output schema, the description covers the function, the scope (Swiss stations), and the intended trigger contexts. It does not discuss failure modes or alternatives to the 'station' parameter, but the simplicity of the tool and presence of an output schema make that acceptable.

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 single parameter 'station' is fully described in the schema (100% coverage), and the tool description does not add additional semantic detail beyond that. Since the schema already provides the parameter meaning, 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 opens with a specific verb ('Report') and resource ('fixed facilities at a Swiss station'), and lists concrete facility types (elevator, WiFi, step-free access, waiting room). This clearly distinguishes it from sibling tools like get_stationboard or get_connections, making the tool's purpose 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?

The description explicitly tells the agent when to use this tool: 'when the user asks about accessibility, amenities, or what to expect at a station,' and gives two example phrasings. It does not explicitly name alternatives or exclusion criteria, but the trigger context is clearly delineated, earning a 4 rather than 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?

With no annotations provided, the description carries the full burden. It discloses the internal behavior: 'Books the first leg ending at the layover, then the next leg starting at layover_minutes after arrival.' This explains the mechanism without requiring inference, though it omits edge cases like connection infeasibility.

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 two short paragraphs: a crisp one-line summary followed by usage examples. Every sentence contributes, and it is front-loaded with the core purpose. No wasted words.

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?

The tool has 4 required params, no annotations, but an output schema does exist, so return values don't need explanation. The description covers purpose, usage, and mechanism. It lacks explicit exclusion of alternatives or edge-case handling, but for a booking tool, the core is complete enough to guide an agent.

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?

Since schema coverage is 100%, the baseline is 3. The description adds value by clarifying layover_minutes as 'after arrival' and explaining how the four parameters interrelate (first leg ends at layover_station, next leg starts after lag). This goes beyond the schema's simple field labels.

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

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

The description opens with a specific verb and resource: 'Chain two connections with a deliberate layover at a chosen station.' It clearly distinguishes this from sibling tools like get_connections by focusing on intentional layovers and the chaining of two legs.

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 explicitly states when to use the tool: 'Use this tool when the user wants to break a journey on purpose' with concrete examples (grab food, meet someone, sightsee). It provides clear context but does not name alternative tools or when not to use it, 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool looks at connections departing around 22:00 or after_time, returns the latest one, and includes a human-readable summary. This explains the search window and output format, adding context beyond a minimal description. It doesn't clarify 'realistic' or edge cases, but core behavior is transparent.

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 two sentences, front-loaded with the main purpose, then usage guidance and behavior. Every clause earns its place with no filler or redundancy.

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 are specified elsewhere. The description provides sufficient context for selection and invocation: parameters are in schema, and behavior is described. Minor gaps like no-train results are not addressed, but for a simple tool this is 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 input schema provides descriptions for all three parameters, including home_station, current_station, and after_time with format and default. The description adds only a general reference to 'back to home_station' and 'after_time' but no additional syntax or detail beyond the schema, so the baseline of 3 applies.

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

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

The description states 'Find the latest realistic train back to home_station tonight' — a specific verb, resource, and scope. It clearly distinguishes from siblings like get_connections by focusing on the last train home, and from plan_evening_out by its single-query nature.

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

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

It explicitly says 'Use this tool when the user asks "when's the last train home from <X>?" or wants reassurance about staying out late.' This gives clear triggering scenarios. It doesn't explicitly name alternatives, but the intent 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?

With no annotations, the description carries the full burden. It discloses that the tool provides outbound options and a 'safest last train' return, and it considers the user's latest_return_time. However, it does not mention edge cases like no viable return or how 'safest' is determined.

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 core purpose, no redundant words. Every sentence 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?

Given the simple 3-parameter tool with an output schema, the description is sufficient for an agent to understand the tool's purpose and invocation context. It could mention what happens if no return option exists, but that is an edge case not necessary for basic usage.

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. The description reinforces parameter roles (home vs. destination station, latest return time as a constraint) but does not add new syntax or format details 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?

The description states a specific verb and resource: 'Plan an evening out' with 'outbound options now plus the latest viable return.' This clearly distinguishes it from sibling tools like last_train_home (which focuses only on return) by combining outbound and return planning in one tool.

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 guidance: 'Use this tool when the user is thinking about going somewhere for the evening and wants to know both how to get there and the safest last train back home.' This is clear context, but it does not explicitly mention when not to use it or name alternative tools.

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