Agenttoll

AgentToll

agenttoll.app provides 21 paid data endpoints for agents, priced from $0.001 to $0.008 in USDC. The hosted service settles on Base mainnet. Onchain identity: agenttoll.base.eth. Source · MCP package.

Fresh-pool discovery, token safety checks, sampled radar history, wallet activity and market data share one API. Base market and chain data always use mainnet; a self-hosted instance can accept payments on Base Sepolia without changing the data network.

Inspect a token in the browser

The browser flow at /inspect.html includes a free, dated report captured from real provider data. Paste a Base token contract address, check the price without connecting a wallet, then approve one USDC payment to receive the eight-check report. It uses the existing /api/base/safety/:address endpoint ($0.003), preserves missing evidence, and offers a settlement receipt and JSON download. A report can be cached for up to five minutes. Ambiguous signed failures require checking the wallet before another payment can be requested.

web/inspect.html is the page template; web/inspect.ts controls quotes and payment, and web/token-report.ts presents the data. npm run build:web builds both browser bundles and embeds public/token-example.json into the generated page, so the example works without JavaScript. npm run check:generated checks that all three generated files agree with their sources. Refresh the example only with a newly recorded response and its capture time and provenance; do not relabel an old example as live.

Operational inspection metrics come from exported application logs; see ops:inspections in OPERATIONS.md. These distinguish mainnet settlements from testnet activity and known operator wallets, and do not claim that a wallet is a person or that a quote is a unique visitor.

Saved research, comparisons and wallet holdings

/research.html keeps a browser-local watchlist and dated report history. Save a token address or the recorded example; completed inspections can also be saved from the inspector. Storage is limited to 50 watched tokens and 100 sanitized reports, with ten per token. No keys, signatures, payment receipts or paying wallet addresses enter that storage. It is specific to this browser; removing site data removes the history. Storage failures are shown and preserve previously stored data.

The history view compares observations of the same token and provenance type, preserving missing evidence and warning when dates are unavailable or the same observation has conflicting contents. Repeated cached results are not presented as fresh checks. Examples and shared snapshots remain distinct from inspections.

Compare two to five token addresses using saved observations, or review a summed quote for new inspections. Each token uses the existing safety endpoint and its own wallet authorization. Batches run sequentially, keep completed responses and receipts, and stop after a failure. Remaining requests need a fresh explicit quote; an uncertain payment must be acknowledged after checking the wallet before another payment can start. Displayed quotes expire after 60 seconds, including remaining steps of a long batch.

The wallet panel separately prices /api/base/portfolio/:address?minValue=0&limit=50, displays observed holdings and source coverage, and lets the visitor select up to five discovered ERC20 tokens for separately priced inspections. Native ETH, missing/unpriced holdings and coverage gaps are not silently treated as inspected. Wallet addresses and the portfolio response remain in page memory.

Report actions copy a bounded URL-fragment snapshot or download a 1200×1200 PNG card. /shared-report.html labels every imported snapshot as user-supplied and unverified, preserves observation dates and never pays or saves automatically. Fragment contents can be read or changed by anyone with the link; they are not an authenticated AgentToll record. Payment and wallet metadata are excluded. There is no background monitoring or messaging service.

web/research*.ts, web/portfolio-model.ts and web/report-share.ts implement these tools. The build shares CSS source files while inlining their contents into generated HTML to match the existing deployed Content Security Policy. npm run build:web regenerates every browser entry; npm run check:generated verifies the results.

Payment flow

1. An unsigned request returns HTTP 402 with a base64 JSON quote in PAYMENT-REQUIRED. JSON responses also include the same complete quote in the body for clients and discovery crawlers that read accepts there.
2. The client validates the endpoint ceiling, expected origin, network, USDC contract and recipient, then signs an EIP-3009 authorization within its budget.
3. The retry carries PAYMENT-SIGNATURE. The facilitator verifies payment and settles after a successful handler response. PAYMENT-RESPONSE carries the settlement receipt.

API consumers do not need an account or API key. Paying clients need a wallet key; operators may need facilitator/upstream credentials. An initial quote and its signed retry are separate HTTP requests.

Handler failures before settlement are not billed. A lost response or timeout after signing/settlement may have an unknown outcome: inspect the receipt and wallet before retrying. The bounded client keeps ambiguous signed amounts reserved.

Endpoints

Optional query parameters do not change registered prices. Invalid inputs return 400. fundedOnly accepts the literal values true or false. The catalog and OpenAPI describe parameter limits. Selected upstream results are cached and concurrent loads are coalesced; TTLs vary, and history caches last longer than live-market caches.

API GET/HEAD requests use URL parameters and payment headers, and reject request bodies with 400 and a closed connection. Encoded path parameters, case variants and one trailing slash are supported; encoded route prefixes and duplicate or encoded path separators are rejected before payment verification.

Interpreting the data

Safety responses preserve unknown checks and provider coverage. A missing owner flag or tax is not a pass. clear requires the necessary evidence; a detected failure can still produce high-risk when other checks are unknown. Passing automated checks does not guarantee safety. Portfolio and radar responses also need their partial/coverage fields to be interpreted correctly.

Free supplemental safety sources provide address-risk screening, verified interface context and observed pool liquidity. Interface names and market value do not complete missing permission or liquidity-ownership checks. See safety evidence and limits.

Portfolio indexer scans stop after three pages or when the indexed tail falls below the $1 source read floor. Lowering minValue changes the display filter, not this source scan bound. Any unread provider pages mark the response partial; totals and unpriced counts describe observed holdings only, and the number of unseen tokens remains unknown. Sentiment responses preserve the provider's observation timestamp separately from their fetch time, including when served from cache.

Address-to-Basename results are forward-resolved back to the original address. Fresh pools cover Uniswap v4; token attribution can be null, ages are estimates from block height, and funded records observed liquidity events rather than a USD liquidity valuation.

Wallet and radar watches

For /api/watch/address/:address, keep the opaque cursor unchanged and pass it as since. Continue while hasMore is true before scheduled polling resumes. Each call reads one provider page; partial and coverage.complete report whether that scan has drained. An initial ISO timestamp is accepted.

The polling overlap is 120 seconds, with at most 100 remembered transaction hashes. Deduplicate by hash in the consuming agent, especially when coverage.replayPossible is true. These bounds do not cover all delayed indexing, older reorganizations or indexer gaps.

The radar watch uses an ISO cursor over a ranked, liquidity-filtered listing. Its coverage is always partial: an omitted or late-indexed pool can be missed. The price-alert watch reports a threshold result and has no cursor.

Published history and scorecards

The snapshot workflow writes selected scout observations to data/scout/ and publishes them in git. History reads pin the index and snapshot bytes to one immutable revision, exposed through provenance.revision and commit/raw links. The payment transaction is a settlement record; it does not authenticate snapshot contents or prove capture time.

For scorecards, days selects the latest N published snapshot days, not a strict calendar lookback. Tokens use their first sighting in that selected window, so holding periods vary. C