Skip to main content
Glama

endpoint_spot_check

Decision-shaped 402xAgent check of a public URL (private, loopback and link-local addresses blocked on every redirect hop) for an x402 PAYMENT-REQUIRED / 402 challenge. Every answer has reason_code (stable code) and confidence (high|medium|low); rules: https://402xagent.com/rules.json. History: stable_for_days, last_changed, drift, days_observed, first_seen, last_checked. Free: verdict (pay|skip|recheck), a plain-words reason, payment_terms_sha256 (hash of the approved payment), and access. Paid: verdict, reason code, quoted/claimed price, pay_to, network, asset, and payment = the exact {network, asset, amount_atomic, amount_usd, pay_to} a router may sign (verdict pay only), plus access with the settlement tx. No 402 terms is skip/no_paywall (recheck/free_trial_active when the target sends x-free-trial headers); recheck only for timeouts, 5xx, network errors and (0.55.0) HTTP 429 (rate_limited), a 403 with a firewall/WAF challenge signature (waf_challenge) or a host that still does not resolve after one retry (dns_error); after 24 h (TRANSIENT_SKIP_AFTER_HOURS) of only those rechecks the endpoint falls back to skip (*_persistent); (0.56.0) recheck/timeout when the whole probe (redirects + body) exceeds PROBE_TIMEOUT_MS (default 8000 ms), and recheck/host_unstable while the per-host circuit breaker is open (3 failed probes of the host in 10 min -> 15 min pause; target not fetched, no free check used, never charged); (0.57.0) before a live pay (after the free check or payment is accepted) a second quick probe of the same target must read the same 402 terms (scheme, network, asset, payTo; amount within 1%): different terms are recheck/terms_unstable, a failed confirm probe is its own recheck (server_error, timeout, unreachable); same price and free check; a plain 403 stays skip/no_paywall; wrong or unsupported network, non-canonical USDC or a pay_to that differs from the listing is skip. The same normalized URL + method reuses one probe for 5 min, so consecutive calls agree. mode=dry-run: free dry run (nothing signed or paid, stored as a public receipt, no approval hash, 50/caller/day). Never pays the target (probe GET only). 5 free checks per client per UTC day (at most 25 per network) (client=vc-mcp), then $0.02 USDC a check on Base via x402. Unpaid after free quota: payment instructions. Forward PAYMENT-SIGNATURE for a paid check.

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": {
      "url": "<url>"
    },
    "name": "endpoint_spot_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
refNooptional attribution tag stored on the receipt (dry-run-<caller> sets mode=dry-run)
urlYespublic http(s) URL to probe
modeNooptional: dry-run = free dry run: one unpaid probe, nothing signed or paid, always stored as a public receipt (check_type dry-run). Returns the free-tier shape with payment_terms_sha256 null (never an approval). 50 per caller (ref, else client, else IP) per UTC day. ref=dry-run-<caller> also sets it
taskNooptional task label (ignored in decision output)
quoteNooptional (0.54.0): the receipt id you were quoted (a discover/crawl id, 10 hex, or a live sc- id). If the live terms (price, pay_to, network, asset) differ from it, the answer is recheck/terms_changed_since_quote instead of pay
methodNooptional: probe the target with POST (empty JSON body) for POST-only endpoints
pay_toNooptional: the wallet you expect to pay (from your listing)
networkNooptional: the CAIP-2 network you expect, e.g. eip155:8453
claimed_priceNooptional claimed USD price to compare vs quoted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / quote
      Added value: +{
      +  "description": "optional (0.54.0): the receipt id you were quoted (a discover/crawl id, 10 hex, or a live sc- id). If the live terms (price, pay_to, network, asset) differ from it, the answer is recheck/terms_changed_since_quote instead of pay",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "optional: dry-run = free dry run: one unpaid probe, nothing signed or paid, always stored as a public receipt (check_type dry-run). Returns the free-tier shape with payment_terms_sha256 null (never an approval). 50 per caller (ref, else client, else IP) per UTC day. ref=dry-run-<caller> also sets it",
      +  "enum": [
      +    "live",
      +    "dry-run"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / ref
      Added value: +{
      +  "description": "optional attribution tag stored on the receipt (dry-run-<caller> sets mode=dry-run)",
      +  "type": "string"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / method
      Added value: +{
      +  "description": "optional: probe the target with POST (empty JSON body) for POST-only endpoints",
      +  "enum": [
      +    "GET",
      +    "POST"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / network
      Added value: +{
      +  "description": "optional: the CAIP-2 network you expect, e.g. eip155:8453",
      +  "type": "string"
      +}
    • addedInput schema / properties / pay_to
      Added value: +{
      +  "description": "optional: the wallet you expect to pay (from your listing)",
      +  "type": "string"
      +}
  4. Changed2 schema fields changed
    • changedInput schema / properties / claimed_price / description
      Previous value: -"optional claimed USD price to compare"New value: +"optional claimed USD price to compare vs quoted"
    • changedInput schema / properties / task / description
      Previous value: -"optional task label"New value: +"optional task label (ignored in decision output)"
  5. Added

TDQS

A3.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses address blocking on every redirect hop, never paying the target, probe GET only, 5-minute URL+method caching, timeouts, circuit-breaker behavior, rate limits, quotas, pricing, and free/paid return shapes.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is a dense run-on paragraph with nested parentheses, version numbers, and long reason-code lists. It is behaviorally rich but poorly structured and harder to scan than 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?

There is no output schema, so the description must explain returns, and it does: it enumerates free and paid response fields, verdict/reason/confidence, history fields, and the exact payment object. Given the tool's complexity, it is complete enough to call correctly.

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 meaningful context for several parameters: mode=dry-run behavior and quota, quote-triggered terms_changed_since_quote, method=POST for POST-only endpoints, expected pay_to/network, and ref=dry-run-<caller>.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

It states a specific verb and resource: a decision-shaped check of a public URL for an x402 PAYMENT-REQUIRED / 402 challenge, returning a verdict. The purpose is clear, but the description never explicitly distinguishes this from sibling tools such as endpoint_report or x402_hygiene.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains free vs paid checks, dry-run mode, and forwarding PAYMENT-SIGNATURE for a paid check, so usage context is inferable. It does not explicitly state when to choose this tool over alternatives or when not to use it.

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.