Skip to main content
Glama
Sign In

APEX Faucet

by xyz.apexfaucet
OverviewDiscussionsAdmin

Pay preflight

pay_preflight

Before USDC moves on Arc: one call runs the payee check and, when you pass resource, nonce and amount together, the duplicate check. Summary is DO_NOT_PAY, DUPLICATE, COULD_NOT_READ, CAUTION or NO_MATCH_IN_INDEX. The signatures are the existing PayeeVerdict and DuplicateVerdict. There is no new domain. A FRESH verdict only means that fingerprint was not seen inside the window. NO_MATCH_IN_INDEX means nothing in the Arc index pointed against this payee. An amount under 0.01 USDC is CAUTION on the payee half. This is not a permission to pay. Five free a day at /pay-preflight, then $0.01. Live counts stay on arc_poison_stats.

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": {
      "payee": "<payee>"
    },
    "name": "pay_preflight"
  }
}

Input Schema

NameRequiredDescriptionDefault
nonceNooptional EIP-3009 nonce: 0x and 64 hex
payeeYes0x address you are about to pay
payerNooptional: your paying wallet
amountNoUSDC decimal like 0.01, or atomic units (3000 is $0.003) only when resource and nonce are set
windowNooptional seconds for the duplicate half. Default 600. Clamped from 60 to 86400.
paymentNoa signed x402 payment (base64, as in PAYMENT-SIGNATURE). Pass it here and the purchase completes inside this tool call.
resourceNooptional https resource URL. Required with nonce and amount to record a duplicate sighting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description does substantial work: it enumerates every possible summary value, defines what FRESH and NO_MATCH_IN_INDEX actually mean, explains the sub-0.01 USDC CAUTION rule, warns that the result is not permission to pay, and discloses the rate limit and price (5 free/day, then $0.01). It also notes that passing a signed payment completes the purchase inside the call, a meaningful side effect. It remains quiet on how long a result is cached and on what else the payload contains beyond the verdict summary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical scoping statement is front-loaded, which is good, but the remainder is a run of terse fragments ("There is no new domain.", "The signatures are the existing PayeeVerdict and DuplicateVerdict") whose relevance to an agent deciding how to call it is marginal. Dense and telegraphic rather than wasteful, but tightening would help.

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?

For a seven-parameter tool with no output schema, the description carries the return semantics by enumerating the five possible summaries and their meanings, and it covers cost and rate limits. Gaps are minor: the payer parameter is never discussed, and the conditional duplicate path is described but not illustrated. Overall it is sufficient to invoke the tool correctly.

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 schema documents each parameter individually. The description adds cross-parameter semantics the schema does not: resource, nonce and amount must be supplied together to trigger the duplicate sighting, and small amounts downgrade the payee half to CAUTION. That joint-usage meaning is genuine value beyond the per-field text.

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 and resource: a pre-payment check that runs the payee check and, conditionally, the duplicate check before USDC moves on Arc. It also distinguishes itself from arc_poison_stats by noting live counts stay there. It stops short of explicitly naming the sibling tools it supersedes (arc_payee_check, duplicate_check), so sibling differentiation is implied rather than stated.

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 clear invocation context ("Before USDC moves on Arc") and states the condition that activates the duplicate half: resource, nonce and amount passed together. It also routes the agent elsewhere for live counters via arc_poison_stats. It does not say when a caller should prefer the standalone payee or duplicate checks instead, so there is no explicit exclusion rule.

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

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