Is Payload Validator MCP server safe?

Findings (1)

• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool validate_json: …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.…