Agent Revenue Network

by dev.workers.nadirventurelabs.agent-revenue-network

Remove Duplicate JSON Rows · Research Result Dedupe

result_dedupe

Read-onlyIdempotent

Discover deterministic duplicate removal for JSON-record arrays and structured research results. Supply one to eight identity fields: paid execution forms a typed composite key, preserves the first occurrence in original order, and reports exact input, output and duplicate counts; use dataset_profile when you only need duplicate measurement. 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": {
      "rows": "<rows>",
      "keys": "<keys>"
    },
    "name": "result_dedupe"
  }
}

Input Schema

Name	Required	Description	Default
`keys`	Yes	One to eight field names that together form the record identity.
`rows`	Yes	JSON object rows to deduplicate while preserving the first occurrence.

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

AddedOct 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With annotations declaring readOnly/idempotent/non-destructive, the description still adds essential behavior the annotations cannot convey: this call 'does not execute the advertised capability and does not charge,' and it returns an endpoint, price and payment guide instead. It also discloses execution semantics (typed composite key, first-occurrence preservation, count reporting) for the downstream paid call. Some of that describes the advertised capability rather than this call, which slightly blurs the picture.

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 dense sentences with little waste; the alternative and the key behavioral constraint all earn their place. Structure is slightly off because the capability semantics are front-loaded ahead of the actual 'this is a non-executing discovery call' disclosure, which an agent most needs to know first.

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 detailed, and the description covers the discovery nature, cost, alternative tool, and execution semantics. Complete enough for correct invocation, though a clearer statement of what the discovery response contains and the distinction from the paid call could be sharper.

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%, with both required parameters documented ('one to eight field names that together form the record identity', 'rows to deduplicate while preserving first occurrence'). The description's mention of 'one to eight identity fields' and first-occurrence preservation restates schema/documentation content, adding little syntactically, so the 100%-coverage baseline of 3 applies.

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 action (free discovery call returning the x402 endpoint, price and payment guide) and a specific resource domain (JSON-record deduplication), and it explicitly separates this discovery call from the advertised paid capability. However, the lead sentence describes the paid execution semantics rather than the actual behavior of this tool, so the true purpose is only revealed in the final sentence — mildly muddled against a title that reads like a mutating dedupe operation.

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?

It gives an explicit alternative with a selecting condition: 'use dataset_profile when you only need duplicate measurement.' It also clarifies when this tool applies versus paid execution. No further when-not guidance is offered, but the routing condition is concrete.

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?