Sairen

repair_malformed_json

Repairs malformed, truncated, or broken JSON from LLMs by stripping markdown, fixing unquoted keys, invalid quotes, trailing commas, and auto-closing brackets into valid JSON.

Instructions

    [Free Promotional Preview / Zero Auth] Repairs malformed, truncated, or syntactically broken JSON generated by smaller LLMs (Llama-3, Mistral).
    Strips markdown wrappers, wraps unquoted keys, replaces invalid single quotes, removes trailing commas,
    and auto-closes truncated brackets/braces into 100% valid JSON in sub-3ms.

    Args:
        raw_text: The malformed, unquoted, or broken JSON string emitted by the LLM.
        target_schema: Optional JSON schema dictionary (or schema JSON string) to validate and backfill.
        target_schema_json: Optional stringified JSON schema for backward compatibility.
        payment_signature: Optional x402 Base USDC transaction hash or developer mock key.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`raw_text`	Yes
`target_schema`	No
`payment_signature`	No
`target_schema_json`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.0Sep 25, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and handles it well: it enumerates the exact transformations performed (stripping markdown wrappers, wrapping unquoted keys, replacing single quotes, removing trailing commas, auto-closing brackets/braces) and discloses the output guarantee, timing, and auth posture. This is substantial behavioral context beyond what the schema alone offers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, opening with purpose and auth status before listing behaviors and arguments. Minor promotional and performance phrasing such as 'Free Promotional Preview' and 'sub-3ms' adds slight noise but does not obscure the essential content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the absence of annotations, the description covers purpose, transformations, auth, and all four parameters, and an output schema exists so return-value details are not required. The only small gap is the relationship between payment_signature and the 'Zero Auth' preview, but the parameter is still described well enough to be usable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by documenting every parameter: raw_text as the malformed input, target_schema as an optional schema for validation/backfill, target_schema_json as a backward-compatible stringified form, and payment_signature as an optional transaction hash or mock key. This adds genuine meaning beyond the bare schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb—'Repairs'—and a precise resource: malformed, truncated, or syntactically broken JSON, with concrete repair behaviors enumerated. It is clearly more informative than the tool name alone, though it does not explicitly contrast any sibling tool such as coerce_tool_arguments, so sibling differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear triggering context: JSON emitted by smaller LLMs such as Llama-3 and Mistral that is malformed or broken, and it clarifies that the tool requires zero auth for the preview. It does not, however, state when not to use the tool or mention alternative tools, so exclusions are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server