Skip to main content
Glama

Payload Validator

by com.gumballtools

Validate YAML

validate_yaml
Read-only

Validates a YAML document, including the values that mean different things to different YAML loaders.

Use this for any YAML you are about to write or have just been given — CI configs, Kubernetes manifests, docker-compose files, OpenAPI specs, Ansible playbooks.

Do not reason about YAML type resolution yourself. It is the single most reliable way to be confidently wrong about a config file, because YAML 1.1 and YAML 1.2 resolve the same plain scalar to different values and real loaders disagree about which to implement — PyYAML is 1.1, Go's yaml.v3 and the yaml npm package are 1.2:

  • no, yes, on, off, y, n are booleans in 1.1 and strings in 1.2. A country list containing no loses Norway. This is known as the Norway problem.

  • on: as a KEY, as in every GitHub Actions workflow, is the boolean true under 1.1, so the key is not "on" at all.

  • 0755 is 493 under 1.1 (octal) and 755 under 1.2 (decimal). Both are numbers, so nothing looks wrong; a file mode is simply the wrong number.

  • 1:30 is the integer 90 under 1.1, because YAML 1.1 has base-60 integers.

  • A bare 2026-01-01 is a timestamp under 1.1 and a string under 1.2.

Divergence is found by resolving each unquoted scalar under both spec versions and comparing, so the answer is what the parsers actually do rather than a list of words someone remembered. Quoted values are never flagged, because quoting is exactly how YAML says "this is a string".

Also reports: duplicate keys, tabs used as indentation (forbidden, and invisible), non-breaking spaces used as indentation (the giveaway that YAML was copied from a web page), aliases with no anchor and anchors nothing references, merge keys (<<, a 1.1 extension not in 1.2 core), multi-document streams, and alias bombs.

Input: input, the raw YAML text as a string. Up to 1,000,000 bytes.

Returns: valid (no errors), parseable (whether a conforming parser would accept it — deliberately separate, because a duplicate key parses fine and still means two different things), a diagnostics array where each entry has a 1-based line and column, a stable rule code, a message, an excerpt showing the offending line with a caret under the column, a fixHint, and blocksParse; plus counts and format-specific stats. Rule codes are stable and safe to branch on; messages are not.

Safety: nothing is resolved, fetched or expanded. External XML entities are reported, never retrieved; alias bombs are detected without being expanded; no schema or DTD is fetched over the network. Payloads are validated in memory and never stored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesThe raw document text, not a parsed object — the findings are properties of the text. Up to 1,000,000 bytes.

Schema Changelog

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

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=true, openWorldHint=false), yet the description discloses an unusually rich behavioral profile: the full set of additional findings (duplicate keys, tab and non-breaking-space indentation, dangling aliases, merge keys, multi-document streams, alias bombs), the deliberate valid-vs-parseable separation, and a detailed safety contract (no network fetches, no expansion, in-memory only, never stored). Nothing contradicts the annotations; the description reinforces the read-only profile.

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 description is long but well-structured and front-loaded: purpose in sentence one, usage in sentence two, then divergences, checks, input, return, and safety in a logical order. Every block maps to a real agent decision, though the five worked type-resolution examples are somewhat redundant with one another and could be trimmed to two or three without losing the point.

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?

With no output schema present, the description correctly carries the return-value burden, explaining valid vs parseable, the diagnostics entry shape (line, column, stable rule code, message, excerpt, fixHint, blocksParse), counts, and format stats — plus the guidance that rule codes are safe to branch on while messages are not. Combined with the safety paragraph and input constraints, an agent lacks nothing needed to call and interpret this tool correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds interpretive meaning beyond the schema: quoted values are never flagged, unquoted scalars are resolved under both spec versions, and findings are properties of the raw text rather than a parsed object. It also restates the 1,000,000-byte limit, keeping the constraint salient at call time.

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?

States a specific verb and resource — 'Validates a YAML document' — and immediately differentiates itself from siblings (validate_csv, validate_json, validate_xml, validate_auto) by focusing on the unique problem of values meaning different things to different YAML loaders. The 'Norway problem' and 1.1-vs-1.2 divergence framing make the tool's distinctive scope unmistakable.

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?

Provides explicit positive guidance: 'Use this for any YAML you are about to write or have just been given — CI configs, Kubernetes manifests, docker-compose files, OpenAPI specs, Ansible playbooks,' and a strong directive not to hand-roll YAML type reasoning. However, it never names when-not-to-use or routes to validate_auto for unknown formats, so exclusions are left to inference from the sibling list.

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

All Payload Validator 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.7/5.0
Disambiguation5/5

Each tool targets a single unambiguous format (JSON, YAML, XML, CSV), and validate_auto is explicitly differentiated from the format-specific tools with guidance on when to prefer one over the other. The cross-references in the descriptions remove any possible confusion between the auto-detector and the dedicated validators.

Naming Consistency5/5

All five tools follow the exact same validate_<format> pattern with consistent snake_case naming. validate_auto fits the pattern naturally alongside validate_json, validate_yaml, validate_xml, and validate_csv, making the tool set predictable at a glance.

Tool Count5/5

Five tools is well-scoped for a payload validation server: auto-detection plus the four dominant text data formats. Each tool earns its place and there are no redundant or filler tools.

Completeness5/5

The validation surface is complete for the stated domain — the four major serialization formats are covered with deep edge-case handling, and validate_auto fills the gap for unknown formats. Possible additions like TOML or JSON Schema validation are outside the server's apparent scope and would be scope creep rather than natural missing coverage.

Resources