Loading ToolBench
Two tools are directly visible in the code with explicit registration. Both tools have acceptable naming and clear descriptions in French, but critical gaps exist in parameter descriptions, output schema documentation, and error handling guidance. Neither tool documents its return structure, making it difficult for LLMs to understand what fields to extract or chain into subsequent calls. Parameter descriptions are minimal (1 - 2 words). Error messages exist but lack recovery guidance. The server does not implement input validation with actionable error messages, instead relying on generic exception strings.
Recherche les trains entre deux villes via l'API SNCF. Fournit les horaires, durées et correspondances.
Donne les détails d'un train SNCF à partir de son identifiant vehicle_journey.
No output schema documentation. Tools return raw JSON via axios without defining the expected response structure. LLMs cannot determine what fields exist in the response or plan downstream calls.
Parameter descriptions are too minimal (1 - 3 words). 'Ville ou gare de départ' and 'Ville ou gare d'arrivée' lack actionable format guidance. The datetime parameter description omits examples of valid input or what happens if the format is wrong.
Error messages do not guide recovery. When getStopArea() returns null, the error 'Aucun stop_area trouvé pour {city}' tells the LLM nothing about what to do next (e.g., 'Try a nearby city name' or 'Call search_cities() to discover valid station names').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Input validation is weak. The code checks for null args and required fields but does not validate datetime format (YYYYMMDDTHHmmss). Malformed dates silently pass to the SNCF API, which may reject them with unclear errors.
Response structure is unpredictable. sncf_search_train strips some fields (sections simplified) but sncf_train_details dumps raw JSON. This inconsistency makes it hard for LLMs to parse responses reliably.
No pagination or result limits documented. searchTrains() requests 10 results (?count=10) but this limit is not mentioned in the tool description. For tools that may return large lists, LLMs need explicit guidance on limits and pagination.
Tool composition gap: sncf_search_train returns minimal journey details (sections with from/to/mode/duration), but sncf_train_details requires a vehicle_journey_id that is not returned by sncf_search_train. This breaks the natural tool chain and forces users to guess or parse raw output for the missing ID.