Interactive tool for converting and visualizing floating-point numbers across standard and custom formats. Convert between FP32, FP16, BF16, TF32, FP8, etc. while inspecting binary representations and precision loss.
Live URL: https://sw23.github.io/fp-conv/
Format presets: FP64, FP32, FP16, BF16, TF32, OCP FP4/FP6/FP8
Integer formats: INT32, UINT32, INT16, UINT16, INT8, UINT8, INT4, UINT4
OCP format support: Full support for Open Compute Project FP8 and microscaling formats
Custom formats: Define any bit layout (0–15 exponent bits, 0–112 mantissa bits)
Interactive editing: Toggle individual bits and see decimal/hex updates
Precision analysis: Calculate absolute and relative error between formats
Special values: Explore zero, infinity, NaN, subnormals, and boundary cases
Rounding modes: Implements IEEE 754 rounding modes (ties to even, ties away from zero, toward zero, toward +inf, and toward −inf)
Overflow behavior: Configurable overflow (Infinity/NaN vs. max normal).
NaN handling: Convert a NaN to the output's canonical quiet NaN, or keep its sign and payload as IEEE 754 §6.2.3 describes (details)
Fixed-point mode: Set exponent bits to 0 for fractional representations
Light and dark modes: Switch between light and dark themes based on your preference
Basic and advanced views: Additional details shown in advanced mode. Defaults based on the screen width until you choose
Shareable links: Bookmark or share a conversion via URL parameters (input/output format, value, rounding mode, overflow behavior, NaN handling, and view mode)
Mobile-friendly: Works on screens of all sizes
WebMCP API: AI agents can perform conversions via WebMCP
Related MCP server: DevKits MCP Server
The following standard formats are supported, in addition to any custom format you define (up to 15 exponent bits and 112 mantissa bits). Interactive pages have been created to help explain and visualize each standard format:
Integer: INT32, UINT32, INT16, UINT16, INT8, UINT8, INT4, UINT4
OCP Microscaling: FP8 E4M3, FP8 E5M2, FP6 E2M3, FP6 E3M2, FP4 E2M1, E8M0 (MX scale), MXINT8
Custom: Supports a wide range of user-defined formats
The fp-conv-mcp npm package provides
a local Model Context Protocol server, giving
agents direct local access to floating point format conversions.
Example client configuration (VS Code, .vscode/mcp.json):
{
"servers": {
"fp-conv": {
"type": "stdio",
"command": "npx",
"args": ["-y", "fp-conv-mcp"]
}
}
}See the package README for full usage, per-client setup, and debugging instructions.
The fp-conv-cli npm package provides a
cross-platform command-line version of the converter (Windows, macOS, and Linux),
reusing the same conversion engine as the web app and MCP server. The installed
command is fp-conv.
npx fp-conv-cli convert 3.14 --from fp32 --to fp16It supports encode, decode, convert, info, and list commands with
human-readable or --json output. See the
package README for full usage and examples.
See CONTRIBUTING.md for local setup, testing, linting, serving the site, and the oracle test-vector workflow.
MIT © 2026 Spencer Williams. See LICENSE.
Convert a value or bit pattern from one floating-point or integer format to another. Returns full encoding details for both formats and precision loss analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| bits | No | The source as a bit pattern in the input format, binary (e.g. "0011110000000000") or hex with 0x prefix (e.g. "0x3C00"), read as decode_bits reads it and converted exactly as given. Use it to convert an exact encoding such as a NaN with a sign and payload. Exactly one of "value" and "bits" is required. | |
| value | No | The value to convert. Accepts a number, hex string (read as an integer, e.g. "0xFF" is 255), or keyword. Exactly one of "value" and "bits" is required. | |
| nanMode | No | What a NaN source operand becomes; it has no effect on any other input. "canonical" gives the output format's canonical quiet NaN. "preserve" keeps the sign and as many high-order payload bits as fit, and quiets the result (IEEE 754-2019 §6.2.3). Default "canonical". Only a "bits" source has a payload to keep. | |
| inputFormat | Yes | Source format preset key or custom format object. | |
| outputFormat | Yes | Target format preset key or custom format object. | |
| overflowMode | No | What an out-of-range output magnitude becomes; the source operand is built with the input format's defaults. "overflow" produces Infinity (or NaN when the format has no Infinity); "saturate" clamps to the largest finite value. Omit to use the per-format default. IEEE 754 §7.4 directed rounding still clamps finite overflow regardless. | |
| roundingMode | No | Rounding mode for encoding into the output format; the source operand is built with the input format's defaults. Options: "tiesToEven" (default, IEEE 754), "tiesToAway", "towardZero", "towardPositive", "towardNegative". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring safety, the description adds useful behavioral context by stating that it returns full encoding details for both formats and precision loss analysis. It does not cover every edge case, but the schema's enum descriptions handle those details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by the return behavior. It contains no filler and is appropriately sized for the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema and read-only annotation, the description is largely complete for invocation and briefly explains the return contents. It does not enumerate the exact output shape, but no output schema exists and the stated return description is sufficient for an agent to understand what comes back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all seven parameters in detail. The description adds no parameter-specific semantics beyond the schema and only broadly mentions value or bit pattern conversion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: converting a value or bit pattern from one floating-point or integer format to another. It is clear and distinguishes the conversion role from encode/decode siblings implicitly, but it does not explicitly name or contrast with list_formats, encode_number, decode_bits, or get_format_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it by describing conversion between formats, and the presence of inputFormat/outputFormat makes the intended usage apparent. However, it does not explicitly say when to use this instead of encode_number or decode_bits, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a binary or hexadecimal bit-pattern into a specified format. Returns the decimal value and full component breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| bits | Yes | Bit-pattern as a binary string (e.g. "0100000001001000") or hex string with 0x prefix (e.g. "0x4048"). | |
| format | Yes | Format preset key (e.g. "fp16") or custom format object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description is free to add the return shape — the decimal value plus a full component breakdown — which is valuable since there is no output schema. It does not say what happens with an invalid bit-pattern or how custom format objects behave, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and resource. No redundant restatement of the name or title. It is efficient but very sparse given the tool's flexibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with full schema coverage and no output schema, the description covers both inputs generically and the return value. The main gap is not explaining which format presets are valid or pointing to list_formats/get_format_info, which matters for the 'preset key' input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented with examples (binary string, 0x-prefixed hex, preset key vs custom object). The description adds no additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (decode) and resource (binary/hex bit-pattern) plus the target (specified format). It does not explicitly name how it differs from sibling encode_number or convert_format, which is the inverse operation, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never states when to use this versus encode_number, convert_format, or list_formats, nor any prerequisites. Usage is only inferable from the name 'decode'. No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode a decimal number (or special value like Infinity / NaN) into a specified floating-point or integer format. Returns binary, hex, and component breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The value to encode. Accepts a number, hex string (e.g. "0xFF"), or keyword ("infinity", "-infinity", "nan"). | |
| format | Yes | Format preset key (e.g. "fp32", "int8") or custom format object. For floating-point: { signBits, exponentBits, mantissaBits, bias?, hasInfinity?, hasNaN?, hasSubnormals? }. For integer: { bits, signed, fractionBits?, symmetric? }. | |
| overflowMode | No | What an out-of-range magnitude becomes. "overflow" produces Infinity (or NaN when the format has no Infinity); "saturate" clamps to the largest finite value. Omit to use the per-format default (overflow for formats with Infinity, saturate otherwise). IEEE 754 §7.4 directed rounding still clamps finite overflow regardless of this setting. | |
| roundingMode | No | Rounding mode for encoding the value. Options: "tiesToEven" (default, IEEE 754), "tiesToAway", "towardZero", "towardPositive", "towardNegative". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, and the description usefully states the return shape ('binary, hex, and component breakdown'), which matters because there is no output schema. Detailed behavioral semantics (overflow defaults, IEEE 754 directed-rounding clamping) live in the schema rather than the description, so it adds context without contradicting anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler: the action and scope come first, the return value second. Every sentence earns its place and nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deterministic read-only computation tool with a fully documented schema, the description covers both purpose and output shape, which compensates for the missing output schema. Only minor gaps remain, such as what happens on an invalid format or value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including overflowMode and roundingMode is already fully documented in the schema. The description only echoes that a format is needed and does not add syntax or interpretation beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb + resource ('Encode a decimal number ... into a specified floating-point or integer format') and even enumerates the accepted input categories (number, Infinity/NaN). It implicitly contrasts with decode_bits as the inverse operation, but never names a sibling, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — an agent can infer 'use this when you have a value and a format and want its bits'. There is no explicit when-to-use / when-not guidance and no mention of the closely related siblings convert_format or decode_bits, which is a real gap for a conversion-family tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a floating-point or integer format, including value range (max/min normal, subnormal), bias, and special value support.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Format preset key (e.g. "bf16") or custom format object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes the safe-read profile, so the description's added value is the disclosure of what is actually returned — value range (normal/subnormal), bias, and special value support. That return-content disclosure is meaningful given there is no output schema. It does not mention error behavior for an unrecognized format key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence with the resource front-loaded and the payload details following. No filler; slightly long but every clause describes a returned field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter fully documented in the schema and no output schema, the description carries the burden of explaining return values, and it does so adequately by listing range/bias/special-value fields. Only the accepted preset-key set and invalid-input behavior are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains that 'format' accepts a preset key like "bf16" or a custom format object. The description says nothing about the parameter, so it adds no meaning beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource ('Get detailed information about a ... format') with the returned content enumerated (range, bias, special values). It is clearly differentiated in function from list_formats or encode_number, though it never names the siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the lookup tool you call before encoding/decoding with a given format. There is no explicit 'use this when' statement, no mention of list_formats for discovery, and no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available floating-point and integer format presets supported by this converter. Returns format keys, names, categories, and parameters (bits, exponent, mantissa, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only safety profile, and the description adds what the annotations cannot: the returned fields (keys, names, categories, and numeric parameters like bits, exponent, mantissa). Since no output schema exists, this return-shape disclosure carries real value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, purpose front-loaded ahead of the return-value detail. Nothing is repeated from the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param read tool with no output schema, the description is nearly complete: it says what is listed and what each entry contains. It could go further by noting the keys are the inputs other tools accept, but no critical information is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. No parameter documentation is needed and none is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all available floating-point and integer format presets') and scopes it to 'this converter'. It does not explicitly contrast with get_format_info, but the enumeration framing makes the difference reasonably inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can guess this is the discovery step before convert_format or get_format_info. There is no explicit 'use this when...' or mention of the sibling tools, so the routing guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0convert_formatdecode_bitsencode_numberget_format_infolist_formatsScored across 5 tools
Each tool has a clearly distinct role: listing formats, encoding, decoding, converting between formats, and retrieving detailed format metadata. The only mild overlap is between list_formats and get_format_info, but the former is collection-level and the latter is single-format detail, so selection is unambiguous.
All tool names follow a consistent snake_case verb_noun pattern: list_formats, encode_number, decode_bits, convert_format, get_format_info. The convention is predictable throughout.
Five tools are well-scoped for a floating-point format converter. The set covers discovery, metadata lookup, encoding, decoding, and conversion without redundant tools.
The tool surface covers the full lifecycle for this domain: discovering formats, inspecting format details, encoding values, decoding bit patterns, and converting between formats with precision-loss analysis. No obvious operational gap remains for a format converter.
Free deterministic tools for math, data transforms, dates, text, statistics, finance, and units.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
