APEX Faucet

Duplicate check

duplicate_check

Before you pay the same x402 request again: flags a repeat of resource + payee + amount + nonce inside a time window (default 600 seconds, clamped from 60 to 86400). EIP-712 signed (domain APEX DuplicateGuard, type DuplicateVerdict) by the payee attester. Verdicts: FRESH, DUPLICATE, COULD_NOT_RECORD. This is not a permission to pay, and PayGuard does not read this signature. One check is $0.003 after 5 free a day; up to 20 is $0.01 (pass items). A batch of 21 is refused and nothing is recorded. Free doors: /check/duplicate and /check/duplicate/batch. The official client hook runs before the EIP-3009 nonce exists, so pass the nonce you will sign. Live poisoning counts stay on arc_poison_stats.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "duplicate_check"
  }
}

Input Schema

Name	Required	Description
`items`	No	JSON array of up to 20 checks, each with resource, payee, amount and nonce. When this is set, the single fields are not used.
`nonce`	No	EIP-3009 nonce: 0x and 64 hex characters. The official x402 client creates this after onBeforePaymentCreation, so pass the nonce you will sign.
`payee`	No	0x address that would be paid
`amount`	No	Atomic USDC (6 decimals, 3000 means $0.003) or a decimal like 0.003. A bare 1 is 1 atomic unit, not 1 USDC.
`window`	No	Seconds. Default 600. Clamped from 60 to 86400.
`payment`	No	a signed x402 payment (base64, as in PAYMENT-SIGNATURE). Pass it here and the purchase completes inside this tool call.
`resource`	No	Exact https resource URL the payment would buy

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations at all, the description carries the full burden and does well: it discloses pricing tiers ($0.003 after 5 free/day, $0.01 for up to 20 via items), the hard refusal at 21 with nothing recorded, the EIP-712 signing domain (APEX DuplicateGuard / DuplicateVerdict), and the verdict set FRESH/DUPLICATE/COULD_NOT_RECORD. The main remaining gap is what happens on COULD_NOT_RECORD (charge? retry?), which affects whether an agent should proceed.

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?

Front-loaded with the trigger condition and one-check-per-idea sentences, with almost no filler. It is dense and slightly telegraphic (pricing, signing domain, endpoints, and ordering caveats packed into one block), so a little structural separation would improve scanability, but every sentence carries 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?

For a seven-parameter, annotation-free, no-output-schema tool, this covers what's needed to call it correctly: input key semantics, batch vs single mode, limits, cost, verdict values, signature provenance, and the free endpoint escape hatches. Only the semantics of COULD_NOT_RECORD remain unspecified.

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 already 100%, so the baseline is 3; the description earns extra by stating the window default (600s) and its 60-86400 clamp, the items-batch ceiling of 20 and that batch mode supersedes the single fields, and the nonce timing caveat ('the hook runs before the EIP-3009 nonce exists, so pass the nonce you will sign'). That adds cross-parameter behavior the schema cannot express.

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 concrete condition and a concrete action: 'Before you pay the same x402 request again: flags a repeat of resource + payee + amount + nonce inside a time window.' That names the exact matching key and scope, not just a restatement of the name. It also foregrounds what it is not ('not a permission to pay, PayGuard does not read this signature'), which separates it from the many payment-adjacent siblings.

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?

Explicit when-to-use ('before you pay the same x402 request again'), explicit when-not ('not a permission to pay'), and an explicit hand-off for a related concern ('Live poisoning counts stay on arc_poison_stats'). It even states the hard batch limit of 20 and that 21 is refused, so the agent knows the operating envelope before calling.

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

All APEX Faucet 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.