Skip to main content
Glama
649,985 tools. Updated 2026-10-11 02:11

"Ansible" matching MCP tools:

  • validate_yamlA

    Payload ValidatorA

    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.
    ConnectorNo auth

Matching MCP Servers