sbb-mcp

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the pagination direction (earlier/later) but no additional behavioral context beyond annotations.

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

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

Two concise sentences with no unnecessary words, front-loading the purpose and usage instruction.

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

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

For a simple read-only pagination tool with full annotations, the description is mostly complete. It lacks details about output format, but the tool's simplicity and annotations compensate.

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 parameters are documented in the schema. The description only reiterates the use of collection_id without adding new semantic details.

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 it loads earlier or later train connections for a previous search, using a collection ID. It is specific about the verb and resource, but does not explicitly differentiate from sibling tools like search_connections.

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 instructs to use the collection ID from search_connections results, providing clear context. However, it does not mention when not to use it or name alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds value by stating prices are in CHF, supports discount cards, and has a batch limit. It does not contradict annotations and provides useful behavioral context beyond what annotations alone convey.

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

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

Description is three sentences, front-loaded with purpose, then discounts, then usage guidance. Every sentence adds value; no redundancy or filler. Well-structured for quick reading.

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?

Without an output schema, the description explains that prices are in CHF and mentions discount support. It covers batch limits and ID provenance. While it could mention possible error cases or response format, the tool is simple enough that this is 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 coverage is 100%, and parameters include descriptions. The description does not add significant meaning beyond the schema (e.g., it mentions trip_ids source but schema already says 'from search_connections'). For reduction_card, schema describes enums, description only mentions discounts. No additional clarity beyond baseline.

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

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

The description clearly states it gets ticket prices in CHF for train connections, and the tool name 'get_prices' matches. It distinguishes from sibling tools like search_connections and get_trip_details by focusing on pricing. The phrasing 'For one or more train connections' specifies scope.

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 advises batching up to 10 trip_ids and explicitly says to use IDs from search_connections and not invent them. It provides clear context for when to use this tool, though it does not explicitly list alternatives or exclusions, the sibling list implies differentiation.

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 convey idempotency and destructive hints. The description adds valuable context beyond annotations: 'On mobile with SBB app installed, opens directly in the app with Halbtax/GA applied automatically.' This explains external behaviour and discount application, which annotations do not cover.

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: first sentence states core purpose, second adds key behavioral context. No redundant information, well-structured, and front-loaded with the primary action.

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

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

The tool has 9 parameters (7 required) and no output schema. The description does not explain the return value shape (the link), possible errors, or prerequisites (e.g., user authentication). While annotations cover some aspects, the description lacks completeness for a purchase link generator, leaving some gaps for the 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?

Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds no new parameter-level semantics beyond what the schema provides. The mention of 'Halbtax/GA' in the description relates to the reduction_card parameter, but the schema already explains that enum. 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 clearly states 'Get a direct purchase link to buy a train ticket on SBB.ch', specifying both verb and resource. It distinguishes itself from siblings by explicitly saying 'Only call this when the user wants to buy a specific ticket', which sets it apart from search or price tools like get_prices or search_connections.

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 includes an explicit usage rule: 'Only call this when the user wants to buy a specific ticket.' This provides clear context for when to invoke the tool. However, it does not explicitly state when not to use it or mention alternative tools, relying on sibling context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context such as included fields (intermediate stops, platforms, occupancy) without contradicting annotations.

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

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

Two sentences, no wasted words. The main purpose is front-loaded, and the dependency on search_connections is clearly stated.

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 tool's simplicity (one parameter, no output schema), the description fully covers what the tool returns and its prerequisite. No gaps.

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 describes the single trip_id parameter with the same wording as the description, achieving 100% coverage. The description does not add new semantic meaning 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 tool retrieves detailed info about a specific train connection, listing included data (intermediate stops, platforms, occupancy). It distinguishes from sibling tools like search_connections and get_more_connections by specifying a unique resource.

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

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

The description explicitly says to use a trip ID from search_connections results, providing clear context for when to invoke this tool. It lacks explicit when-not-to-use guidance but is sufficient for standard usage.

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 provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by noting name resolution, live schedule data, and that delays/cancellations are included for trains departing within 30 min. It does not contradict annotations.

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

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

Two sentences with no wasted words. Front-loaded with purpose, followed by input notes, output summary, and live data note. Each sentence adds necessary 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?

Given 5 parameters (all documented in schema) and no output schema, the description covers key outputs (schedules with times, transfers, IDs) and input nuances. It does not mention pagination or max results, but that may not be critical for the tool's use.

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 extra context: confirms name or ID acceptance with examples, explains name resolution, and gives detailed guidance on arrival_time (when to set true). This adds meaning beyond the schema descriptions.

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 'Find train connections between two Swiss stations' with specific verb and resource. It distinguishes from siblings by mentioning that results include trip IDs for downstream calls (pricing/details/tickets), which are separate sibling tools.

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 explains input formats (names/IDs) and the arrival_time parameter usage explicitly. It implies the tool is the starting point for journey planning by mentioning downstream uses, but does not explicitly state when to use alternatives like get_trip_details or get_prices.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds context about the output format (UIC IDs) and that the tool is used by other tools. It shows no contradiction with annotations.

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

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

The description is concise: a single sentence for purpose, a note about output format, and a clear usage guideline. Every sentence adds value, and the key information is 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?

Given there is no output schema, the description adequately explains the output format (UIC station IDs) and its relevance to other tools. It also addresses relationship with sibling tool. The description is complete for a search 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% with clear parameter descriptions. The description adds no new semantic details beyond the schema but provides helpful context about the output type (UIC IDs), which indirectly aids parameter understanding. 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?

The description clearly states it searches for Swiss train stations, addresses, or POIs by name and returns UIC station IDs. It distinguishes from sibling search_connections by noting that search_connections accepts station names directly, so this tool is only needed for explicit station info or disambiguation.

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 when to use this tool (explicit station info request or disambiguation) and when not to (search_connections accepts station names directly). This is excellent guidance for an AI agent.

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