Skip to main content
Glama
Sign In

SpendPreflight

by io.github.spendpreflight
OverviewDiscussionsAdmin

x402 Seller Index

seller_index
Read-only

Use when you need sellers from the existing cached public catalog. Search cached public x402 sellers. First three matches free; up to12 cost0.01 USDC only with extra matches. Bounded unpaid availability, 402, quote history and public Lint evidence; missing evidence unknown. Partial Base USDC wash-activity heuristic: low/elevated/unknown, coverage and reasons. Elevated subtracts10 ordering points without excluding sellers. No target request, safety or paid-delivery guarantee. Price: 0.01 USDC. Minimal input example: {"capability":"weather forecast","limit":3}. Illustrative output excerpt: {"results":[],"free_top":3,"paid_available":false,"not_charged":true}. Illustrative output excerpt, not a live result, signature, approval or guarantee. Freshness/data/availability checks still apply. How to pay (MCP): Top three cached matches are free; extended results cost the quoted fee only when extra matches exist. No shared trial. Use an x402-capable MCP client. A generic MCP connector without payment support cannot complete a paid continuation. On payment required, STOP. Inspect the exact accepts amount, asset, network and payTo; obtain explicit wallet/budget approval before continuing. Only after approval, let the configured x402 MCP client attach its signed payload in _meta["x402/payment"] and retry the same tools/call arguments. Never send a separate USDC transfer or paste keys into tool arguments. Never silently fall back from free access to payment. If a signed attempt has an unknown outcome, inspect that authorization/transaction; do not create another automatically.

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": {
      "capability": "<capability>"
    },
    "name": "seller_index"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoOptional. Result count integer, 1–12. Example: 3. Defaults to 3 free results; extended results retain the existing price only when extra matches exist.
networkNoOptional. Payment network identifier string; use the quoted CAIP-2 identifier. Example: eip155:8453.
capabilityYesRequired. Capability search text string, 1–256 characters and at most 16 words. Example: weather forecast.
max_price_usdNoOptional. Maximum quoted price as a nonnegative USD number, at most 1000000. Example: 0.05. Omit for no price filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / capability / description
      Added value: +"Required. Capability search text string, 1–256 characters and at most 16 words. Example: weather forecast."
    • addedInput schema / properties / limit / description
      Added value: +"Optional. Result count integer, 1–12. Example: 3. Defaults to 3 free results; extended results retain the existing price only when extra matches exist."
    • addedInput schema / properties / max_price_usd / description
      Added value: +"Optional. Maximum quoted price as a nonnegative USD number, at most 1000000. Example: 0.05. Omit for no price filter."
    • addedInput schema / properties / network / description
      Added value: +"Optional. Payment network identifier string; use the quoted CAIP-2 identifier. Example: eip155:8453."
  2. Added

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations, it discloses the free tier (top three matches), the paid continuation and its 0.01 USDC price, bounded unpaid availability plus 402 behavior, and the scoring heuristic (elevated wash-activity subtracts 10 ordering points without excluding sellers). The payment protocol rules — STOP on 402, verify amount/asset/network/payTo, obtain wallet approval, attach signed payload in _meta, never send a separate transfer — are exactly the behavioral context annotations cannot convey. Nothing here contradicts readOnlyHint=true; charging for a read does not make it a mutation.

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?

It is a single dense block of roughly 300 words with duplicated disclaimers ("Illustrative output excerpt" appears twice, followed by yet another "not a live result" caveat) and repeated payment warnings. The core purpose and price are front-loaded, but a large fraction of the text is defensive boilerplate that could be cut in half without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid, cached-search tool with no output schema, it supplies the needed pieces: cost structure, free-vs-paid threshold, an illustrative output shape, the scoring heuristic, and the full payment-retry protocol. What is missing is minor — no guidance on latency or catalog staleness beyond "freshness/data/availability checks still apply."

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?

Schema description coverage is 100%, so capability, limit, network and max_price_usd are already well documented, and the 3/12 free/paid boundary is stated in both places. The description adds only a minimal example argument object ({"capability":"weather forecast","limit":3}), which is marginal value over the schema's own example block. Baseline 3 is appropriate.

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?

The second sentence states a specific verb and resource: "Search cached public x402 sellers." That distinguishes it from sibling check_* tools, which validate individual endpoints/listings/payees rather than search a catalog. The purpose is clear but is buried mid-paragraph after a usage clause and pricing caveats, requiring more parsing than it should.

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?

It opens with an explicit trigger ("Use when you need sellers from the existing cached public catalog") and adds a real exclusion: a generic MCP connector without payment support cannot complete a paid continuation. It stops short of naming any sibling tool as the alternative for validation-style needs, so the routing guidance is context-rich but not complete.

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

All SpendPreflight 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