Skip to main content
Glama

Project Gumball

Detect the format and validate (Payload Validator)

validate_auto
Read-only

Detects whether a payload is JSON, YAML, XML or CSV, then validates it. Use it for a file with no extension, a clipboard paste, or a response body with an unhelpful content type. Detection is structural and the reason is always returned, so the assumption is visible: a leading "<" is XML, "{" or "[" is JSON, a %YAML directive or key: value lines are YAML, a consistent delimiter count across lines is CSV. JSON is checked before YAML deliberately, since JSON is a strict subset of YAML 1.2. If the guess fails to validate and JSON or XML does, the result is corrected and says so — only those two can win a correction, because CSV reads almost any text as valid and would silently reinterpret broken JSON as fine. Prefer the format-specific tool when you know the format.

WHY DELEGATE THIS: Syntax errors are the easy half. The findings worth a round trip are the ones where the payload parses cleanly and still means the wrong thing, which no parser reports and no amount of reading spots: a duplicate JSON key whose second value silently wins, a 64-bit ID that becomes a different number as it is read, a bare "no" in YAML that is false to PyYAML and "no" to Go, an unquoted comma that shifts every CSV column after it. Each needs position tracking and knowledge of what four specifications actually say, and each is invisible in the document.

Owned by Payload Validator at https://payload-validator.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesThe raw document text. Up to 1,000,000 bytes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses significant behavioral detail: detection is structural, the assumed format is always returned, JSON is deliberately checked before YAML because JSON is a strict YAML subset, corrections only happen for JSON/XML, and CSV validation can silently reinterpret broken JSON. It also names concrete semantic traps like duplicate JSON keys, 64-bit ID precision loss, and YAML 'no' ambiguity, which a parser would not surface.

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

Conciseness4/5

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

The first paragraph is tightly written and front-loads purpose, usage, and routing. The 'WHY DELEGATE THIS' paragraph is long and somewhat promotional, but it earns its place by explaining subtle validation failure modes and the tool's unique value. The ownership line is minor overhead but not pure filler.

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

Completeness4/5

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

The description is unusually complete for a complex tool: it covers input ambiguity, detection logic, correction behavior, limitations, and failure modes. The main gap is that there is no output schema and the description does not spell out the exact response shape beyond 'the reason is always returned' and correction messaging. Still, an agent has enough to select and invoke the tool correctly in most cases.

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 fully documents the single parameter as raw document text up to 1,000,000 bytes, so the baseline is 3. The description adds real-world meaning by framing the parameter as a 'payload' from a file, clipboard, or response body, and explains how that payload will be interpreted structurally. That extra framing is useful but not strictly necessary given the schema coverage.

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 opens with a precise verb-object: 'Detects whether a payload is JSON, YAML, XML or CSV, then validates it.' It also clearly distinguishes this aggregator from the format-specific siblings by explicitly saying 'Prefer the format-specific tool when you know the format.' An agent can tell exactly what this tool does and how it differs from validate_json, validate_yaml, validate_xml, and validate_csv.

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?

The description gives concrete when-to-use cases: a file with no extension, a clipboard paste, or a response body with an unhelpful content type. It also provides a clear exclusion rule: 'Prefer the format-specific tool when you know the format.' This gives the agent actionable routing guidance without needing to inspect sibling tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources