Skip to main content
Glama
Sign In

APEX Faucet

by xyz.apexfaucet
OverviewDiscussionsAdmin

Arc payee batch

arc_payee_batch
Read-onlyIdempotent

Check up to 20 Arc addresses before paying USDC ($0.02 for the batch, or the shared 5 free checks a day, one per payee). Each address gets its own EIP-712 PayeeVerdict. A voucher (scheme apex-upto-v1) is present only when the verdict is NO_MATCH_IN_INDEX, you passed payer and amount (at least 0.01 USDC): that signature caps the payment until it expires, and PayGuard pays it once. New boxes (arc-mandate-2, factory 0x91957bd6e6da2880bf49174eaa4b5d36627af9d3) pay only on a clean PayeeVerdict whose payer is the box. pay() uses a verdict once. x402 can reuse one unexpired verdict on each free daily slot, and the daily count still applies. Boxes from the v1 factory 0x69e444f722666e13e171181efe054a93e0976b26 do not read the verdict. The v2 factory and the v2 implementation are Sourcify exact matches. DO_NOT_PAY, CAUTION and COULD_NOT_READ include no pay call. Policy: https://apexfaucet.xyz/.well-known/apex-trust.json

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": {
      "payees": "<payees>"
    },
    "name": "arc_payee_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
payerNooptional: your paying wallet. Required for a voucher.
amountNooptional: USDC amount signed in as maxAmount. At least 0.01 for a voucher.
payeesYesup to 20 Arc addresses, comma-separated
paymentNoa signed x402 payment (base64, as in PAYMENT-SIGNATURE). Pass it here and the purchase completes inside this tool call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior2/5

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

The description genuinely adds behavior annotations do not cover: cost ($0.02 or a shared 5 free checks/day, one per payee), the voucher condition requiring payer plus an amount >= 0.01 USDC, and that 'the purchase completes inside this tool call' when a signed payment is passed. That last point conflicts with readOnlyHint=true and the metered, quota-consuming behavior conflicts with idempotentHint=true, so the disclosed behavior undercuts the supplied annotations rather than complementing them.

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

Conciseness2/5

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

The purpose and price are correctly front-loaded, but the body is a single dense paragraph mixing EIP-712 voucher mechanics, three factory addresses, x402 slot reuse, and Sourcify attestation into run-on sentences. Several facts (factory 0x69e4..., Sourcify exact matches) are verification trivia that do not help an agent decide or invoke, and the lack of separation makes the operational rules hard to extract.

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 cross-chain payment-gating tool with no output schema, the description covers what an agent needs: input limit (20 addresses), pricing and free quota, the four verdict classes and which ones suppress payment, what a voucher grants and when it is issued, and a policy URL. Only the concrete response shape (how the 20 per-address verdicts are returned) is left 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: payer and amount are conditionally required only when a voucher is needed, amount must be at least 0.01 USDC, and passing a signed payment settles the purchase in-call. These conditional relationships are not expressible in the flat schema and are the most valuable part of the 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 opening clause is specific: 'Check up to 20 Arc addresses before paying USDC', giving an explicit verb (check), resource (Arc payee addresses), and the batch scope that separates it from a single-address check. The remainder of the description drifts into voucher schemes, factory addresses, and Sourcify verification, which muddies but does not obscure the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes the context ('before paying USDC') and states that DO_NOT_PAY, CAUTION and COULD_NOT_READ outcomes include no pay call, which is actionable. However, it never names the single-address sibling (arc_payee_check) or any of the payment alternatives (pay_preflight, pay_safe, arc_verdict) as the choice for one payee, leaving the batch-vs-single routing to inference.

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