F
licenseNot graded
qualityB
maintenanceValidates OpenAPI documents, JSON Schemas, and JSON payloads. Also compares OpenAPI specs and displays breaking changes.
-
Payload Validator
Server Details
Validate JSON, YAML, XML and CSV with exact line/column errors and silent-corruption warnings.
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
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolsvalidate_autoDetect the format and validateARead-onlyInspect
Detects whether a payload is JSON, YAML, XML or CSV, then validates it.
Use this when you have a blob of text and do not know what it is — a file with no extension, a clipboard paste, a response body with an unhelpful content type, or a config file whose format you would otherwise have to guess.
Detection is structural and the reason is always returned, so the assumption is visible rather than hidden: a leading < is XML, a leading { or [ is JSON, a %YAML directive or key: value lines are YAML, and a consistent delimiter count across multiple lines is CSV. JSON is checked before YAML on purpose, because JSON is a strict subset of YAML 1.2 and every JSON document would otherwise be ambiguous.
If the detected format does not validate but JSON or XML does, the result is corrected and detection.corrected is true. Only those two can win a correction, because only they have decisive grammars — CSV will read almost any text as a valid single-column file, so "it validates as CSV" is not evidence, and allowing it would silently reinterpret broken JSON as fine.
Prefer the format-specific tool when you already know the format: it skips detection and cannot be corrected out from under you.
Input: input, the raw text. 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. Additionally detection with the chosen format, the reason in one sentence, and corrected.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw document text, not a parsed object — the findings are properties of the text. Up to 1,000,000 bytes. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, but the description goes far beyond this: it explains structural detection logic, the deliberate JSON-before-YAML ordering, the correction rule limited to JSON/XML, the parseable-vs-valid distinction, diagnostic entry contents, and explicit safety guarantees (no network, no expansion, no storage). This richly discloses behaviors an agent could not infer from annotations or schema.
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 into purpose, usage, detection logic, correction behavior, return values, and safety. Each paragraph earns its place, and the most decision-relevant information (purpose and when to use) comes first. A slight deduction for repeating the byte limit already present in the schema and for including more detail on diagnostics than an agent strictly needs to decide on invocation.
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?
For a tool with one simple parameter, no output schema, and read-only annotations, this description covers all bases: use cases, alternatives, detection and correction semantics, full return structure, and safety constraints. An agent has everything needed to call it correctly and understand the result.
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?
Schema coverage is 100% and the schema already describes the single parameter as raw document text with the 1,000,000-byte limit. The description repeats those details and adds contextual examples like clipboard paste and config file, but does not materially expand the parameter's semantics beyond what the schema already provides.
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 states a specific verb and resource: 'Detects whether a payload is JSON, YAML, XML or CSV, then validates it.' It clearly distinguishes itself from format-specific siblings by positioning itself as the auto-detecting variant and explicitly naming the alternative tools to prefer when the format is known.
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?
Usage is explicit: 'Use this when you have a blob of text and do not know what it is' lists concrete scenarios, and it warns to 'Prefer the format-specific tool when you already know the format.' It also explains the trade-off: detection can be corrected, while the format-specific tools cannot be corrected out from under you.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_csvValidate CSVARead-onlyInspect
Validates CSV text against RFC 4180 and reports ragged rows individually, with both field counts.
Use this before loading a CSV, and whenever a CSV-derived number looks wrong.
Do not attempt this by reading the file, and be aware that loading it successfully proves nothing. The failure that matters is the ragged row: a file where one row has six fields and the header has five loads without complaint almost everywhere — pandas pads or throws depending on the engine, Excel shifts the columns, and split(",") silently mis-assigns every field after the extra one. Nobody notices until a figure is wrong in a report. This reports it as "row 4813 has 6 fields; the header has 5", per row.
The other half is the delimiter. A European CSV is semicolon-separated because the comma is the decimal separator; reading it as comma-separated yields one column of nonsense and no error. The delimiter is sniffed from the header — ignoring quoted regions so their contents cannot vote — and always reported, with a warning when the guess was a close call. Pass delimiter to remove the guess entirely.
Also reports: unterminated quotes (which swallow the rest of the file into one field, which is why one typo can make thousands of rows look ragged), text after a closing quote, stray quotes in unquoted fields, duplicate column names, unnamed columns, column names with invisible leading or trailing whitespace, mixed CRLF/LF line endings, CR-only endings, and a byte order mark — which becomes part of the first column's name, so a lookup for "id" fails against a column that prints identically.
Input: input, the raw CSV text. Optional delimiter (a single character) and hasHeader (default true; pass false and rows are compared against the first row instead, and header checks are skipped). 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw document text, not a parsed object — the findings are properties of the text. Up to 1,000,000 bytes. | |
| delimiter | No | Field delimiter, as a single character. Omit to sniff it from the header. Pass it when you know it — a semicolon-separated European export read as comma-separated produces one column and no error. | |
| hasHeader | No | Whether the first row names the columns. Default true. Pass false and rows are compared against the first row instead, and header checks are skipped. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, yet the description adds substantial behavior beyond them: the valid-vs-parseable distinction, stable rule codes vs unstable messages, delimiter-sniffing mechanics, and a full safety disclosure (nothing resolved, fetched or expanded; no network schema/DTD retrieval; never stored). It even explains failure modes like unterminated quotes swallowing the file. No contradiction — readOnlyHint matches the 'validated in memory and never stored' claim.
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 dense, and the core purpose is front-loaded before any context. The pandas/Excel/split narrative earns its place by explaining why a validating tool beats manual parsing, and the closing safety paragraph covers the remaining burden. Slightly more illustrative prose than strictly necessary, but every paragraph serves a function.
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, the description carries the full burden of explaining return values — and it does in detail (valid, parseable, diagnostics array with line/column/rule/message/excerpt/fixHint/blocksParse, counts, stats). It also covers size limits, all detection categories, parameter behavior, and safety. For a tool with this complexity, nothing an agent needs to call it correctly is missing.
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?
Schema coverage is 100% for all three parameters, and the 'Input' section largely restates the schema's descriptions (delimiter single character, hasHeader default true, 1,000,000-byte limit). It adds some rationale (why delimiter sniffing matters, rows compared against the first row when no header) but does not meaningfully extend what the schema already documents, keeping it at the high-coverage baseline.
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?
Opens with a precise verb+resource+standard: 'Validates CSV text against RFC 4180 and reports ragged rows individually, with both field counts.' The CSV target cleanly distinguishes it from sibling validators validate_json/xml/yaml/auto, and the specific mention of ragged-row reporting describes concrete behavior rather than restating the name.
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?
Gives explicit when-to-use triggers ('Use this before loading a CSV, and whenever a CSV-derived number looks wrong') and a clear when-not ('Do not attempt this by reading the file' plus 'loading it successfully proves nothing'). However, it never mentions the validate_auto sibling for format auto-detection, and the named alternatives are manual processes (pandas, Excel, split), so it stops just short of full sibling routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_jsonValidate JSONARead-onlyInspect
Validates a JSON document and reports every problem with an exact line and column.
Use this whenever you need to know why a JSON payload is failing, or to check a JSON document you or a user produced before sending it somewhere that will reject it.
Do not do this by reading the JSON yourself. Three of the findings are invisible to inspection and to JSON.parse alike:
(1) Duplicate keys. {"port":8080,"port":9090} is accepted by every mainstream parser, which keeps the last value and discards the first without a word. Reading it, you cannot see which one the consumer will use, because the answer differs by language.
(2) Integer precision loss. 9007199254740993 parses as 9007199254740992 — quietly, because JSON numbers are IEEE-754 doubles in nearly every parser, exact only to 2^53-1. Any 64-bit ID (Twitter, Discord, most database bigints) is in the lossy range. This tool proves the loss with exact BigInt arithmetic rather than estimating it.
(3) Lone surrogates. "\ud83d" alone is syntactically legal and cannot be encoded as UTF-8, so the document parses here and fails somewhere else entirely.
It also reports, with positions: trailing commas, comments, single-quoted strings, unquoted keys, Python literals (True/None/NaN/Infinity), leading zeros, hex numbers, unescaped control characters, raw line breaks inside strings, byte order marks, and trailing content — including recognising when the input is actually NDJSON being read as one document.
Input: input, the raw JSON text as a string. Not a parsed object — the text, because the findings are properties of the text. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw document text, not a parsed object — the findings are properties of the text. Up to 1,000,000 bytes. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation by explaining invisible failure modes, the separate parseable flag, stable rule codes, exact positions, input size limits, and the safety guarantees about not fetching, expanding, or storing payloads. This gives an agent a realistic model of what will happen when the tool runs.
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 paragraph earns its place: purpose, when to use it, invisible failure classes, input constraints, return shape, and safety behavior. It is front-loaded with the main function and structured so an agent can quickly extract the decision-relevant information.
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 fully documents the return contract: valid, parseable, diagnostics with line/column/rule/message/excerpt/fixHint/blocksParse, plus counts and stats. It also covers safety and size limits, so an agent has enough context to call and interpret the tool 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?
Schema coverage is 100%, so the schema already documents the single input parameter. The description reinforces that input must be raw text, not a parsed object, but it largely repeats the schema's own wording rather than adding substantially new semantic meaning.
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 specific verb and resource: 'Validates a JSON document and reports every problem with an exact line and column.' It clearly distinguishes JSON validation from the sibling format validators and includes concrete examples of what it catches, so an agent can tell exactly what this tool does.
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 gives an explicit trigger: 'Use this whenever you need to know why a JSON payload is failing, or to check a JSON document you or a user produced before sending it somewhere that will reject it.' It also warns against doing the check manually. It doesn't explicitly name validate_auto or the format-specific siblings as alternatives, but the JSON scope makes the boundary clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_xmlValidate XMLARead-onlyInspect
Validates an XML document for well-formedness, namespace correctness, and the entity-based attacks that arrive as XML.
Use this before parsing XML you received, and when an XML document is being rejected by something that will not say why.
Do not eyeball this. Four classes of genuinely invalid XML are accepted by ordinary well-formedness checkers, so "it validated" does not mean what it appears to:
(1) Two root elements. <a/><b/> is not a valid XML document; XML permits exactly one outermost element. Concatenated records hit this constantly.
(2) Undeclared namespace prefixes. <x:a> with no xmlns:x is well-formed as raw XML and invalid under Namespaces in XML — so it passes a syntax check and is then rejected by XPath, XSLT, SOAP and every schema validator.
(3) Undeclared entities. XML predefines only five (< > & ' "). is an HTML entity and is simply undefined in XML.
(4) A bare &, almost always arriving inside a URL.
Security findings, which are the reason to run this on input you did not write: external entity declarations (XXE — reported with the URI they point at and the remediation for Python, Java and .NET), nested entity expansion (billion laughs), parameter entities (the out-of-band XXE vehicle), external DTD references (an SSRF vector and a runtime dependency on someone else's host), and any DOCTYPE at all, since hardened parsers reject them outright.
Input: input, the raw XML 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw document text, not a parsed object — the findings are properties of the text. Up to 1,000,000 bytes. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnlyHint and openWorldHint annotations by explaining exactly what is and isn't done: nothing is resolved, fetched, expanded, or stored. It also warns about common false positives and explains the 'valid' vs 'parseable' distinction.
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?
Long but well-organized, with a clear lead sentence, explicit usage guidance, a numbered list of subtle failure modes, and a structured explanation of returns and safety. Every paragraph adds meaningful decision-making or interpretation value.
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?
For a complex security-relevant validator with no output schema and minimal annotations, the description is exceptionally complete: it covers input bounds, return semantics, stable rule codes, safety guarantees, and the specific attack classes an agent should expect.
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?
Schema coverage is 100%, so the schema already documents the `input` parameter. The description adds a clarifying reminder that the input is raw text, not a parsed object, but largely restates information already present in the schema.
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 ('Validates') and resource ('XML document') with precise scope: well-formedness, namespace correctness, and entity-based attacks. This clearly distinguishes it from JSON, CSV, YAML, and auto-format validators.
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?
Explicitly says when to use it: before parsing received XML and when an XML document is rejected without explanation. It does not explicitly say when not to use it or name a specific alternative, so it stops just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_yamlValidate YAMLARead-onlyInspect
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,nare booleans in 1.1 and strings in 1.2. A country list containingnoloses Norway. This is known as the Norway problem.on:as a KEY, as in every GitHub Actions workflow, is the booleantrueunder 1.1, so the key is not "on" at all.0755is 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:30is the integer 90 under 1.1, because YAML 1.1 has base-60 integers.A bare
2026-01-01is 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The raw document text, not a parsed object — the findings are properties of the text. Up to 1,000,000 bytes. |
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
- First observed
validate_auto - First observed
validate_csv - First observed
validate_json - First observed
validate_xml - First observed
validate_yaml
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Validate oh-my-posh configurations and segment snippets against the official schema.
EN 16931: validate invoice data or a UBL/CII file, emit UBL or CII XML. XRechnung, Peppol. Not PDF.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Validate and convert JSONL fine-tuning data across 11 AI providers. 13 tools.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceDeterministic 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
- AlicenseAqualityCmaintenanceValidates electronic invoices (XRechnung, ZUGFeRD, Factur-X, Peppol BIS, etc.) against authority-pinned rules and explains failures.221MIT
- AlicenseNot gradedqualityAmaintenanceValidates Excel (.xlsx) workbooks against reviewed, lockable acceptance contracts, catching errors and outputting structured issues that agents can repair.1MIT
Try in Browser
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.