Loading ToolBench
MCP server for vehicle serial number generation, validation, and management with check digit calculation
This MCP server exhibits significant quality gaps across naming, descriptions, and schema completeness. Five tools are defined with basic JSON schemas, but descriptions are consistently vague and parameter documentation is sparse. Tool names use compound verbs ('Upload', 'Get', 'Validate') but lack the clarity expected for agentic disambiguation. Most critically, parameter descriptions are either missing or trivial (e.g., 'Serial number filter' with no guidance on format, valid ranges, or dependencies). Output schemas are not documented, making it impossible for LLMs to plan chaining. Error handling is present but generic ('error', 'success' fields in JSON without recovery guidance). No parameter enums are used despite obvious opportunities (e.g., VehicleType, AcronymCountryOfManufacture should be constrained sets, not free-form strings). The codebase is in C# with a custom framework, tools are manually registered via McpServerTool subclasses, but tool definitions are hardcoded and lack the flexibility of modern patterns.
Get vehicles with serial number and check digit.
Get vehicles with validated serial number check digit.
Validate serial number with check digit.
Get total vehicles by country.
Upload vehicles with serial number.
Missing output schemas across all tools. No tool documents what fields or structure the response contains, making it impossible for LLMs to plan downstream tool calls or extract relevant data.
Tool descriptions are absent or under 20 characters for 2/5 tools (GetVehiclesWithValidatedSerialNumberAndCheckDigit missing entirely; TotalVehiclesByCountry is 31 chars). LLMs cannot disambiguate tools without actionable context.
Parameter descriptions lack validation rules and format constraints. E.g., VehicleType and AcronymCountryOfManufacture are free-form strings with descriptions like 'Vehicle type filter', no enum constraints, allowed values, or format guidance. This invites hallucinated invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Tool naming violates verb_noun convention. 'ReturnsIfTheSerialNumberIsValid' and 'GetVehiclesWithValidatedSerialNumberAndCheckDigit' are compound descriptive names, not action verbs. This makes it hard for LLMs to parse intent and distinguish tools.
No parameter enums despite obvious opportunities. 'VehicleType' and 'AcronymCountryOfManufacture' should declare allowed values as enums, not free-form strings. This prevents LLMs from self-correcting and forces them to guess at valid values.
Error handling is generic and non-actionable. Responses use 'error' and 'success' JSON fields with plain text messages (e.g., 'File processed successfully'). No recovery guidance: what should the LLM do if file validation fails? What are the valid formats?
File upload tool accepts 'format: binary' in JSON Schema, which is non-standard and ambiguous. Should clarify: is this base64-encoded? Raw bytes? Plain text? Agents and validators may not parse this correctly.
Overlapping tool purposes without clear differentiation. GetVehiclesWithCheckDigitCreated and GetVehiclesWithValidatedSerialNumberAndCheckDigit appear to serve similar purposes but differ in name only. LLMs will conflate them and waste reasoning cycles.