Skip to main content
Glama
Sign In

SpendPreflight

by io.github.spendpreflight
OverviewDiscussionsAdmin

ERC-8478 Draft Payee Verification

verify_payee_binding
Read-only

Use when a seller advertises an ERC-8004 identity and you need an ERC-8478 Draft wallet-binding observation. ERC-8478 Draft payee verification: endpoint origin and ERC-8004 agent wallet or EIP-712 delegation at one pinned registry block. Nine explicit outcomes; not-read is uncharged. Signed JSON observation, not payment approval or a safety guarantee. Shared trial may apply. Price: 0.01 USDC. Minimal input example: {"requirement":{"scheme":"exact","network":"eip155:8453","asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913","amount":"10000","payTo":"0xBf4164e07552e4c1b1B1597E72C7acAA3F0a1c58"},"resource_url":"https://api.spendpreflight.com/v1/check"}. Illustrative output excerpt: {"result":{"kind":"payee_binding","outcome":"no-identity","block_number":null,"block_timestamp":null},"jws":"illustrative-not-a-live-signature"}. Illustrative output excerpt, not a live result, signature, approval or guarantee. Freshness/data/availability checks still apply. How to pay (MCP): First use the existing shared allowance of 3 eligible calls per IP per UTC day, without payment metadata. This is shared with eligible HTTP trials, not a new allowance. Use an x402-capable MCP client. A generic MCP connector without payment support cannot complete a paid continuation. On payment required, STOP. Inspect the exact accepts amount, asset, network and payTo; obtain explicit wallet/budget approval before continuing. Only after approval, let the configured x402 MCP client attach its signed payload in _meta["x402/payment"] and retry the same tools/call arguments. Never send a separate USDC transfer or paste keys into tool arguments. Never silently fall back from free access to payment. If a signed attempt has an unknown outcome, inspect that authorization/transaction; do not create another automatically.

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": {
      "requirement": "<requirement>"
    },
    "name": "verify_payee_binding"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentIdNoOptional. Unsigned ERC-8004 agent ID as a decimal integer string, not a JS number. Example: "1151628". Supply together with registry; may instead use advertised extra.erc8004.
registryNoOptional. ERC-8004 registry string in eip155:chainId:0xAddress format. Example: eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432. Supply together with agentId; may instead use advertised extra.erc8004.
requirementYesRequired. One exact-scheme x402 payment requirement JSON object. Example: {"scheme":"exact","network":"eip155:8453","asset":"0x833589fcd6edb6e08f4c7c32d4f71b54bda02913","payTo":"0xBf4164e07552e4c1b1B1597E72C7acAA3F0a1c58","amount":"10000"}. Supply resource here or resource_url separately; amounts are atomic integer strings.
resource_urlNoOptional. Absolute HTTP(S) resource URL string. Example: https://api.example.com/data. Supply if the resource URL is absent from the challenge or requirement.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • addedInput schema / properties / agentId / description
      Added value: +"Optional. Unsigned ERC-8004 agent ID as a decimal integer string, not a JS number. Example: \"1151628\". Supply together with registry; may instead use advertised extra.erc8004."
    • addedInput schema / properties / registry / description
      Added value: +"Optional. ERC-8004 registry string in eip155:chainId:0xAddress format. Example: eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432. Supply together with agentId; may instead use advertised extra.erc8004."
    • addedInput schema / properties / requirement / description
      Added value: +"Required. One exact-scheme x402 payment requirement JSON object. Example: {\"scheme\":\"exact\",\"network\":\"eip155:8453\",\"asset\":\"0x833589fcd6edb6e08f4c7c32d4f71b54bda02913\",\"payTo\":\"0xBf4164e07552e4c1b1B1597E72C7acAA3F0a1c58\",\"amount\":\"10000\"}. Supply resource here or resource_url separately; amounts are atomic integer strings."
    • addedInput schema / properties / requirement / properties / amount / description
      Added value: +"Optional. Quoted amount as a nonnegative atomic-unit integer string, not decimal USDC. Example: \"10000\" = 0.01 USDC at six decimals. Required when maxAmountRequired is absent."
    • addedInput schema / properties / requirement / properties / asset / description
      Added value: +"Required. Quoted token asset identifier string; EVM assets use a 0x-prefixed 20-byte contract address. Example: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 (native Base USDC)."
    • addedInput schema / properties / requirement / properties / extra / description
      Added value: +"Optional. Advertised x402 extension JSON object, preserved as supplied. Example: {\"erc8004\":{\"registry\":\"eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432\",\"agentId\":\"1151628\"}}. Identity fields must match explicit registry/agentId if both are supplied."
    • addedInput schema / properties / requirement / properties / maxAmountRequired / description
      Added value: +"Optional. x402 v1 amount as a nonnegative atomic-unit integer string. Example: \"10000\" = 0.01 USDC. Required when amount is absent."
    • addedInput schema / properties / requirement / properties / network / description
      Added value: +"Required. Payment network identifier string; use the quoted CAIP-2 identifier. Example: eip155:8453."
    • addedInput schema / properties / requirement / properties / payTo / description
      Added value: +"Required. Quoted recipient identifier string; EVM recipients use a 0x-prefixed 20-byte address. Example: 0xBf4164e07552e4c1b1B1597E72C7acAA3F0a1c58."
    • addedInput schema / properties / requirement / properties / resource / description
      Added value: +"Optional. Absolute HTTP(S) resource URL string. Example: https://api.example.com/data. Required here or in resource_url."
    • addedInput schema / properties / requirement / properties / scheme / description
      Added value: +"Required. Payment scheme literal string exact. Example: exact; other schemes are unsupported."
    • addedInput schema / properties / resource_url / description
      Added value: +"Optional. Absolute HTTP(S) resource URL string. Example: https://api.example.com/data. Supply if the resource URL is absent from the challenge or requirement."
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds genuinely useful context beyond them: price of 0.01 USDC, a shared 3-call-per-IP-per-day trial, that not-read outcomes are uncharged, and that the response is a signed JSON observation rather than an approval. The main gap is that 'nine explicit outcomes' are asserted but never enumerated, so the agent cannot anticipate the result space; the extensive payment-flow instructions are also largely generic boilerplate.

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 purpose and trial/price information are front-loaded, which is good. However, more than half the text is repeated payment-mechanics prose (never send a separate transfer, never paste keys, never silently fall back) and the illustrative-output disclaimer is stated twice, which crowds out tool-specific information.

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?

With no output schema and a nested 4-parameter object, the description does needed extra work by showing an illustrative response shape (kind, outcome, block_number, block_timestamp, plus JWS) and explaining the free-trial-then-paid-continuation model. It is nearly complete for invocation; enumerating the nine outcomes would close the remaining gap.

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 every parameter (agentId, registry, requirement, resource_url, and the nested requirement fields) is already documented in the schema. The description adds only a concrete worked example argument, which is mildly useful but does not explain semantics beyond what the schema states, e.g. how identity is resolved from extra.erc8004 versus explicit fields.

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: 'ERC-8478 Draft payee verification: endpoint origin and ERC-8004 agent wallet or EIP-712 delegation at one pinned registry block.' That is concrete enough for an agent to know what is being observed. It does not, however, differentiate itself from the sibling 'check_payee' or 'check_endpoint', which an agent would plausibly confuse with this tool.

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?

The trigger is stated explicitly: 'Use when a seller advertises an ERC-8004 identity and you need an ERC-8478 Draft wallet-binding observation.' It also carves out what the result is not ('not payment approval or a safety guarantee'), which prevents over-reliance. It stops short of naming alternative siblings to use when the seller does not advertise an ERC-8004 identity.

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

All SpendPreflight 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