Skip to main content
Glama
Sign In
matteoredaelli

ViaggiaTreno MCP Server

by matteoredaelli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Treni Su Tratta

treni_su_tratta

Retrieve trains currently running on a specific railway segment using the direction IDs and region ID returned by the route list query.

Instructions

Restituisce i treni attualmente in circolazione su uno specifico segmento di tratta ferroviaria. Richiede gli identificativi numerici nei due sensi (tratta_ab e tratta_ba) e lo stesso id_regione usati nella chiamata a elenco_tratte_ferroviarie che li ha prodotti: gli ID sono numerati per regione, non sono identificativi globali della rete.

Input Schema

NameRequiredDescriptionDefault
categorieNoES*,IC,EXP,EC,EN,REG
tratta_abYes
tratta_baYes
id_regioneNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.0
    • addedInput schema / properties / id_regione
      Added value: +{
+  "default": 0,
+  "type": "integer"
+}
    • changedOutput schema / properties / result / items / properties / tratta / anyOf
      Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / result / items / properties / tratta / description
      Previous value: -"ID della tratta o segmento"New value: +"ID numerico o nome leggibile del segmento (es. 'Codogno - Piacenza'); può essere null per i nodi senza nome (es. segnaposto S00000/S99999). Verificato dal vivo: con id_regione=0 è spesso null, con id_regione>0 può contenere il nome del segmento."
    • changedOutput schema / properties / result / items / properties / treni / items / properties / compRitardo / anyOf
      Previous value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / result / items / properties / treni / items / properties / compRitardo / description
      Previous value: -"Testo del ritardo multilingua"New value: +"Testo del ritardo multilingua (elementi possono essere null, osservato dal vivo)"
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/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 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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools