Loading ToolBench
DB Schenker scraper that retrieves and cleans tracking information from DB Schenker based on a tracking number.
Single tool 'soup_cleaning' has a descriptive docstring and basic input validation, but falls short on several critical production-readiness dimensions. The tool name does not follow verb_noun conventions (should be 'get_shipment_tracking' or 'fetch_tracking_info'). The schema is present but minimal, parameter has type and description but lacks constraints (enums, ranges, or format patterns in JSON Schema). Output is unstructured string concatenation rather than typed JSON. Error handling provides basic ValueError exceptions but no recovery guidance for the LLM. The tool conflates two responsibilities (details + history) into a single response. No pagination for potentially long history. Security: Playwright browser automation with external URL dependency introduces attack surface (malicious HTML could cause ReDoS or parser exploits via BeautifulSoup), and no mention of input sanitization beyond regex validation of tracking number format.
Retrieves and cleans tracking information from DB Schenker based on a tracking number. Args: trackingNum (int or str): The tracking number, which must be an integer or a (digit) string starting with '180' and be 10 digits long. Returns: str: Concatenated details and history of the tracking information. Raises: ValueError: If the tracking number is invalid or if the webpage content cannot be retrieved.
Tool name 'soup_cleaning' does not follow verb_noun convention. Should start with an action verb (e.g., 'get_shipment_tracking', 'fetch_tracking_info', 'lookup_shipment'). LLMs rely on the name to infer intent before reading the description; 'soup_cleaning' is opaque and does not convey 'retrieve tracking information'.
Input schema for 'trackingNum' lacks formal constraints. Schema shows type as ['integer', 'string'] with a description, but does not include JSON Schema pattern or minLength/maxLength. Format constraint '10 digits starting with 180' is in the description text only, LLMs cannot reliably parse text descriptions for format rules. Should declare pattern: '^180\d{7}$' and minLength: 10 in the JSON Schema.
Output is unstructured concatenated string ('details_out + "\n" + history_out'). LLMs cannot reliably parse free-text markdown to extract structured fields. Should return a typed JSON object: {"details": {"<key>": "<value>"}, "history": [{"date": "", "status": "", ...}]}. This enables downstream tool composition and reduces parsing errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Error handling returns generic ValueError exceptions with basic messages. LLM receives 'Tracking number must start with 180 and be 10 digits' or 'Failed to retrieve the webpage content.' but has no guidance on recovery: Should I retry? Call a different tool? Ask the user? Include actionable recovery hints: 'Invalid tracking number format, must be 10 digits starting with 180 (e.g., 1805551234). Verify the number with the user or shipment document.'
Tool conflates two responsibilities: extracting shipment details AND shipping history. Should be split into separate tools ('get_shipment_details' and 'get_shipment_history') so agents can call them independently when needed. Combined tool forces the agent to always fetch both even if only one is relevant, wasting bandwidth and tokens.
No output schema documentation. Tool description mentions 'Returns: str' but does not document the structure of the markdown tables (column names, possible values, field meanings). An LLM cannot parse the output or plan downstream actions without knowing what fields are present.
Security: Playwright browser automation with external web scraping against db.schenker.com is fragile and introduces attack surface. HTML parsers (BeautifulSoup) can be exploited via malformed markup. No input sanitization beyond regex check of tracking number. No rate limiting; agent could hammer the endpoint. No mention of user-agent rotation or evasion of anti-scraping measures. Consider whether an official DB Schenker API exists that would be safer and more maintainable.
No pagination or result limiting. If shipping history is very long, the concatenated markdown string could grow unbounded, bloating the LLM context.