Skip to main content
Glama

Scored, signed verdict on any x402 seller: challenge shape, Bazaar usage, trust surfaces.

vet_seller
Read-onlyIdempotent

Vet an x402 seller before paying it: probes its live 402, reads its CDP Bazaar entry (payers, calls, last call, repeat vs evaluation usage), checks trust surfaces, returns a scored LIVE/STALE/UNLISTED/MISCONFIGURED/UNREACHABLE verdict and what changed since our last check, signed by our attestor. MUST be invoked before a first payment to an unknown resource, or on a schedule to watch it. Do NOT use to pay it. Settles $0.010 USDC; no charge on failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodNoHTTP method the resource expects; POST resources are probed with an empty JSON body.
resourceYesAbsolute https URL of the x402 resource to vet (the paid route itself, not the seller homepage).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tsNoResponse timestamp, UNIX milliseconds
scoreNo40 challenge shape + 40 Bazaar usage + 20 trust surfaces
trustNoWhich of /.well-known/x402, /llms.txt, /.well-known/security.txt, /transparency the origin publishes
bazaarNoCDP Bazaar index entry for the resource: indexed, lastCalledAt, uniquePayers30d, totalCalls30d, callsPerPayer
methodNo
changesNoFields that differ from the previous verdict (verdict, score, usagePattern, findingCodes, priceUsdc, payTo, indexed, uniquePayers30d, totalCalls30d, lastCalledAt); empty when unchanged or first check
settledNotrue when an x402 payment settled for this response
verdictNoLIVE = payable, indexed, recently called. STALE = indexed but not called within VET_STALE_DAYS. UNLISTED = payable but never counted by the Bazaar. MISCONFIGURED = an x402 buyer cannot pay it as served. UNREACHABLE = no answer.
findingsNoEvery deduction, machine-coded and human-readable
previousNoSummary of the last verdict this gateway issued for the same resource (checkedAt, verdict, score, usagePattern); null on first check. Call on a schedule and this is your watch.
resourceNoNormalized resource URL that was vetted
challengeNoWhat the target 402 actually said: status, x402Version, accepts[0], description length, WWW-Authenticate presence, networks offered
checkedAtNoISO-8601 time of the probe
attestationNoEIP-712 signature over resource, checkedAt, verdict, score, usagePattern and changes by the published attestor, verifiable offline; null when the attestor is unconfigured
usagePatternNorepeat = calls/payer at or above the repeat threshold; evaluation = buyers try once and leave

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / attestation / description
      Previous value: -"EIP-712 signature over this verdict by the published attestor, verifiable offline; null when the attestor is unconfigured"New value: +"EIP-712 signature over resource, checkedAt, verdict, score, usagePattern and changes by the published attestor, verifiable offline; null when the attestor is unconfigured"
    • addedOutput schema / properties / changes
      Added value: +{
      +  "description": "Fields that differ from the previous verdict (verdict, score, usagePattern, findingCodes, priceUsdc, payTo, indexed, uniquePayers30d, totalCalls30d, lastCalledAt); empty when unchanged or first check"
      +}
    • addedOutput schema / properties / previous
      Added value: +{
      +  "description": "Summary of the last verdict this gateway issued for the same resource (checkedAt, verdict, score, usagePattern); null on first check. Call on a schedule and this is your watch."
      +}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive hints, it discloses the live 402 probe, CDP Bazaar reads, change-tracking since the last check, and the $0.010 USDC settlement with no charge on failure. The fee is a critical side effect that would otherwise be invisible.

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?

Three dense sentences with no filler: action, scope, scheduling rule, exclusion, and pricing all earn their place. The most important usage constraint is front-loaded.

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, scheduled, stateful vetting tool, the description supplies the missing operational context: when to call, what it probes, what it returns, and what it costs. A rich output schema covers the return details, so nothing essential appears absent.

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

Parameters3/5

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

The input schema already documents both parameters at 100% coverage, including the important distinction that `resource` is the paid route, not the seller homepage. The description adds no per-parameter detail beyond what the schema provides, so the baseline of 3 applies.

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?

Names a specific verb ('vet'), target ('x402 seller'), and exact deliverable ('scored LIVE/STALE/UNLISTED/MISCONFIGURED/UNREACHABLE verdict signed by our attestor'). The probe/Bazaar/trust-surface details make it easy to tell apart from generic market or census siblings.

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 states when it is mandatory ('MUST be invoked before a first payment to an unknown resource, or on a schedule') and gives a hard negative ('Do NOT use to pay it'). This gives an agent a clear decision rule.

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.

Resources