Agent Revenue Network

Tabular Comparison · CSV / Spreadsheet Record Diff

tabular_diff

Read-onlyIdempotent

Discover row-level comparison between two JSON-record tables keyed by one unique field. Paid execution reports added and removed keys plus changed rows with field-level evidence while preserving deterministic order; CSV or spreadsheet rows must be converted to JSON first. Use json_diff for arbitrary nested JSON or tabular_validate to enforce row contracts. 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.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Field name used as the unique record identity in both datasets.
`after`	Yes	New keyed JSON record set to compare with before.
`before`	Yes	Original keyed JSON record set.

Output Schema

TableJSON 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"
+]

AddedOct 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: the free call does not execute the advertised capability, does not charge, and returns the x402 endpoint, price and payment guide. It also discloses that paid execution yields added/removed keys, changed rows with field-level evidence, and deterministic ordering.

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?

Three front-loaded sentences with no filler, purpose stated first and pricing/execution caveats last. Slightly dense with multiple embedded clauses, but every sentence contributes routing or behavioral 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?

An output schema exists so return values need not be re-explained, and the description supplies the one non-obvious thing an agent needs: that this is a free discovery stub whose response is an endpoint/price/payment guide, plus what the eventual paid execution returns. Nothing required 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 description coverage is 100%, so before/after/key are already documented by the schema. The description adds only the notion that records are keyed by one unique field, which mildly clarifies the 'key' parameter but no format or syntax detail beyond the schema, matching the baseline 3 for full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (discover/compare) and resource (row-level comparison of JSON-record tables keyed by one unique field), and it clarifies at the end that this is a discovery call returning an x402 endpoint rather than an executor. The tension between the name/title ('tabular_diff', 'Tabular Comparison') which imply actual diffing and the reality of a paid-execution discovery stub is resolved only in the final sentence, so slight ambiguity remains.

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?

It explicitly names two alternative siblings and their distinct purposes: json_diff for arbitrary nested JSON and tabular_validate to enforce row contracts. It also states the precondition that CSV/spreadsheet rows must be converted to JSON first, leaving no routing decision 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

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?