Loading ToolBench
An MCP server and Gradio-based application for vehicle diagnostics using OBD-II protocol. Provides tools for interpreting OBD-II responses, decoding VINs, retrieving fault codes, and searching for repair tutorials.
This server provides 5 tools with basic functionality for vehicle diagnostics. However, critical gaps significantly undermine production readiness. Three tools (hex_to_decimal, combine_bytes, calculate_obd_value) are mathematics/conversion utilities with minimal practical value for diagnostic assistance. Descriptions exist but are sparse (avg ~100 chars). Input schemas ARE present with type definitions and parameter descriptions, which is positive. However, output formats are inconsistent, most tools return unstructured strings rather than structured JSON objects, forcing LLMs to parse free-text responses. No tool annotations (readOnlyHint/destructiveHint) despite all tools being read-only. Error handling is present but minimal, generic error wrapping without recovery guidance or classification. The YouTube search tool has no validation, and the VIN decoder is partially visible. Overall, this reads as a prototype or hobbyist project rather than production-grade agent tooling.
Calculate an OBD-II PID value using a formula and hex byte inputs. Common formulas include Engine RPM: "(A * 256 + B) / 4", Coolant Temp: "A - 40", Throttle Position: "(A * 100) / 255", MAF Rate: "(A * 256 + B) / 100", Timing Advance: "(A - 128) / 2", Fuel Trim: "(A - 128) * 100 / 128".
Combine 2-4 hex bytes into a larger value (big-endian, MSB first).
Decode a Vehicle Identification Number (VIN) using the NHTSA API.
Convert a hexadecimal value to decimal.
Search YouTube for a video tutorial and return the video URL.
Output schemas not documented. All tools return unstructured string responses instead of typed JSON objects. LLMs must parse free-text output (e.g., 'Hex \'1A\' = Decimal 26'), which is error-prone and token-wasteful. No downstream tool can consume these outputs reliably.
decode_vin tool definition incomplete. Only tool registered in app.py with no visible schema, input parameters, or implementation. Cannot verify NHTSA API integration or error handling.
No tool annotations. The rubric requires destructiveHint/readOnlyHint. All tools ARE read-only, but this is not declared via annotations. LLMs cannot distinguish safe-to-retry tools from destructive ones without explicit marking.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Error messages are generic and non-actionable. E.g., 'Error: Invalid hexadecimal value' does not tell the LLM what valid input looks like or how to recover. Example: calculate_obd_value catches generic Exception without categorizing it as retryable, user-fixable, or fatal.
Tool descriptions lack context. 'Convert a hexadecimal value to decimal' does not explain WHEN an LLM should call this vs other tools, what the return value structure is, or how the output feeds into diagnostics. Descriptions should be 50-200 chars and LLM-optimized per pattern:tool-description.
search_youtube_video lacks input validation. No check that query is non-empty; no rate limiting; no handling for YouTube API rate limits or deprecations. YoutubeSearch library is fragile and unsupported.
No tool composition or chaining. Tools operate in isolation. There is no example of how hex_to_decimal → combine_bytes → calculate_obd_value → search_youtube_video would work together for a real diagnostic workflow. Each tool returns a string; none return IDs or references the next tool needs.
hex_to_decimal, combine_bytes, and calculate_obd_value are low-level utilities without clear diagnostic value. They should either be composed into a higher-level 'interpret_obd_message' tool or removed if not core to the diagnostic workflow. Three similar tools with overlapping responsibility.