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 full burden. 'Restituisce' implies a read operation, and it discloses the return content (segments + occupancy status), which is genuinely useful. However, it omits any behavioral context such as permissions, result size, or whether the occupancy status is real-time vs cached.

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 resource and return content front-loaded ahead of the parameter details. No filler; each 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 values need not be fully specified, and the single optional parameter is documented. For a read-only listing tool this is nearly complete; the only gap is the lack of usage routing versus sibling 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 description coverage is 0%, so the description must compensate, and it does: it explains that 'categorie' is a comma-separated filter and lists the accepted values ('ES*,IC,EXP,EC,EN,REG'). It adds real meaning beyond the bare string type, though the use of 'includono' leaves ambiguity about whether the list is exhaustive.

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 ('segmenti della rete ferroviaria nazionale') plus the returned content (node pairs with coordinates and occupancy status). It is clear what the tool produces, but it never distinguishes itself from the closely related sibling 'treni_su_tratta', which an agent could easily confuse with this.

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 (listing the network segments) but offers no explicit when-to-use or when-not-to-use guidance. It does not route the agent between this tool and alternatives such as treni_su_tratta or elenco_stazioni_regione, leaving selection to inference.

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

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

No annotations are provided, so the description carries the burden. It does disclose behavioral content beyond a bare name - stop-by-stop flags for whether departure/arrival occurred and whether the train is currently stopped - but omits permissions, rate limits, and how the data is scoped or refreshed.

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 wasted phrasing; the purpose leads and the output detail follows. Efficient, though it could be marginally tighter.

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 unnecessary, but the description leaves critical gaps: with 0% parameter coverage, no annotations, and amiguous integer fields, it does not supply enough for an agent to call a 3-required-param tool correctly.

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

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

Schema description coverage is 0% across 3 required parameters, so the description must compensate; it does not. It never clarifies the format of data_partenza (integer - epoch? YYYYMMDD?), the meaning of codice_stazione_origine, or how numero_treno should be supplied.

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 (returns) and resource (the visual tree representation tratteCanvas of the train itinerary), which distinguishes it from a plain status lookup. It is clear what the tool produces, though it does not explicitly name or contrast with siblings like stato_treno.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as stato_treno or cerca_numero_treno for overlapping needs. The agent must infer the use case entirely from the purpose statement.

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

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

No annotations are provided, so the description carries the full burden. 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 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?

No annotations are provided, so the description carries the full burden. It discloses a genuine behavioral trait — that origine/data_partenza are auto-derived from numero_treno when omitted — but says nothing about authentication, rate limits, or failure behavior when the train number is unknown or ambiguous.

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: the first front-loads the tool's purpose and output scope, the second carries the only non-obvious parameter rule. No filler, no repetition of the title.

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 description needn't detail return values, yet its enumeration is consistent rather than contradictory. The remaining gap is behavioral failure modes and the distinction from sibling train tools, but nothing essential for a correct call 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 compensate, and it does for the two optional parameters by explaining their auto-resolution semantics. numero_treno is self-evident, and format expectations (e.g. valid train number ranges) remain unstated, keeping this below a 5.

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 lo andamento e lo stato in tempo reale di un treno') and enumerates exactly what comes back: delay, last detection, running status, and full stop list. It is far more specific than siblings like cerca_numero_treno, though it never names an alternative to disambiguate against itinerario_treno_canvas.

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 conditional clause explains when the optional parameters can be omitted and how they are resolved, which is useful operational guidance. However, there is no indication of when to prefer this tool over cerca_numero_treno or itinerario_treno_canvas, so the usage context is 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 behavioral burden. It discloses the real-time nature of the data and enumerates the fields returned, but says nothing about read-only semantics, auth needs, rate limits, or failure behavior for invalid station codes. The field enumeration largely duplicates what the output schema already provides.

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 plus a compact field list; the purpose and scope land immediately with no filler. Slightly over-specified on return fields that the output schema already covers.

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-value enumeration is not strictly needed, and the description never addresses the undocumented data_ora parameter. It is adequate for calling the tool with a station code but leaves a real gap for the second parameter and for how to obtain valid codes.

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 does document the required codice_stazione format via the 'S01700' example, which the schema lacks, but the optional data_ora parameter is never mentioned, leaving half the parameters 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 degli arrivi in tempo reale per una stazione ferroviaria') and anchors it with a concrete station-code example ('S01700' per Milano Centrale). The arrivals-vs-departures distinction is unambiguous against the sibling 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?

The real-time framing implies the usage context, but there is no explicit when-to-use guidance, no mention of the natural alternative (tabellone_partenze), and no stated prerequisites such as needing a valid station code from cerca_stazione or autocompleta_stazione. Usage is inferable from the name only.

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

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

With no annotations, the description carries the full burden and does add value by declaring the data is 'in tempo reale' and listing the fields returned (delay, actual vs scheduled platform, circulation status). It says nothing about auth needs, rate limits, or how 'data_ora' alters behavior, leaving gaps for a real-time query 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?

Front-loaded with the core action, followed by a compact field list. Every element earns its place, though listing return fields overlaps somewhat with the existing 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?

An output schema exists so return values needn't be spelled out, yet the description partially duplicates them. The main incompleteness is the undocumented 'data_ora' parameter and the absence of any pointer to the station-code lookup workflow, leaving an agent unsure how to discover valid codes.

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. It provides example values for the required 'codice_stazione' ('S01700', 'S08409'), which is genuinely helpful, but the optional 'data_ora' parameter is never mentioned — its format and effect (historical vs current board) are completely 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 verb+resource ('Restituisce il tabellone delle partenze') and enumerates the returned fields, making the tool's output clear. It does not, however, explicitly distinguish itself from the sibling 'tabellone_arrivi', relying on the reader to infer the departures-vs-arrivals distinction.

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

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

There is no guidance on when to use this versus alternatives (e.g. tabellone_arrivi) nor on how to obtain the station code (siblings like cerca_stazione/autocompleta_stazione exist but are not referenced). The example station codes hint at input format but not workflow.

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 burden, but it does disclose the key behavioral trait that results are limited to trains currently in circulation (a live snapshot rather than a schedule). It says nothing about freshness, pagination, permissions, or what happens with an invalid segment.

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 filler, with the core behavior front-loaded and the prerequisite immediately after. Every sentence adds information an agent needs.

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 details need not be repeated, and the prerequisite chain is covered. The remaining gap is the unmentioned category filter and any error behavior for invalid identifiers, which for a three-parameter read tool is a modest omission.

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

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

Schema description coverage is 0%, and the description does explain the two required parameters as numeric directional identifiers plus where to source them, which is genuinely useful. However, the third parameter 'categorie' (train category filter with a default) is never mentioned, leaving a full third of the parameters 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 verb and resource: it returns trains currently in circulation on a specific railway segment. It also distinguishes itself from the station-oriented siblings by scoping the query to a tratta segment identified by directional IDs.

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 states the prerequisite that the numeric identifiers for both directions must be obtained via elenco_tratte_ferroviarie, which is actionable routing information. It stops short of naming when not to use it or how it differs from real-time siblings like stato_treno.

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