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

No annotations are provided, so the description must carry the full behavioral burden. It describes the basic suggestion behavior and the returned fields, but omits operational traits such as case sensitivity, matching limits, rate limits, or authentication needs. Output schema exists, so return value details are not a credit here.

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 three front-loaded sentences that each serve a purpose: function/examples, return example, and recommended use. It is appropriately sized and free of filler, though the example detail is slightly more than strictly necessary.

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 one-parameter autocomplete tool and the existence of an output schema, the description covers purpose, parameter meaning, and recommended usage adequately. It could add behavioral details like matching semantics, but no critical element for invocation is missing.

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

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

Schema description coverage is 0%, so the description must explain the single parameter. It does so clearly by stating 'prefisso del nome' and providing concrete examples ('firenze', 'milano'), adding meaning beyond the bare schema type.

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 ('Suggerisce') and resource ('stazioni ferroviarie') along with the matching condition ('per prefisso del nome'). It clearly tells the agent what the tool does, but does not differentiate it from siblings like cerca_stazione or autocompleta_stazione_nts.

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 positions itself as the recommended endpoint ('È l'endpoint consigliato') for obtaining station codes to be used in boards and details. This gives clear context for when to use it, though no explicit when-not or alternatives are named.

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 code format (9-11 digits, prefix 83) and an interoperability constraint, but says nothing about whether the lookup is read-only, how many matches are returned, or what the output schema contains. It adds real context but leaves the behavioral profile thin.

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 tight sentences with the core purpose front-loaded and the code-format detail in a parenthetical. No filler, though the domain examples (BIVIO, DEV., PC) are somewhat dense for an English-reading agent.

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

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

An output schema exists, so return-value explanation is not needed. For a single-parameter autocomplete tool, the description covers what it searches and the key interop caveat. Only the prefix parameter's expected format remains under-specified.

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?

One required parameter (prefisso) with 0% schema description coverage, so the description must compensate. 'Autocompletamento' implies prefix-matching semantics, but the description never states what prefisso should contain (code prefix vs. name fragment) or matching rules. Marginal value over the bare 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 (autocompletamento) and a well-scoped resource (stazioni e nodi tecnici ferroviari: bivi, deviazioni, posti di comunicazione) and pins the output to 9-11 digit RICS codes starting with 83. This clearly distinguishes it from the sibling autocompleta_stazione, which handles ordinary stations.

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 note that these NTS codes 'non vanno usati con gli altri endpoint ordinari' gives a when-not caveat, but it is about downstream usage of the returned codes, not about when to select this tool over autocompleta_stazione or cerca_stazione. Usage context is implied by the domain rather than explicitly routed.

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 does disclose a behavioral scope ('corse attive' only, i.e. non-archived runs) and the essential return payload, but says nothing about read-only nature, error handling, or limits, which is a notable gap 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?

Two tight sentences: purpose and example first, then the return summary and downstream usage. Every clause 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?

For a one-parameter lookup with an output schema present, the description supplies purpose, a usage workflow, and a brief return characterization. It is nearly complete, missing only read-only/auth disclosure that the absent annotations would otherwise cover.

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

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

Schema description coverage is 0% and the single integer parameter is undocumented in the schema, but the description compensates meaningfully by giving the example value 9611, clarifying the expected numeric train-number 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?

States a specific verb and resource ('Cerca le corse attive associate a un numero di treno') with a concrete example (9611). It also names the sibling tools it feeds (stato_treno, itinerario_treno_canvas), which signals its role as the ID-resolution step, though it does not explicitly contrast itself against an alternative lookup.

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?

Implies a clear workflow: call this first to obtain the millisecond value, then pass it to stato_treno or itinerario_treno_canvas. It establishes context well but gives no explicit when-not-to-use condition or eligibility constraint beyond 'corse attive'.

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 does disclose the returned fields (id, long name, short name, label/city) and the prefix-matching behavior, which is useful. It omits case sensitivity, result limits, pagination, and whether the prefix must be non-empty, so behavioral coverage is only partial.

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 tight sentences: the matching behavior comes first, the return payload second. No filler and nothing redundant.

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

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

An output schema exists, so return values need not be spelled out, yet the description helpfully summarizes them anyway. For a one-parameter read tool this is nearly complete; the only real gap is the absence of guidance distinguishing it from the autocomplete sibling.

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 documents the single parameter only as type string with 0% description coverage, but the description compensates by explaining that 'prefisso' is the prefix the station name must begin with. That meaningfully clarifies how the parameter is matched, though it doesn't specify case handling or minimum length.

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 (cerca) and resource (stazioni) plus the exact matching mode ('il cui nome inizia con la stringa specificata'), so the agent knows this is a prefix search, not a full-text search. It does not, however, differentiate itself from the very similar sibling autocompleta_stazione, leaving the choice between the two 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?

There is no statement of when to use this tool versus alternatives such as autocompleta_stazione or dettaglio_stazione, and no prerequisites or exclusions are given. The agent must guess the intended use case from the name 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 full burden. It does convey that this is a pure read/lookup returning a mapped code, and the example demonstrates the mapping behavior. However, it says nothing about error behavior for unknown/invalid station codes, so behavioral disclosure is 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?

A single, front-loaded sentence with a compact inline example. Nothing is wasted and the core mapping is immediately clear.

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 lookup with an output schema, the description covers input semantics and the return transformation well. Only the absence of error/edge-case behavior and sibling routing keeps it from being 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 coverage is 0%, so the description must compensate, and it does: it identifies the parameter as a station code and the example 'S01700' conveys the expected string format. It stops short of documenting constraints or failure modes, but the format hint is the key missing piece the schema omits.

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 (Restituisce) and resource (codice numerico di regione) tied to a concrete input (stazione), and the 'S01700 -> 1 Lombardia' example makes the transformation unambiguous. It is clearly distinct from list-oriented siblings like elenco_stazioni_regione, though it does not name that 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?

No guidance on when to use this tool versus alternatives such as dettaglio_stazione or elenco_stazioni_regione. The usage is only implied by the parameter name; no exclusions or prerequisites are 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?

With no annotations, the description carries the full behavioral burden. It does disclose one non-obvious trait: that codice_regione is auto-retrieved when omitted, which is not stated in the schema. It does not cover failure behavior for an invalid codice_stazione, permissions, or any error/edge conditions.

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 tight sentences with the returned fields front-loaded and the fallback behavior appended; no filler. Slightly dense but appropriately sized for a simple lookup tool.

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

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

An output schema exists so return values needn't be re-described, and the description is adequate for a two-parameter lookup. However, with zero schema coverage and no annotations, the required parameter remains unexplained, leaving an agent without guidance on the format of codice_stazione.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It explains codice_regione's optional nature and auto-fallback, but says nothing about the required codice_stazione (its format or valid values) or what codice_regione actually affects in the result set.

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 ('Restituisce i dettagli completi di una stazione ferroviaria') and enumerates the fields returned (coordinates, city, region, typology), so an agent knows exactly what it fetches. It does not explicitly contrast itself with lookalike siblings such as cerca_stazione or autocompleta_stazione, so differentiation is only implied.

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?

There is no explicit when-to-use guidance and no mention of when to prefer this over cerca_stazione, autocompleta_stazione, or elenco_stazioni_regione. The only conditional statement concerns the codice_regione fallback, which is behavioral rather than usage 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 must carry the behavioral burden. The verb 'Restituisce' implies a read-only retrieval with no mutation, and the supported-language list adds useful context, but it does not disclose auth requirements, rate limits, error behavior, or explicitly confirm the operation is side-effect free.

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, zero wasted words. The purpose is front-loaded and the supported-language list follows immediately as practical 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?

The tool is simple, has one optional parameter, and an output schema exists, so return values need not be described. The description supplies the supported language values and the retrieval purpose, though it omits the default language behavior and any invalid-language handling.

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

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

Schema description coverage is 0%, so the description must compensate. It lists the exact supported language codes ('it', 'en', 'de', 'fr', 'sp', 'ro', 'jp', 'zh', 'ru'), effectively supplying the enum values missing from the schema. It does not name the parameter or mention the default 'it', keeping it from a perfect score.

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: it returns the ViaggiaTreno interface string translation dictionary. This is a clear, unique purpose that cannot be confused with any sibling tool such as station lookup or train status 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 implies usage by naming the returned resource and listing supported languages, but it does not explicitly say when to use this tool versus alternatives or when not to use it. For a simple unique lookup tool, the implied usage is adequate, though no explicit guidance is given.

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, yet it only mentions that geographic coordinates are returned (already covered by the output schema). It says nothing about read-only nature, permissions, rate limits, or pagination, leaving the safety/behavior profile undisclosed.

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 that states the purpose before the code enumeration, with no wasted clauses. The dense parenthetical of region codes is long but earns its place given the zero-coverage 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?

For a one-parameter read tool with an output schema covering return values, the description adequately conveys purpose and parameter semantics. However, it omits usage guidance and any behavioral context, leaving gaps an agent would otherwise need to infer.

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

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

Schema description coverage is 0% — codice_regione is a bare integer — but the description compensates by enumerating the actual code values (1=Lombardia, 2=Liguria, 5=Lazio, 8=Emilia Romagna, 13=Toscana, 0=principali) that the schema completely lacks. This is exactly the semantic mapping the parameter needs, though 'ecc.' leaves the set open-ended.

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 (Restituisce) and resource (elenco di tutte le stazioni ferroviarie) scoped to a region, which cleanly separates it from search/detail siblings like cerca_stazione and dettaglio_stazione. It does not explicitly name a sibling to differentiate, so it lands at 4 rather than 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 explains what the tool returns but gives no when-to-use or when-not guidance and never points to an alternative such as cerca_stazione or codice_regione_stazione. The use case is only implied by the purpose statement, with no framing of context 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?

With no annotations, the description carries the burden and does well: it discloses that region filtering applies to segments (not trains), that border segments can return long-distance trains merely transiting, and that tratta IDs are region-scoped and must be reused with the same id_regione. No mention of rate limits, pagination, or auth, but the meaningful behavioral traps are surfaced.

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

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

Front-loaded with what the tool returns, then parameter semantics, then the critical caveats — every sentence adds information. It is dense and sentence length in the id_regione explanation is high, but nothing is truly redundant.

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

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

An output schema exists, so return shape needn't be restated; the description still covers the returned content (segments, coordinates, occupancy, tratta_ab/ba IDs) and the cross-tool ID-reuse rule. For a two-param read tool, an agent has everything needed to call it 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 0%, yet the description fully documents both parameters: categorie with concrete example values, and id_regione with the full code space (0=tutta Italia, 1-22=singola regione) plus a pointer to elenco_stazioni/regione for codes. It adds semantic depth the bare schema defaults could never convey.

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 ('Restituisce i segmenti della rete ferroviaria') plus what each segment carries (coppie di nodi con coordinate, indicazione di occupazione). It also implicitly distinguishes itself from treni_su_tratta by describing segments rather than trains, so an agent can tell the two apart without reading schemas.

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

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

It explains the segment-vs-train filtering distinction and explicitly names treni_su_tratta as the downstream consumer of the returned IDs, which gives clear usage context. What's missing is an explicit 'use this tool when you need X, use treni_su_tratta when you need Y' routing statement, and any prerequisites are 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 carries the full disclosure burden. It does disclose meaningful behavioral content — that each stop carries flags for departure/arrival already occurred and train currently stopped — but says nothing about error conditions, required identifiers being valid, or response size/limits.

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 with no filler, front-loading the verb and the return artifact ('tratteCanvas'). It could be tighter only by trimming the parenthetical or by adding the missing parameter guidance.

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

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

An output schema exists, so the return shape needn't be explained, and the description does characterize the semantic content of that output. However, with three required parameters at 0% schema coverage and no annotations, an agent still lacks enough to call it correctly — the date format alone is a real blocker.

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

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

Schema description coverage is 0% and the description never mentions parameters at all. In particular, 'data_partenza' is typed as integer with no format hint (epoch? YYYYMMDD?), and 'codice_stazione_origine' as a string with no indication of the expected station-code convention — these are exactly the gaps the description should close.

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: it returns the visual tree representation ('tratteCanvas') of a train's itinerary, with per-stop status flags. This is clearly distinguishable from list-style siblings, though it never explicitly contrasts itself with stato_treno or elenco_tratte_ferroviarie, which cover adjacent ground.

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 on when to prefer this tool over stato_treno, elenco_tratte_ferroviarie, or treni_su_tratta. The agent must infer the use case entirely from the phrasing 'visual tree representation'.

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 an edge case (the official API may return an empty set for some regions), but says nothing about authentication, rate limits, 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?

Two sentences, front-loaded with the core behavior and followed by the caveat. No filler; only the caveat sentence could be tightened.

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 output schema covers return values, so the description need not explain them, and the empty-result caveat is a helpful addition. However, it leaves out how to obtain valid region codes and any error or permission behavior, which matters for a tool with a bare 0%-documented schema.

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

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

Schema coverage is 0% for the single codice_regione parameter, so the description must compensate. It supplies two example values (1=Lombardia, 13=Toscana), which adds real meaning, but gives no full code list or pointer to the sibling codice_regione_stazione tool for lookup.

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

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

States a specific verb+resource: returns weather forecasts for stations within a given region, which distinguishes it from sibling tools like elenco_stazioni_regione (station listing) and stato_treno. It does not explicitly name a sibling, 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 indication of when to use this versus cerca_stazione, dettaglio_stazione, or elenco_stazioni_regione, nor any prerequisites. The only guidance is an implicit example of the region code format.

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 burden. It discloses that the data is real-time and enumerates the alert categories, which tells the agent this is a read of current conditions. It does not address rate limits, update cadence, pagination, or volume of results, leaving behavioral gaps for a live-feed 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?

Two sentences, front-loaded with the primary purpose and followed by the one actionable parameter hint. No filler, no repetition of the title, every clause carries information.

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

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

An output schema exists, so return structure need not be explained, and with one optional boolean parameter the surface area is small. The description covers purpose, content scope, and parameter behavior adequately; the only meaningful omission is sibling routing among the three infomobilità 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 0% and the single parameter has no description, so the description must compensate. It does so clearly by explaining that solo_lavori=True switches the result from live alerts to scheduled works, which fully characterizes the flag's effect beyond its boolean type and default.

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

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

States a specific verb and resource ('Restituisce le notizie dettagliate di infomobilità') and enumerates the content covered (circolazione, ritardi, guasti, scioperi), so an agent knows exactly what comes back. The word 'dettagliate' implicitly contrasts with the sibling titoli_infomobilita/ticker_infomobilita, but it never names them, so sibling 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?

Provides a concrete usage instruction for the flag ('Impostare solo_lavori=True per ottenere l'elenco dei lavori programmati'), which is genuinely useful. However, it offers no guidance on when to prefer this tool over titoli_infomobilita or ticker_infomobilita, nor any 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?

With no annotations, the description carries the full burden well. It discloses that this is a proximity-based estimate rather than certain API data, describes the matching basis (most recent arrival, same station, same operator, same line), warns that unsuitable lines may return null, and explains automatic parameter resolution.

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 front-loaded with the core concept and then adds useful caveats and line-suitability examples. It is dense but most sentences earn their place; it could be tightened slightly but is not bloated.

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?

It covers purpose, usage limits, estimation caveats, null behavior, and auto-resolution of two optional parameters, and an output schema exists so return values need not be described. However, the lack of explanation for finestra_minuti and the required parameter leaves the invocation context incomplete.

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 0%, so the description must explain all four parameters, but it only clarifies that codice_stazione_origine and data_partenza are auto-determined when omitted. It says nothing about numero_treno requirements or finestra_minuti behavior/default, leaving significant parameter meaning undocumented.

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 action and resource: it estimates the predecessor train on shuttle/suburban lines, explaining the rolling-stock logic. It also distinguishes this estimate from certain API data, so an agent can tell what the tool is for without opening the schema.

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

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

It gives clear when-to-use and when-not-to-use guidance: good for high-frequency shuttle lines such as S8 and Como/Chiasso-Milano, not suitable for long-distance regional lines with few daily runs. It does not explicitly name a sibling tool to use instead when unsuitable, so it falls short of full alternative routing.

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, and it does disclose 'in tempo reale' (real-time freshness) and the national scope. It does not mention refresh cadence, caching, or failure behavior, so the disclosure is partial rather than 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?

A single front-loaded sentence stating the resource first and the returned metrics after; every clause carries information and nothing is redundant.

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

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

An output schema exists, so return values need not be explained, and the description still names the two headline metrics. Zero params and a simple read make it nearly complete; only freshness/behavioral guarantees are unstated.

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 takes zero parameters, which is the baseline-4 case per the rubric. The description correctly adds no parameter detail because there is nothing to parameterize.

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 ('Restituisce') and resource ('statistiche della rete ferroviaria nazionale') and then enumerates the exact two metrics returned (treni programmati, treni in circolazione). No sibling tool offers service-wide statistics, so the purpose is unambiguous without naming an alternative.

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 stated purpose; there is no explicit when-to-use, when-not-to-use, or comparison to alternatives. For a zero-parameter tool with a unique role this is acceptable, but no routing guidance is actually 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 provided, the description carries the full behavioral burden and does well: it discloses the real-time nature of the data, the possible running states (regolare, soppresso, parzialmente soppresso), and the automatic resolution of missing origin/date parameters. It does not mention error behavior, such as what happens when the train number is invalid or not found, which is a remaining 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?

Two sentences, front-loaded with the core purpose and immediately followed by the optional-parameter fallback behavior. Every clause adds information about the return payload or parameter handling, 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?

For a three-parameter read tool with an output schema, the description is largely complete: it covers the behavioral contract and parameter fallback logic. The main omission is format guidance for data_partenza and codice_stazione_origine at 0% schema coverage, plus any note about failure modes.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It explains that numero_treno drives the lookup and that data_partenza and codice_stazione_origine are optional and auto-determined when omitted, which adds real meaning. However, it does not specify accepted formats for the integer date or the station code string, leaving format ambiguity unresolved.

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 ('Restituisce lo andamento e lo stato in tempo reale di un treno') and enumerates the exact data returned, including delay, last detection, running status, and full stop list. It is clearly distinguishable from search-oriented siblings like cerca_numero_treno, though it does not explicitly name which sibling to use instead.

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 final sentence gives valuable context for the two optional parameters, explaining that origin station and departure date are auto-determined from the train number when omitted. However, there is no explicit guidance on when to choose this tool over alternatives such as itinerario_treno_canvas or predecessore_treno, so usage is only implied by the described real-time status purpose.

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 does disclose 'in tempo reale' (live data) and enumerates the returned fields, which implies a read-only operation, but it never states auth/permission needs, rate limits, or how data_ora changes the result set.

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 filler. The field enumeration is long-ish but earns its place given the schema documents nothing; only slight redundancy against the output 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?

With an output schema present, the returned-field list is largely duplicated, and the exclusion of any guidance on data_ora leaves a real gap for a 2-parameter tool. Adequate for the common case of a current-arrivals lookup but incomplete around the optional time parameter.

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

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

Schema description coverage is 0% for both parameters. The description compensates for codice_stazione by giving an example value format ('S01700'), but data_ora is not mentioned at all, leaving an entire parameter — presumably a timestamp for querying a non-current timetable — unexplained in either schema or description.

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

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

States a specific verb and resource ('Restituisce il tabellone degli arrivi in tempo reale per una stazione ferroviaria') and gives a concrete station-code example ('S01700' per Milano Centrale). The arrivals scope cleanly separates it from the obvious counterpart, tabellone_partenze.

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: an agent can infer this is for looking up live arrivals at a given station. There is no explicit when-to-use/when-not, no mention of tabellone_partenze or stato_treno as alternatives, and no stated prerequisites.

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 at all, the description must carry the full behavioral burden; it does disclose that data is real-time and enumerates the returned fields (delay, platform programmed vs actual, circulation status). However, it says nothing about failure behavior for an invalid station code, whether results are cached or how fresh 'tempo reale' is, or how much data is returned per call. Useful but incomplete 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?

Two sentences, purpose front-loaded before the field enumeration, with no throat-clearing. The second half re-lists fields that the output schema already declares, which is redundant, but the text stays short enough that it does not impede use.

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 return values are documented by the output schema, yet the description spends its length restating them while leaving the real gaps open: how to obtain a valid codice_stazione and what data_ora does. For a simple read tool this is workable 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 0%, so the description must explain both parameters. The station-code examples give a useful hint about codice_stazione format, but data_ora is never mentioned at all — its format, whether it selects a future timetable rather than now, and its default of null are entirely undocumented.

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 ("Restituisce il tabellone delle partenze in tempo reale") scoped to a single station, and the departures-vs-arrivals distinction is inherent in the named resource, so an agent can separate it from tabellone_arrivi at a glance. The concrete station-code examples ('S01700' Milano Centrale, 'S08409' Roma Termini) make the resource identifiable without opening the schema.

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

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

There is no explicit when-to-use guidance, no mention of when to prefer tabellone_arrivi, stato_treno, or treni_diretti_tra_stazioni, and no hint that autocompleta_stazione / cerca_stazione should be called first to resolve a station code. The examples imply a code format but nothing routes the agent among the many sibling 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 behavioral burden. It conveys only that the result is short scrolling alerts; nothing about freshness, auth requirements, or update cadence is disclosed. Low risk as a zero-param read, but the disclosure is thin.

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 compact sentence with no filler, and the resource is front-loaded. Nothing is wasted, though there is no structure beyond the one clause.

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

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

An output schema exists, so return values need not be described. For a zero-param read tool the definition is minimal-but-viable, though it leaves the agent without any routing cue relative to the other infomobilità 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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?

Names a specific verb ("Restituisce") and a well-defined resource: the short scrolling alerts of the ViaggiaTreno portal's info strip. This is sufficient to distinguish it from near-siblings like notizie_infomobilita and titoli_infomobilita, though it does not explicitly contrast itself with them.

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

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

No statement of when to use this tool versus the closely related infomobilità siblings (notizie_infomobilita, titoli_infomobilita). The agent must infer the distinction from resource wording 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 full burden. It usefully discloses that only synthetic titles (not full text) are returned and that it is a compact view, which tells the agent what to expect. However it says nothing about the boolean mode switch, freshness/caching, or any read-vs-write behavior beyond the implicit read nature of 'Restituisce'.

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 core scope comes first and the compact-mode qualifier follows. Efficient, though it is short enough that the omissions cost it rather than any verbosity.

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 (one optional param) and an output schema exists, so return-value documentation is unnecessary. That said, with no annotations and an undescribed parameter, the description is only minimally sufficient – it should at least explain what 'solo_lavori' toggles and how this differs from notizie_infomobilita/ticker_infomobilita.

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 0% and the single parameter 'solo_lavori' is never mentioned in the description. The mention of 'lavori programmati' only indirectly alludes to that filter and is presented as part of the default result set, not as a toggle, so the agent gets almost no help understanding the parameter's effect.

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 ('Restituisce') and resource ('titoli sintetici degli avvisi di infomobilità o dei lavori programmati'), and the parenthetical '(versione compatta per panoramica rapida)' positions it against fuller-output siblings like notizie_infomobilita. It never names those siblings explicitly, so an agent must infer the boundary, but the verb+resource+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?

'Versione compatta per panoramica rapida' implies the use case (fast overview rather than full detail), but no explicit when-to-use/when-not guidance and no alternative sibling is named. Usage must be inferred from the compactness hint rather than 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?

With no annotations, the description carries the full behavioral burden: it discloses the current-day-only scope, the empty-list behavior for change connections, and the provenance (undocumented ViaggiaTreno endpoint verified live). It does not cover rate limits or error responses, but those are less critical for a read-style 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?

Three sentences, front-loaded with the core purpose, followed by the key limitation and then provenance. No repetition 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?

An output schema exists, so return values needn't be described. The description supplies the essential call context—current day, direct-only, station-ID format—and the caveat about empty results, making it complete enough for an agent to use it 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 description coverage is 0%, so the description compensates with concrete station-ID examples ('S01700' Milano Centrale, 'S06421' Firenze Santa Maria Novella) that establish the required format. It does not map the examples to the parameter names explicitly, but the 'da...a...' phrasing aligns with id_stazione_da and id_stazione_a.

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 ('Restituisce') and resource ('treni DIRETTI tra due stazioni') and scopes it to the current day. It does not explicitly name a sibling alternative for journeys with changes, leaving that differentiation implicit in 'senza cambi'.

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 warns that routes requiring a change are unsupported and that the list may be empty even when a connecting service exists. It stops short of naming the sibling tool to use in those cases, so the agent must infer the fallback.

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 burden. It usefully discloses that IDs are region-scoped rather than global — a real gotcha — and that results are live trains. However it says nothing about the default region behavior (id_regione default 0), the implicit category filter, or what happens when a segment has no trains.

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 dense sentences with no filler, and the core purpose is front-loaded before the ID caveat. The second sentence is long but every clause carries operational 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?

An output schema exists, so return values need no explanation, and the ID-sourcing rule is well covered. The gap is the undocumented 'categorie' filter, which materially changes results and is invisible to the agent given 0% schema coverage.

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

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

Schema description coverage is 0%, so the description must compensate. It explains tratta_ab/tratta_ba as the two directions and id_regione as the region key, covering three of four parameters meaningfully. The 'categorie' filter (with its default string of train types) is never mentioned in the description or schema, leaving that parameter opaque.

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 ('Restituisce i treni attualmente in circolazione su uno specifico segmento di tratta ferroviaria'), which is far more precise than the title. It implicitly separates itself from board-style siblings (tabellone_partenze, tabellone_arrivi) by scoping to a track segment, but it never names the closest alternative (treni_diretti_tra_stazioni) 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?

It gives a concrete prerequisite: the IDs must come from a prior call to elenco_tratte_ferroviarie, and id_regione must match that call. This effectively defines the usage chain. It stops short of stating when NOT to use it or contrasting it with the other train-listing siblings.

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