agent-tools (x402 + MCP + A2A directory)

prepare_paid_verification

Quote a sponsored paid verification of an x402 service.

You pay the service once from your own wallet (Base USDC, <= $1; funds go
to its payTo). Sign the returned `typed_data` (EIP-712), then call
`execute_paid_verification` before `valid_before`. We never sign or hold funds.

Auth: API key from POST https://agent-tools.cloud/api/v1/keys, as the
`Authorization: Bearer` header or `api_key`.

Args:
    slug: Service slug from `search` / `get`.
    payer: 0x address of the wallet that will sign and pay.
    api_key: Optional if the Authorization header is sent.

Returns:
    { id, amount_usd, pay_to, valid_before, typed_data, ... } or { error, message }.

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": {
      "slug": "<slug>",
      "payer": "<payer>"
    },
    "name": "prepare_paid_verification"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	Service slug from `search` / `get`.
`payer`	Yes	0x address of the wallet that will sign and pay.
`api_key`	No	Optional if the Authorization header is sent.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 1, 2026
- addedInput schema / properties / api_key / description
```
Added value: +"Optional if the Authorization header is sent."
```
- addedInput schema / properties / payer / description
```
Added value: +"0x address of the wallet that will sign and pay."
```
- addedInput schema / properties / slug / description
```
Added value: +"Service slug from `search` / `get`."
```
AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say this is a non-destructive, non-read-only, non-idempotent call. The description goes far beyond: it discloses the real money movement (Base USDC, <= $1, sent to payTo), that the caller signs EIP-712 typed_data, the validity window, and the 'we never sign or hold funds' custody boundary. Those are exactly the behavioral facts an agent needs before committing funds.

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 purpose, then a compact flow paragraph, then Args/Returns. Every line is relevant, but the Args and Returns blocks duplicate the input schema and output schema respectively rather than adding to them, so it is slightly longer than strictly necessary.

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 tool that moves money, the description covers auth, payment mechanics, signing, expiry, custody guarantees, and error shape. With an output schema present, it does not need to enumerate return fields further, and nothing an agent needs to call this correctly is missing.

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% and the description's Args block restates the schema text near-verbatim, adding no extra format detail (e.g. slug format, address validation). Baseline 3 applies when the schema already carries parameter meaning.

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 specific verb+resource ('Quote a sponsored paid verification of an x402 service') and immediately positions it in a two-step flow with `execute_paid_verification`. An agent can distinguish it from every sibling, including the closely related `get_paid_verification` and `execute_paid_verification`, without opening a schema.

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?

It states the exact sequence (prepare → pay from your own wallet → sign typed_data → call execute_paid_verification before valid_before), the auth prerequisite with the key-issuing endpoint, and the payment cap. That is explicit when-to-use plus the condition that gates the next step.

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

All agent-tools (x402 + MCP + A2A directory) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.