ViaggiaTreno MCP Server

Treni Diretti Tra Stazioni

treni_diretti_tra_stazioni

Retrieves direct trains between two stations for the current day; it excludes routes requiring a transfer, so results may be empty when only connecting services exist.

Instructions

Restituisce i treni DIRETTI (senza cambi) tra due stazioni nella giornata corrente (es. da 'S01700' Milano Centrale a 'S06421' Firenze Santa Maria Novella). Non gestisce percorsi che richiedono un interscambio: in tal caso la lista può risultare vuota anche se un collegamento con cambio esiste. Endpoint non documentato nelle fonti note, trovato nello script ufficiale del sito ViaggiaTreno e verificato dal vivo.

Input Schema

Name	Required	Description	Default
`id_stazione_a`	Yes
`id_stazione_da`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Oct 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.