Tools for agents: Strict JSON text decoder

Decode one JSON value with duplicate-key rejection, finite-number checks and structured syntax diagnostics.

Connect with MCP

{
  "mcpServers": {
    "super-agent-tools": {
      "url": "https://app.getsupers.com/sites/agent-strict-json/mcp"
    }
  }
}
Streamable HTTP · No API key · Stateless

Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.

Call decode_strict_json

Input is JSON text inside the text argument, not an already parsed value. Exactly one root value is allowed, including scalars and null, with optional surrounding JSON whitespace. Duplicate decoded object keys fail at any nesting level, including escape-equivalent names. NaN, Infinity, -Infinity and float overflow fail. Unpaired Unicode surrogates in decoded keys or values fail; valid escaped surrogate pairs are accepted. Check valid: successful null has value:null; rejected input has no value. Syntax errors include a zero-based Unicode code-point offset and one-based line/column; only LF advances line count. Duplicate, numeric and Unicode validation errors do not claim source locations and report the first encountered failure, not every defect. Integers use runtime arbitrary precision subject to its digit limit; decimal/exponent numbers use binary64 rounding and may underflow to zero. This is not exact decimal parsing, JSON Schema validation, canonicalization, JSON5, comment stripping or automatic repair. Deep nesting and oversized integer literals return decoder_limit. Input is never executed or persisted.

Input and output schemas
{
  "name": "decode_strict_json",
  "title": "Strict JSON text decoder",
  "description": "Decode a single JSON value, rejecting duplicate keys, nonfinite numbers and unpaired surrogates. Return explicit valid/value or valid/error with syntax location when available.",
  "inputSchema": {
    "properties": {
      "text": {
        "title": "Text",
        "type": "string"
      }
    },
    "required": [
      "text"
    ],
    "title": "decode_strict_jsonArguments",
    "type": "object"
  },
  "outputSchema": {
    "additionalProperties": true,
    "title": "decode_strict_jsonDictOutput",
    "type": "object"
  },
  "icons": null,
  "annotations": {
    "title": null,
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "meta": null,
  "execution": null
}

Run the example to see the actual result.

HTTP alternative

POST https://app.getsupers.com/sites/agent-strict-json/call
Content-Type: application/json

{
  "text": "{\"agent\":\"builder\",\"result\":null,\"ready\":true,\"steps\":[1,2]}"
}

The HTTP and MCP interfaces execute the same implementation. Validation errors are returned explicitly. See the tool notes above for its supported inputs and behavior.

Strict JSON decoding distinguishes valid null from a rejected input

Read the explanation

The saved example carries JSON text inside one text argument. That nested JSON has four object keys: agent, result, ready and steps. The steps array has two integers and the result value is null. At sixty pixels per count object keys measure two hundred forty, array entries one hundred twenty and root values one sixty. A strict decoder consumes exactly one root value, including a scalar or null. It differs from receiving an already parsed object; duplicate key evidence is lost if a permissive parser has already collapsed it. A hypothetical object with two occurrences of the same decoded key must be rejected rather than choosing one value. At one hundred pixels per count the two occurrences measure two hundred, unique decoded key one hundred and accepted duplicate occurrences zero. Escape-equivalent names count as the same key. The saved contract also rejects nonfinite numbers, floating overflow and unpaired Unicode surrogates. A successful null result has valid true and value null, whereas rejected input has an error and no value. This distinction prevents treating a failed parse as a legitimate empty result. Syntax diagnostics use zero-based character offset and one-based line and column, with only line feed advancing the line count. In the hypothetical text containing opening bracket, line feed and question mark, the bad character has offset two, line two and column one. At eighty pixels per count those bars measure one hundred sixty, one hundred sixty and eighty. Numeric and duplicate-key errors do not claim such source positions. Decimal numbers use binary sixty four rounding rather than exact decimal arithmetic, and oversized values can hit runtime decoder limits. The shared browser client is absent offline, so this walkthrough is contract-grounded and does not claim an actual HTTP or MCP decoder response.

Strict JSON Decoding and Syntax Diagnostics

How does strict JSON decoding enforce uniqueness and numeric bounds compared to standard permissive parsers?

Standard JSON parsers frequently overwrite duplicate keys silently and accept non-standard floating-point tokens like NaN or Infinity. This decoder enforces RFC 8259 compliance and predictable agent payloads by intercepting duplicate member keys across all object depths, rejecting non-finite numeric tokens and IEEE 754 binary64 float overflows, and flagging unpaired Unicode surrogates.

The decoder validates a single top-level JSON value and rejects non-standard JSON extensions like comments, unquoted keys, or trailing commas. It stops at the first validation or duplicate error rather than collecting all semantic faults, and relies on standard binary64 floating-point rounding rather than arbitrary-precision decimal arithmetic.

Try a worked example

When you click 'Run tool' with the default payload {"text": "{\"agent\":\"builder\",\"result\":null,\"ready\":true,\"steps\":[1,2]}"}, the decoder validates the root object and outputs a structured result with "valid": true, "root_type": "object", and the parsed key-value mapping.

Object Member Uniqueness and Determinism

Under RFC 8259 Section 4, the names within an object should be unique. When duplicate keys are present, receiver behavior across different parsers is unpredictable—some retain the first key, others overwrite with the last key, and others raise errors. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format

This tool prevents data collisions and ambiguity in automated agent workflows by raising an explicit duplicate_member error whenever an identical decoded key is encountered in an object. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format

Numeric Bounds and Unicode Constraints

RFC 8259 Section 6 requires JSON numbers to follow decimal syntax and explicitly forbids literals like Infinity or NaN. It also notes that implementations standardizing on IEEE 754 binary64 double-precision values should expect interoperability limits on numeric range and precision. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format

Furthermore, RFC 8259 Section 8.2 warns that unpaired UTF-16 surrogates can cause fatal runtime exceptions or differing string length interpretations across receiving platforms. This decoder actively inspects strings to halt execution when unpaired surrogates appear. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format

Sources and further reading