Skip to main content
Glama

FabTally Guard

by io.github.zvmzaretsky

Repair near-miss LLM JSON to a schema (paid $0.002)

json_repair

PAID $0.002 (x402, USDC on Base). Coerce near-miss LLM JSON to a JSON-Schema-conformant object: strip code fences/prose, fix trailing commas/quotes/unquoted keys, normalise Python literals, balance brackets, then coerce types, apply defaults, and drop extraneous keys. Returns the repaired object OR precise per-field errors. Args: json (the raw string), schema (a JSON Schema object). Without payment returns the x402 challenge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsonYesThe raw, possibly-malformed JSON text to repair.
schemaYesA JSON Schema (draft 2020-12) object the result must conform to.
x_paymentNox402 payment payload (base64) for this PAID check. If supplied it is forwarded as the X-PAYMENT header to settle the call and return the real result instead of a 402 challenge. Omit to get the price challenge first.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure. It details the transformation steps (strip fences, fix syntax, normalize literals, balance brackets), the output behavior ('repaired object OR precise per-field errors'), and the payment gate ('Without payment returns the x402 challenge'). This is comprehensive for a stateless JSON-processing tool.

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 concise and well-structured, with payment info front-loaded, followed by a compact list of processing steps and return behavior. Every sentence adds value and there is no redundancy.

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?

Despite having no output schema, the description states the return format ('repaired object OR precise per-field errors'). It covers the tool's full workflow (parsing, repairing, validating, payment gating) and parameter roles, making it sufficiently complete for an agent to invoke it correctly.

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

Parameters3/5

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

The input schema provides full descriptions for all three parameters (100% coverage), so the description adds little beyond restating that 'json' is a raw string and 'schema' is a JSON Schema object. It does add context around payment behavior via 'Without payment returns the x402 challenge', which relates to the x_payment parameter, but no new parameter-level semantics.

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 clearly states the tool's function: 'Coerce near-miss LLM JSON to a JSON-Schema-conformant object' and enumerates specific actions (strip code fences/prose, fix trailing commas, etc.). It distinguishes itself from siblings (deps_check, url_read, x402_preflight) by focusing on JSON repair with schema 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?

The description provides clear context: it is for repairing near-miss LLM JSON against a schema, and it explains the payment requirement ('PAID $0.002', 'Without payment returns the x402 challenge'). It does not explicitly name alternatives or exclusion criteria, but the purpose is specific enough to guide selection.

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

All FabTally Guard toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a clearly distinct function: package vetting, JSON repair, URL fetching, and x402 endpoint verification. There is no overlap in intent or output, making selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case object_action pattern (deps_check, json_repair, url_read, x402_preflight). This maintains uniformity and predictability across the set.

Tool Count5/5

With exactly four tools, the server is well-scoped and every tool earns its place. There is no bloat or trivial filler, and the count falls squarely within the ideal 3-15 range.

Completeness4/5

Each tool is functionally complete for its individual purpose, but the set lacks batch operations or a way to manage/retrieve prior checks. These are minor gaps that agents can work around with scripting or external state.

Resources