rossbus — buses across Russia

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

No annotations are given, so the description carries the full burden. It discloses sorting behavior, the optional budget filter, and the inclusion of price per kilometer. However, it does not mention limit defaults, output format, or error behavior, leaving a moderate transparency gap.

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

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

The description is a single, compact sentence with an illustrative example. It front-loads the core behavior and avoids unnecessary details, though it could arguably be a bit more 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?

For a simple three-parameter tool with no output schema, the description covers the primary return values: destinations, ticket prices, and price per kilometer. Missing details such as the default result limit and whether max_price_rub is inclusive are minor but prevent a perfect score.

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 describes 'from' and 'max_price_rub'. The description adds context for these by restating the budget filter and giving an example, but the 'limit' parameter has no schema description and is also not explained in the tool description. With 67% schema coverage, this leaves a noticeable 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?

The description clearly states that the tool returns destinations from a city ordered by ascending ticket price, optionally within a budget, and includes price per kilometer. It identifies the resource and operation well, though it uses a noun phrase rather than an explicit imperative verb. It is distinct enough from siblings like get_route and search_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 description provides a concrete example ('куда уехать из Казани до 1000 ₽'), which clearly suggests when to use the tool: when the user wants cheap destinations from a city, possibly under a budget. It does not explicitly exclude alternatives, but the intended context is 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?

No annotations are provided, so the description must carry the behavioral burden. It only adds a data-source note ('according to the partner's schedule') but does not disclose limit behavior, ordering, date range, default values, or failure modes.

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 one concise sentence with no redundant words. The core data fields are front-loaded, and the partner-schedule qualifier is supplementary. It is appropriately sized for the tool's simplicity.

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, the description and schema identify the required city parameter and the general output, but gaps remain: the meaning of 'limit', the time period covered, and the output structure are unspecified. Since there is no output schema, these omissions matter. Overall, it is minimally 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 50%; only 'city' is described in the schema. The description adds no explanation for the 'limit' parameter, its effect on returned directions, or its default value. The description does not compensate for the undocumented parameter.

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 output content: first/last departure and number of trips per direction, which identifies the tool's specific resource. It distinguishes this from siblings like search_routes and find_transfer, though it lacks an explicit verb, relying on a noun phrase.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention sibling tools, exclusions, or typical use cases, leaving the agent to infer usage from the name and description alone.

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 behavioral burden. It discloses that the tool computes the cheapest option through one transfer city and includes prices for both legs. However, it does not describe output format, pagination, or behavior when no transfer route is available.

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 tight sentence that front-loads the usage condition and clearly states the result. Every word contributes value, with no repetition of the title or schema.

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

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

Given the absence of an output schema, the description does well by specifying the result type: cheapest option via one transfer city with prices for both legs. It could be more complete by indicating what happens when no transfer route exists, but it is sufficient for a simple two-parameter 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%: both parameters are described identically in the schema as city names or slugs. The tool description adds no parameter-specific meaning beyond that, so the baseline score 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 clearly states the tool finds the cheapest route via one transfer city with prices for both legs, specifically for cases when no direct bus exists. This distinguishes it from direct-route and destination-ranking siblings like search_routes and cheapest_destinations.

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

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

The opening phrase 'Когда прямого автобуса нет' gives a clear condition for when this tool is appropriate. It does not name alternatives explicitly, but the context makes the intended usage obvious relative to direct-route tools.

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. It usefully specifies the data source (OSRM), the metric types (road distance and car time), and the bus-availability check. Still, it does not mention return shape, units, potential failure behavior, or that this is a safe read-only operation.

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, dense sentence that states all main outputs without filler. Every part contributes to understanding what the tool computes.

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-string-parameter tool, the description covers the core returned values — distance, driving time, and direct bus existence. It lacks explicit detail on units and result format, and there is no output schema to compensate, so the completeness is good 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?

Schema description coverage is 100% — both 'from' and 'to' are already documented as Russian city names or slugs. The description adds no additional parameter meaning, 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 clearly lists what the tool returns — road kilometers via OSRM, driving time, and direct bus availability — making its function easily understood. The title 'Расстояние между городами' reinforces the scope. However, it is a noun phrase rather than an explicit verb statement and does not name how it differs from siblings like get_route or search_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?

No guidance is given on when to use this tool versus its siblings. With tools like get_route, find_transfer, and search_routes nearby, the description does not help an agent select between 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 behavioral burden. It discloses two genuine traits: it returns only real data and it will offer a transfer when no direct route exists. However, it does not cover error behavior, rate limits, response structure, or how the transfer suggestion is represented, leaving notable gaps.

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, each carrying distinct value: the first enumerates return fields, the second adds the real-data guarantee and transfer fallback. It is front-loaded, concise, and free of 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 tool with no output schema and no annotations, the description lists the types of information returned and the fallback behavior, but it does not describe the response format, how transfers are structured, or how edge cases are handled. Parameter coverage is excellent in the schema, but the overall context has moderate 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 already describes all three parameters fully, including accepted formats and the default date behavior. The description adds no parameter-specific meaning beyond what the schema states, so the baseline score 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 lists concrete outputs—prices, number of tickets on sale, departure times, stations, carriers, and a partner purchase link—making the tool's purpose clear. It lacks an explicit verb like 'search' or 'fetch' and does not explicitly differentiate from siblings such as search_routes or find_transfer beyond the fallback mention, so it does not fully earn 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 description implies this tool is for retrieving real route data between cities and notes that if no direct flights exist it will propose a connection. However, it never explicitly states when to prefer this tool over alternatives like find_transfer or search_routes, nor does it provide exclusions. Usage is therefore only implied.

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

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

No annotations are provided, so the description alone must disclose behavioral traits. It only explains the data source ('from partner data') and that the output is names; it does not describe response shape, behavior for unknown cities, ordering, or completeness. This is minimal behavioral context.

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 short phrase with no wasted words and is easy to scan. However, it is phrased as a noun phrase rather than a complete sentence, and an explicit verb would improve clarity without adding length.

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 the description is mostly adequate: it states the input city and the data returned. But with no output schema, the agent is left to guess whether the result is a plain list of strings or a richer structure that could feed sibling tools like city_departures.

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 'city' has a complete schema description, including examples of Russian names and slugs. The tool description adds no additional meaning for this parameter, so the baseline of 3 for high schema coverage 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 indicates the tool returns names of bus stations and bus terminals in a city, which is specific enough to understand the resource and purpose. It does not use an explicit verb like 'возвращает' and does not explicitly distinguish itself from siblings, 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?

No guidance is given about when to use this tool versus alternatives such as city_departures or search_routes. The context of needing station names is implied by the description, but no explicit when/when-not or alternative selection is provided.

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

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

With no annotations present, the description carries the disclosure burden. It does explain the two behavioral modes: aggregate results without region, and regional median/rank with region. It does not disclose output format, units, or behavior for unknown or invalid regions, so transparency 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?

The description is one front-loaded sentence stating the core metric, the default output, and the parameterized variant with no redundant wording.

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 low-complexity tool with one optional fully documented parameter and no output schema, the description covers both invocation modes and the kind of result returned. It lacks only minor details such as exact return format or the number of regions shown, which do not block correct invocation.

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 documents that region accepts a Russian name or slug. The description adds meaningful semantics by explaining that supplying region changes the result from nationwide aggregate to the specific region's median and rank, going beyond what the schema 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 clearly identifies the resource (price per kilometer by bus in Russia) and the expected outputs: nationwide median, cheapest and most expensive regions, and with a region parameter the regional median and rank. It does not explicitly contrast it with sibling tools such as cheapest_destinations, so it is clear but lacks explicit sibling differentiation.

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

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

The description implies when to use the tool: when bus price-per-kilometer statistics are needed, either for the whole country or for a specific region. However, it gives no explicit when-not-to-use guidance or alternatives to prefer.

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 the result fields (price 'from', number of departures, mileage) but says nothing about ordering, pagination, limit behavior, or error handling. For a tool without annotations, this is a limited disclosure.

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, compact sentence that directly states the resource and key output fields. It is front-loaded with 'Список направлений из города' and has no filler, though it could benefit from a second sentence about usage.

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 is too thin for an agent to fully understand return format, limit application, or when to select this tool over siblings. The listed fields partly cover output expectations, but the context around invocation and selection is missing.

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

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

Schema coverage is only 50% (only 'from' has a description). The tool description adds no extra meaning for the 'limit' parameter and does not clarify its semantics. It implicitly ties 'from city' to the 'from' parameter but does not compensate for the undocumented limit.

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 states a clear object: 'Список направлений из города' with specific result fields (price from, number of departures, mileage). It is not a tautology and conveys what the tool returns, though it does not explicitly differentiate it from sibling tools like cheapest_destinations or get_route.

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?

No guidance is given about when to use this tool versus alternatives. It does not mention that it lists general directions, which could be confused with sibling tools like cheapest_destinations or city_departures, and no exclusions or conditions are stated.

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