Austin Oaks Payload Rescue
Server Details
Repair malformed JSON that fails a schema. Deterministic only; refuses to guess; signed receipt.
- Status
- Healthy
- Uptime
- 99.8% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusion or overlapping purpose. The tool's role is clearly defined and distinct.
With a single tool named 'rescue_payload', the naming is internally consistent and follows a clear verb_noun convention. There are no conflicting styles or patterns to evaluate.
A single tool is on the thin side, but the server's purpose is narrow: repairing malformed payloads. One well-described tool may be enough, though a validation-only companion could justify a higher score.
The tool covers the full rescue lifecycle: validating, repairing, refusing unsafe changes, and reporting results with receipts. Minor gaps exist, such as no separate dry-run or repair preview tool, but these are not essential to the core purpose.
Available Tools
1 toolrescue_payloadRescue a JSON payloadARead-onlyIdempotentInspect
Repair a malformed JSON or API payload so it matches a required schema. Use when a request, webhook, or tool output was rejected for schema validation errors: wrong types, a null where an array or object belongs, a forbidden extra property, or mismatched keys between two APIs. Deterministic repairs only. No semantic guessing. Refuses instead of inventing a value, and returns an exact change manifest plus a signed receipt so a silent 'fix' can never pass downstream unrecorded.
Give it the payload that was rejected and the JSON Schema it failed. It returns one of: VALID the payload already conformed; nothing changed REPAIRED safely repaired; the returned payload satisfies the schema CANNOT_REPAIR no safe repair exists; repaired_payload is null on purpose INVALID_SCHEMA the schema is malformed or uses an unsupported keyword ERROR bad request, or a size/depth limit was exceeded
It repairs structure only: unambiguous type coercion, null to empty array or object, removing a property the contract forbids, renaming a key when an explicit mapping rule is supplied, and trimming whitespace that is blocking validation.
It will NOT invent a value. A missing required field, an ambiguous number like "1,234.00", an identifier like "007" that would lose its leading zeros, or a date like "09/06/2026" whose day/month order is unknown all return CANNOT_REPAIR with a stable reason code rather than a guess.
No language model is involved. The same input always produces the same output and the same receipt id.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | The JSON Schema the payload must satisfy. A supported subset; unsupported keywords are rejected, never ignored. | |
| payload | Yes | The JSON document that failed downstream. Any JSON value. | |
| mappings | No | Optional explicit key renames, e.g. {"custId": "customer_id"}. Field equivalence is NEVER inferred without a rule here. |
Output Schema
| Name | Required | Description |
|---|---|---|
| path | No | |
| status | Yes | |
| changes | No | Every repair applied, with a JSON path. |
| receipt | No | Hashes and a signature. No payload content. |
| problems | No | Every blocking issue, with a stable reason code. |
| receipt_id | No | |
| reason_code | No | |
| schema_valid | Yes | |
| original_hash | No | |
| repaired_hash | No | |
| repaired_payload | No | Null when status is CANNOT_REPAIR. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses determinism, refusal behavior, the change manifest and signed receipt, unsupported-schema handling, and exact return variants. These are important behavioral traits the agent could not infer from annotations alone.
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 long but every sentence earns its place: purpose, trigger conditions, return statuses, repair scope, refusal cases, and determinism guarantees. It is front-loaded with the core purpose and structured so the agent can quickly extract action and constraints.
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?
The description is fully self-contained for a complex tool: it explains when to call it, how it behaves, what it refuses, what it returns, and that it is deterministic and non-LLM. The presence of an output schema and rich annotations also reduces the burden on the description.
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 input schema already covers all parameters at 100%, so the baseline is 3. The description adds value by clarifying that mappings are explicit key-rename rules, that field equivalence is never inferred without such rules, and that the schema parameter must be a supported JSON Schema subset.
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 uses a specific verb ('repair') and resource ('malformed JSON or API payload') and states the exact goal: match a required schema. It clearly distinguishes the tool's scope from generic validation or formatting tools.
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?
It explicitly says when to use the tool: when a request, webhook, or tool output was rejected for schema validation errors such as wrong types, nulls, extra properties, or key mismatches. It also states what it will not do, such as inventing values, which acts as an implicit when-not-to-use boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
rescue_payload
Related MCP Connectors
Repair malformed JSON from LLM/agent output; optional JSON Schema coercion. Free + x402 paid.
Deterministic JSON repair, validate, example-gen, schema-coerce for agents. Zero LLM, sub-10ms.
Validates JSON against a JSON Schema, lists violations. x402 payment required (testnet USDC).
MCP server (stdio): repair broken/malformed JSON via the AgentForge API
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceProvides deterministic JSON repair and JSON Schema validation for malformed AI agent outputs, safely fixing unambiguous errors without an LLM and refusing ambiguous cases.MIT
- AlicenseNot gradedqualityDmaintenanceDeterministic JSON validation and repair for AI agents. Validates, repairs, schema-checks, and diffs JSON so long-running agents don't corrupt their session state with malformed writes.MIT
- AlicenseNot gradedqualityBmaintenanceEnables agents to diagnose JSON incompatibilities against target schemas and explicit rules, then receive bounded deterministic repairs independently verified before delivery.MIT
- AlicenseNot gradedqualityCmaintenanceJSON repair & validation MCP server for AI agents: fixes malformed JSON (trailing commas, truncation, etc.) and validates/coerces against a JSON Schema, with deterministic free tier and paid LLM-fallback.01MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.