Loading ToolBench
Model Context Protocol (MCP) server for floating-point conversions. Encode, decode, and convert numbers across FP32, FP16, BF16, TF32, FP8, FP6, FP4, and integer formats, with binary/hex breakdowns and precision-loss analysis.
fp-conv-mcp exposes 5 well-named, specialized floating-point conversion tools with complete JSON Schema input definitions and clear descriptions. All tool names start with action verbs (list_, encode_, decode_, convert_, get_) following the verb_noun pattern. Schemas are properly typed with enums for constrained inputs (roundingMode, overflowMode). However, parameter descriptions are minimal or missing in several cases, and output schemas are not documented. Error handling exists but lacks recovery guidance. The server uses STDIO transport, which is a hard cap at 50 per the rubric, but the tool definitions themselves are solid for a specialized domain.
Convert a value from one floating-point or integer format to another
Decode a binary or hex bit-pattern in a given floating-point or integer format
Encode a decimal or keyword value into a floating-point or integer format
Get detailed information about a floating-point or integer format, including range, bias, and special-value details
List all available preset formats
Output schemas not documented for any tool. Clients cannot determine what fields to expect in responses, forcing LLMs to parse unstructured output or make assumptions about response structure.
Parameter descriptions are generic or minimal. The 'format' parameter appears across 4 tools described only as 'Format preset key (e.g. fp32, int8) or custom format object' without explaining what a 'custom format object' contains or how to construct one.
The 'bits' parameter in decode_bits lacks validation guidance. Description says 'Binary string (e.g. 0100000) or hex (e.g. 0x40)' but does not specify length constraints, character restrictions, or error handling for malformed input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
encode_number accepts both 'value' and 'format' as strings but 'format' description says it can be 'custom format object'. Type ambiguity in the description, the schema shows string type but the prose suggests object type is also accepted. This forces LLMs to guess.
Error responses are converted to isError results with plain text messages (callTool in tools.js), but no recovery guidance is provided. An LLM receiving 'Invalid format: fp32_custom' has no hint on what to call next (e.g. list_formats to discover valid presets).