Skip to main content
Glama

Austin Oaks Payload Rescue

Server Details

Repair malformed JSON that fails a schema. Deterministic only; refuses to guess; signed receipt.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.8% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of confusion or overlapping purpose. The tool's role is clearly defined and distinct.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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 tool
rescue_payloadRescue a JSON payloadA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
schemaYesThe JSON Schema the payload must satisfy. A supported subset; unsupported keywords are rejected, never ignored.
payloadYesThe JSON document that failed downstream. Any JSON value.
mappingsNoOptional explicit key renames, e.g. {"custId": "customer_id"}. Field equivalence is NEVER inferred without a rule here.

Output Schema

ParametersJSON Schema
NameRequiredDescription
pathNo
statusYes
changesNoEvery repair applied, with a JSON path.
receiptNoHashes and a signature. No payload content.
problemsNoEvery blocking issue, with a stable reason code.
receipt_idNo
reason_codeNo
schema_validYes
original_hashNo
repaired_hashNo
repaired_payloadNoNull when status is CANNOT_REPAIR.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • First observedrescue_payload

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Deterministic 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    JSON 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.
    0
    1
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources