Skip to main content
Glama

Check an x402 endpoint before paying it

x402_verify
Read-onlyIdempotent

Call this BEFORE authorising payment to any x402 endpoint you did not write yourself. It fetches the endpoint's live payment challenge and compares it against every observation previously made by every other caller, so you learn things a single agent cannot see on its own -- above all, whether the address receiving the money has changed. A 'critical' entry in drift means something determining where funds go (pay_to, network or asset) is different from before: stop and confirm out of band. Read the LIVE charges in preference to any directory listing, and pass what the listing claimed as expect to have the disagreement reported. IMPORTANT: 'status':'ok' is NOT an endorsement -- it only means a challenge was read and recorded. It cannot tell you whether the operator will deliver anything for your money. 'first_observation':true means there is no history at all, so an empty drift proves nothing. ALWAYS read prior_criticals: drift only compares against the last observation, so an endpoint that swapped its payee earlier shows an empty drift once that swap became the baseline -- a non-zero prior_criticals means it has changed where money goes before, and that is true no matter how clean today's look is. 'status':'unreachable' is not evidence of fraud and not evidence of health; do not pay on it either way. A null price_usd means the token's units are unknown here and the amount was NOT converted -- do not assume it is small. Costs $0.010 in USDC on Base, paid via the x402 protocol, or from a credit token — call credits_trial for free credit if you have neither.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPublic HTTPS URL of the endpoint you are about to pay. Loopback and private-network addresses are refused rather than fetched.
expectNoOptional. What a directory, README or earlier response led you to believe. Any disagreement with the live challenge is reported.
methodNoHow to provoke the challenge: 'POST' (default), 'GET' or 'HEAD'. Use the method you intend to pay for.
credit_tokenNoOptional. A credit token from credits_trial or /credits/buy. Supplying it pays for this call from that balance, so no x402 payment or wallet is needed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe URL that was checked
driftNoDifferences from the last observation. Any severity 'critical' entry changes where money goes. Null means no comparison was made at all, which is not the same as an empty array.
adviceNoPlain-language statement of what was and was not established
statusYes'ok' means a challenge was read -- NOT that the endpoint is trustworthy. 'refused' means the URL was never fetched. 'unreachable', 'redirected' and 'not_x402' all mean no challenge was obtained.
chargesNoWhat the endpoint declares it will charge, right now
last_seenNoISO-8601 time of the previous observation
reachableNoWhether the endpoint answered at all
first_seenNoISO-8601 time this endpoint was first observed
mismatchesNoHow the live challenge disagrees with what you expected
times_seenNoHow many observations exist, across all callers
http_statusNoStatus code the endpoint returned
last_criticalNoThe most recent previously recorded critical change, or null if there has never been one.
prior_criticalsNoHow many critical changes have EVER been recorded for this endpoint, not counting this call. `drift` only compares against the last observation, so once a change has been absorbed into the baseline it stops appearing there. A non-zero value here means this endpoint has changed where money goes before, even when `drift` is empty.
first_observationNoTrue when there was no prior record, so an empty `drift` means nothing
matches_expectationNoPresent only when `expect` was supplied

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / credit_token
      Added value: +{
      +  "description": "Optional. A credit token from credits_trial or /credits/buy. Supplying it pays for this call from that balance, so no x402 payment or wallet is needed.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedOutput schema / properties / last_critical
      Added value: +{
      +  "description": "The most recent previously recorded critical change, or null if there has never been one.",
      +  "properties": {
      +    "at": {
      +      "description": "ISO-8601 time the change was recorded",
      +      "type": "string"
      +    },
      +    "field": {
      +      "description": "What changed: pay_to, network or asset",
      +      "type": "string"
      +    },
      +    "from": {
      +      "description": "The previous value",
      +      "type": "string"
      +    },
      +    "to": {
      +      "description": "The value that replaced it",
      +      "type": "string"
      +    }
      +  },
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / prior_criticals
      Added value: +{
      +  "description": "How many critical changes have EVER been recorded for this endpoint, not counting this call. `drift` only compares against the last observation, so once a change has been absorbed into the baseline it stops appearing there. A non-zero value here means this endpoint has changed where money goes before, even when `drift` is empty.",
      +  "type": "number"
      +}
  3. Changed3 schema fields changed
    • changedOutput schema / properties / drift / description
      Previous value: -"Differences from the last observation. Any severity 'critical' entry changes where money goes."New value: +"Differences from the last observation. Any severity 'critical' entry changes where money goes. Null means no comparison was made at all, which is not the same as an empty array."
    • changedOutput schema / properties / drift / items / properties / severity / description
      Previous value: -"'critical' or 'warning'"New value: +"'critical' when something determining where money goes is new, 'warning' when it is worth knowing, 'info' when it is merely a fact"
    • changedOutput schema / properties / drift / type
      Previous value: -"array"New value: +[
      +  "array",
      +  "null"
      +]
  4. Changed1 schema field changed
    • changedOutput schema / properties / charges / properties / price_usd / type
      Previous value: -[
      -  "number",
      -  "null"
      -]New value: +[
      +  "string",
      +  "null"
      +]
  5. Added

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavioral caveats that annotations alone cannot convey: 'status':'ok' is not an endorsement, a first observation makes empty drift meaningless, prior_criticals remains the truthful signal after a baseline swaps, unreachable is inconclusive, and null price_usd means no conversion occurred. These do not contradict readOnlyHint/idempotentHint; they enrich the safety profile.

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

Conciseness5/5

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

The description is long but every section earns its place: the when-to-use rule is front-loaded, followed by the core mechanism, then the caveats most likely to prevent a mistaken payment. It uses clear emphasis markers (IMPORTANT, ALWAYS) to prioritize the highest-risk messages.

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 paid verification tool with an output schema, the description covers the necessary interpretation of statuses and fields, failure semantics, pricing, and payment fallbacks. There is no missing operational context an agent would need to decide whether to call it or act on its result.

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 semantic guidance beyond field descriptions: expect should carry 'what the listing claimed', method should be the one you intend to pay with, and credit_token is explicitly an alternative balance that avoids an x402 payment. This lifts it above baseline without needing to repeat schema details.

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 opening sentence names a specific action ('Call this BEFORE authorising payment') tied to a clear resource (an x402 endpoint not written by the caller), and the second sentence defines the mechanism ('fetches ... live payment challenge and compares it against every observation previously made'). This is precise and naturally distinguishes it from unrelated siblings like meetings_* or vault_*.

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 exactly when to invoke ('BEFORE authorising payment to any x402 endpoint you did not write yourself'), tells the agent to prefer live charges over directory listings, and routes users without funding to credits_trial. It also tells the caller which HTTP method to use ('Use the method you intend to pay for') and what conditions should prevent payment ('stop and confirm out of band').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.