Skip to main content
Glama
Sign In

alalanet — check before you pay

by com.alalanet
OverviewDiscussionsAdmin

Did my x402 payment settle? May I pay again?

payment_status
Read-only

Tells whether an x402 payment settled, for use after a timeout, a 5xx or any unclear answer to a paid request and before a new payment is signed. Pass network and the settlement tx, or (EVM exact) from + nonce + valid_before of the signed authorization, or (Solana exact) from + the recentBlockhash of the signed transaction; the signature itself is not needed. safe_to_sign_new is true only when a new payment cannot pay twice. alalanet reads the chain and answers state (settled | pending | not_settled | expired_unsettled | failed) and retry: do_not_pay_again, resend_same (same authorization can settle only once), new_payment_ok, or wait. Prevents paying twice. Read-only (nothing is signed or logged); the error chain_unavailable means the payment networks did not answer, and the same question can be asked again after 15 s.

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": {
      "network": "<network>"
    },
    "name": "payment_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
txNosettlement transaction hash from the transaction field of the PAYMENT-RESPONSE header (0x + 64 hex on Base, base58 signature on Solana), if you got one
fromNopayments without a tx: EVM exact: payload.authorization.from of the PAYMENT-SIGNATURE you sent (your wallet address); Solana exact: your wallet address (the signer of the transaction besides the facilitator's fee payer)
assetNotoken contract; default USDC on Base
nonceNoEVM exact payments without a tx: payload.authorization.nonce of the PAYMENT-SIGNATURE you sent (0x + 64 hex); never send the signature itself
networkYesBase: eip155:8453 or base; Solana: solana or solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
blockhashNoSolana exact payments without a tx: the recentBlockhash of the transaction you signed (base58); with from it identifies your payment, since the facilitator's fee-payer signature (the transaction id) is unknown to you before settlement
valid_beforeNopayload.authorization.validBefore (unix seconds): lets alalanet tell an expired, unused authorization (safe to pay anew) from one that may still settle

Output Schema

NameRequiredDescriptionDefault
txNo
retryYes
stateYes
adviceYes
sourceYes
networkYes
checked_atYes
reported_outcomeNo
safe_to_sign_newYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedOutput schema / additionalProperties
      Removed value: -false
  2. Changed4 schema fields changed
    • addedInput schema / properties / blockhash
      Added value: +{
+  "description": "Solana exact payments without a tx: the recentBlockhash of the transaction you signed (base58); with from it identifies your payment, since the facilitator's fee-payer signature (the transaction id) is unknown to you before settlement",
+  "type": "string"
+}
    • changedInput schema / properties / from / description
      Previous value: -"EVM exact payments without a tx: payload.authorization.from of the PAYMENT-SIGNATURE you sent (your wallet address)"New value: +"payments without a tx: EVM exact: payload.authorization.from of the PAYMENT-SIGNATURE you sent (your wallet address); Solana exact: your wallet address (the signer of the transaction besides the facilitator's fee payer)"
    • addedOutput schema / properties / safe_to_sign_new
      Added value: +{
+  "type": "boolean"
+}
    • changedOutput schema / required
      Previous value: -[
-  "network",
-  "state",
-  "retry",
-  "advice",
-  "checked_at",
-  "source"
-]New value: +[
+  "network",
+  "state",
+  "retry",
+  "safe_to_sign_new",
+  "advice",
+  "checked_at",
+  "source"
+]
  3. Changed5 schema fields changed
    • changedInput schema / properties / from / description
      Previous value: -"EVM exact payments: authorization.from of the payment you signed (your wallet)"New value: +"EVM exact payments without a tx: payload.authorization.from of the PAYMENT-SIGNATURE you sent (your wallet address)"
    • changedInput schema / properties / network / description
      Previous value: -"eip155:8453 (Base) or solana"New value: +"Base: eip155:8453 or base; Solana: solana or solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp"
    • changedInput schema / properties / nonce / description
      Previous value: -"EVM exact payments: authorization.nonce (0x + 64 hex) of the payment you signed"New value: +"EVM exact payments without a tx: payload.authorization.nonce of the PAYMENT-SIGNATURE you sent (0x + 64 hex); never send the signature itself"
    • changedInput schema / properties / tx / description
      Previous value: -"settlement transaction (the transaction field of PAYMENT-RESPONSE), if you have it"New value: +"settlement transaction hash from the transaction field of the PAYMENT-RESPONSE header (0x + 64 hex on Base, base58 signature on Solana), if you got one"
    • changedInput schema / properties / valid_before / description
      Previous value: -"EVM exact payments: authorization.validBefore (unix seconds)"New value: +"payload.authorization.validBefore (unix seconds): lets alalanet tell an expired, unused authorization (safe to pay anew) from one that may still settle"
  4. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses that nothing is signed or logged, that the signature itself is not needed, the full state and retry vocabularies, and the meaning of safe_to_sign_new. The chain_unavailable error and its 15 s retry window are behavior an agent could not infer from annotations.

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 with the core question and the when-to-use clause, and every sentence carries information. It is a dense single paragraph, though; the three identification paths would read faster as a short list.

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 7-parameter, multi-network settlement checker with an output schema, the description covers invocation paths, safety semantics, error handling, and retry timing. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds the crucial routing logic: which parameter combination identifies a payment for EVM exact (from + nonce + valid_before) versus Solana exact (from + blockhash) versus a known tx. It also explains why valid_before matters (distinguishing expired-unused from still-settleable).

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?

States a specific question and resource: whether an x402 payment settled, plus the derived safe_to_sign_new answer. It is clearly distinguishable from siblings like preflight_payment (pre-payment) and invoice_status (billing records).

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?

Explicitly names the triggering conditions (after a timeout, a 5xx, or any unclear answer to a paid request) and the decision point (before a new payment is signed). It also states the error case chain_unavailable and that the same question may be retried after 15 s.

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

All alalanet — check before you pay toolsInspect
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.

Resources