Skip to main content
Glama
Sign In

tech-risk

by io.github.rezearcher
OverviewDiscussionsAdmin

x402_preflight

Should an agent pay this x402 endpoint? Pre-payment check of an UNKNOWN x402 URL: fetch it once (never pays) to validate the 402 challenge + accepts[] (scheme/network/payTo/amount/asset/resource = will it settle) AND label its LIVENESS (LIVE | ZOMBIE | DEAD — is it a working payable endpoint right now, or listed-active-but-broken) AND flag an absolute PRICE TRAP (a honeypot charging >= $1,000/call trips AVOID even when its advertised==live price looks self-consistent; pass max= for your own budget ceiling) AND scan the resource + any advertised MCP tools for LLM01/LLM08 prompt-injection and screen payTo against the OFAC SDN + community scam lists (safe to pay) AND verify the PRICE — does the live accepts[].amount match the advertised price? pass advertised= (the figure your catalog quoted) or it self-checks the endpoint's /.well-known/x402: MATCH | OVERCHARGE | UNDERCHARGE. Optional samples=N (1-5) runs a reliability/payability burst (settle-consistency + latency; a flapping endpoint downgrades PAY to CAUTION). Returns verdict PAY | CAUTION | AVOID + per-check fix hints + latency. Read-only, never a settlement guarantee. Cost: $0.005 USDC per call via x402 on MCP tools/call (direct HTTP route: $0.001).

Input Schema

NameRequiredDescriptionDefault
maxNooptional: your per-call budget ceiling in USDC dollars (e.g. 0.05) — the result flags price_trap.exceeds_caller_max if the live charge is over it; an absolute >=$1000/call trap trips AVOID regardless
urlYesthe x402 endpoint URL to pre-check before paying
samplesNooptional reliability burst: sample the 402 challenge N times (1-5) for settle-consistency + latency; default 1
advertisedNooptional: the price (USDC dollars, e.g. 0.001) your catalog/listing quoted — returns MATCH/OVERCHARGE/UNDERCHARGE vs the live accepts[].amount; omit to self-check against the endpoint's own /.well-known/x402

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / max
      Added value: +{
+  "description": "optional: your per-call budget ceiling in USDC dollars (e.g. 0.05) — the result flags price_trap.exceeds_caller_max if the live charge is over it; an absolute >=$1000/call trap trips AVOID regardless",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / advertised
      Added value: +{
+  "description": "optional: the price (USDC dollars, e.g. 0.001) your catalog/listing quoted — returns MATCH/OVERCHARGE/UNDERCHARGE vs the live accepts[].amount; omit to self-check against the endpoint's own /.well-known/x402",
+  "type": "string"
+}
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it declares the tool is read-only, that it fetches once and 'never pays', that it is not a settlement guarantee, and that it costs $0.005 USDC per call via x402 ($0.001 direct HTTP). It also discloses side-effect-relevant behavior such as the flapping endpoint downgrading PAY to CAUTION and the absolute >=$1,000 trap tripping AVOID regardless of self-consistency.

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 lead question is well front-loaded, but the body is one very long run-on sentence chained with 'AND ... AND ... AND', making the seven distinct checks hard to parse on a first read. Dense all-caps emphasis (LIVENESS, PRICE TRAP, MATCH | OVERCHARGE | UNDERCHARGE) aids scanning somewhat but the structure is not cleanly segmented.

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 complex, multi-check tool with no output schema and four parameters, the description covers the verdict vocabulary (PAY | CAUTION | AVOID), per-check fix hints, latency in the return, pricing of the call itself, and the read-only caveat. An agent has everything needed to decide whether to invoke it and how to interpret the 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; the description goes beyond it by explaining consequences: max produces price_trap.exceeds_caller_max, samples runs a settle-consistency/latency burst that can downgrade the verdict, and omitting advertised triggers a self-check against /.well-known/x402. It adds outcome semantics rather than just restating the parameter types.

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 verb and resource: a pre-payment validation of an unknown x402 URL, enumerating exactly what is checked (402 challenge/accepts[], liveness, price trap, prompt injection, OFAC/scam screening, advertised-vs-live price). The 'pre-payment' framing cleanly separates it from the sibling x402_receipt_verify, which is post-payment, without needing to name it.

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 opening question 'Should an agent pay this x402 endpoint?' plus 'pre-payment check of an UNKNOWN x402 URL' establishes the use case, and it tells the caller when to supply max, advertised, and samples. It stops short of explicit when-not-to-use guidance or naming alternatives such as x402_receipt_verify for already-paid receipts.

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

All tech-risk 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