CryptoAd Network

Buy prepaid ad credit

buy_ad_credit

Idempotent

Buys prepaid ad credit at a fixed price: amount_usd in USDC, 1 USDC = $1.00 of credit (for example 5, 10, 25, 50, 100). The first call returns isError with the x402 PaymentRequired object; call again with the signed payment. Without an API key the paid result carries api_key: the key of a new account whose balance is the credit, shown once. With an API key the credit is added to that account. Orders placed with the key are then paid from the balance, with no further payment.

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": {
      "amount_usd": "<amount_usd>"
    },
    "name": "buy_ad_credit"
  }
}

Input Schema

Name	Required	Description
`api_key`	No	The API key of the account (can_live_...). Optional when this MCP connection sends it as the Authorization: Bearer header.
`amount_usd`	Yes	Whole dollars ("25") or two decimals ("25.00").
`idempotency_key`	No	Only to REPEAT an earlier call of this tool (a lost answer, a payment still confirming): the idempotency_key that call returned. Leave it out for a new call; the server then makes a random one and returns it.
`payment_signature`	No	The x402 PaymentPayload for the requirement an earlier call of this tool returned, as base64-encoded JSON (the value of an HTTP PAYMENT-SIGNATURE header). An x402-aware MCP client sends the payload in _meta["x402/payment"] instead and leaves this out.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare a non-read-only, idempotent, open-world mutation, and the description adds the behavior those hints cannot convey: the two-phase x402 payment handshake, that the api_key is shown only once, and that orders placed with that key are subsequently paid from the balance with no further payment. This is real disclosure beyond structured fields, with no contradiction of destructiveHint=false.

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?

The payment flow and account semantics are front-loaded, and each sentence carries distinct information. It is dense — the third and fourth sentences pack multiple clauses — but nothing is redundant or filler.

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 payment tool with no output schema, the description covers the critical return behavior: the PaymentRequired error on first call and the one-time api_key in the paid result. It is slightly thinner on the full success payload (e.g. resulting balance or the returned idempotency_key), which an agent must infer from the schema.

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 genuine meaning: amount_usd is denominated in USDC at a fixed 1:1 rate with concrete example values, and api_key determines whether a new account is created or an existing one is topped up. It doesn't restate the payment_signature's base64 encoding, which the schema already covers.

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?

Opens with a specific verb and resource ("Buys prepaid ad credit at a fixed price") and immediately pins down the unit of exchange (USDC at 1:1 with credit dollars). That makes it clearly distinguishable from siblings like quote_ad, get_balance, and create_ad without needing to open any 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 spells out the exact call sequence: the first call returns isError with the x402 PaymentRequired object, then call again with the signed payment. It also states the two account paths (no API key = new account, API key = top-up) and restricts idempotency_key to repeats only, which is unusually explicit when-to guidance.

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

All CryptoAd Network 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.

Resources

Need Help?