Agent Revenue Network

JSON Normalization · Stable Key Ordering

json_normalize

Read-onlyIdempotent

Discover deterministic JSON normalization for any JSON value: paid HTTP execution recursively sorts object keys, preserves array order and scalar values, and returns normalized structure plus a deterministic JSON string. Use it for stable comparisons, cache keys and repeatable payloads; use json_diff to identify changes, and never treat this as RFC 8785/JCS canonicalization. This free MCP discovery call does not execute the advertised capability and does not charge; it returns the exact x402 endpoint, price and payment guide for execution.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "value": "<value>"
    },
    "name": "json_normalize"
  }
}

Input Schema

Name	Required	Description	Default
`value`	Yes	Any JSON value to normalize. Object keys are recursively sorted; array order and scalar values are preserved.

Output Schema

Name	Required	Description
`price`	Yes
`method`	Yes	HTTP method for paid execution.
`endpoint`	Yes	Canonical absolute ARN HTTP URL to POST the same tool arguments to for paid execution.
`protocol`	Yes	Payment protocol required by the HTTP execution endpoint.
`instruction`	Yes	How to execute the capability after receiving the payment requirement.
`paymentGuide`	Yes	Public setup guide with a working x402 v2 Base-mainnet client example.
`paymentRequired`	Yes	Always true for paid ARN capabilities exposed over MCP.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

changedOutput schema / properties / endpoint / description

Previous value: -"ARN HTTP path to POST the same tool arguments to for paid execution."New value: +"Canonical absolute ARN HTTP URL to POST the same tool arguments to for paid execution."

addedOutput schema / properties / endpoint / format
```
Added value: +"uri"
```

addedOutput schema / properties / method

Added value: +{
+  "const": "POST",
+  "description": "HTTP method for paid execution.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "paymentRequired",
-  "protocol",
-  "endpoint",
-  "price",
-  "paymentGuide",
-  "instruction"
-]New value: +[
+  "paymentRequired",
+  "protocol",
+  "method",
+  "endpoint",
+  "price",
+  "paymentGuide",
+  "instruction"
+]

Changed2 schema fields changedOct 8, 2026

addedOutput schema / properties / paymentGuide

Added value: +{
+  "description": "Public setup guide with a working x402 v2 Base-mainnet client example.",
+  "format": "uri",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "paymentRequired",
-  "protocol",
-  "endpoint",
-  "price",
-  "instruction"
-]New value: +[
+  "paymentRequired",
+  "protocol",
+  "endpoint",
+  "price",
+  "paymentGuide",
+  "instruction"
+]

Changed4 schema fields changedOct 2, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / description

Added value: +"Input for deterministic JSON key-order normalization."

addedInput schema / properties / value / description

Added value: +"Any JSON value to normalize. Object keys are recursively sorted; array order and scalar values are preserved."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "MCP payment instruction. Calling the MCP tool itself does not charge or execute the paid operation.",
+  "properties": {
+    "endpoint": {
+      "description": "ARN HTTP path to POST the same tool arguments to for paid execution.",
+      "type": "string"
+    },
+    "instruction": {
+      "description": "How to execute the capability after receiving the payment requirement.",
+      "type": "string"
+    },
+    "paymentRequired": {
+      "const": true,
+      "description": "Always true for paid ARN capabilities exposed over MCP.",
+      "type": "boolean"
+    },
+    "price": {
+      "additionalProperties": false,
+      "properties": {
+        "amount": {
+          "description": "Atomic asset amount.",
+          "type": "string"
+        },
+        "asset": {
+          "description": "Settlement asset.",
+          "type": "string"
+        },
+        "display": {
+          "description": "Human-readable current price.",
+          "type": "string"
+        },
+        "network": {
+          "description": "CAIP-2 settlement network identifier.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "amount",
+        "asset",
+        "network",
+        "display"
+      ],
+      "type": "object"
+    },
+    "protocol": {
+      "const": "x402",
+      "description": "Payment protocol required by the HTTP execution endpoint.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "paymentRequired",
+    "protocol",
+    "endpoint",
+    "price",
+    "instruction"
+  ],
+  "type": "object"
+}

First observedOct 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds genuinely non-obvious context — that this call is free, does not execute the advertised paid capability, and returns the x402 endpoint, price and payment guide. It also discloses the normalization semantics (recursive key sort, array order preserved). It is slightly muddled in that most of the text describes the remote paid capability rather than this MCP tool's own behavior.

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 capability and the discovery-call caveat are front-loaded, and the sentence count is reasonable for the amount of routing and payment context conveyed. It loses a point for restating the key-sorting semantics that the input schema already documents verbatim.

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?

An output schema exists so return values need not be spelled out; the description still covers routing, exclusions, cost, and the fact that execution is deferred to a paid endpoint — everything an agent needs to call this correctly. Minor gap is that it never says what the discovery response's fields look like at a glance, leaving that entirely to the output schema.

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?

Single parameter with 100% schema description coverage, so the baseline is 3. The description restates the same normalization semantics already present in the 'value' property description ('object keys are recursively sorted; array order and scalar values are preserved'), adding no syntax, format, or constraint information beyond 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+resource ('discover deterministic JSON normalization for any JSON value') and explicitly delimits scope, naming the sibling to use instead for change detection ('use json_diff to identify changes') and disclaiming a commonly-confused standard ('never treat this as RFC 8785/JCS canonicalization'). An agent can distinguish this from json_diff and json_schema_check without opening any schema.

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?

Gives concrete when-to-use cases ('stable comparisons, cache keys and repeatable payloads'), an explicit alternative with its triggering condition ('use json_diff to identify changes'), and a when-not-to-use warning about JCS canonicalization. Nothing about routing is left to inference.

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

All Agent Revenue Network tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?