Skip to main content
Glama
Bristlecone2026

Bristlecone Logic Utilities

by Bristlecone2026
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

repair_json

Read-onlyIdempotent

Repairs malformed, truncated, or unclosed JSON strings from LLMs by fixing missing brackets, unescaped quotes, and trailing commas, then returns valid parsed JSON.

Instructions

Deterministically parses and repairs malformed, truncated, or unclosed JSON strings produced by LLMs (e.g. missing closing brackets, unescaped quotes, trailing commas). Returns parsed valid JSON object. Use when an LLM produces syntax-broken JSON. Do not use on valid non-JSON prose or for modifying data values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
raw_jsonYesThe unparsed, malformed, or incomplete JSON text string requiring syntax repair into standard RFC 8259 format.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.3
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "repaired_json": {
-      "type": "object"
-    },
-    "status": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "status",
-    "repaired_json"
-  ],
-  "type": "object"
-}New value: +null
  2. First observedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: deterministic (not heuristic/best-effort) repair, the specific defect classes handled, and the explicit non-goal of altering data values.

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

Conciseness5/5

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

Four tight sentences with no filler; purpose and determinism are front-loaded, followed by return value, then usage and exclusions. Every sentence adds distinct information.

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

Completeness5/5

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

For a single-parameter, side-effect-free tool with no output schema, the description covers purpose, input defect classes, return value, and boundaries. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description goes further by enumerating the kinds of malformation the single raw_json input may contain (missing closing brackets, unescaped quotes, trailing commas), giving the agent a concrete sense of what counts as repairable input.

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

Purpose5/5

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

States a specific verb (parses/repairs) and resource (malformed, truncated, or unclosed JSON strings), with concrete examples of the failure modes it handles. The 'produced by LLMs' qualifier and the sibling landscape (e.g. validate_schema) make it clear this is repair, not validation.

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?

Explicitly says when to use it ('Use when an LLM produces syntax-broken JSON') and gives two exclusions (valid non-JSON prose, modifying data values). It stops short of naming a sibling alternative such as validate_schema for the already-valid case.

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

Deploy Server

Other Tools