Austin Oaks Payload Rescue

Rescue a JSON payload

rescue_payload

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Austin Oaks Payload Rescue tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?