What can you do with this server?

This server lets you assess the trustworthiness and reliability of x402 payment endpoints before sending USDC to them. Free capabilities: * Ecosystem stats — Aggregate snapshot of the x402 ecosystem (listings, reachability, compliance, 30-day settlement volume). * Trust leaderboard — Top-25 most trustworthy endpoints ranked by uptime, compliance, latency, age, settlement activity, and price stability. * Trust preview — Full-grade sample trust reports for three endpoints (best, median, worst) so you understand the paid output format before committing. * Watch events — Poll the append-only event log of an active monitor watch. Paid capabilities (charged in USDC on Base via x402): * Trust score — Detailed score (0–100, A–F grade) for a specific endpoint, with a machine-readable verdict (proceed/caution/avoid), advertised price, confidence range, structured flags with severity levels, and full component breakdown. * Bulk scoring — Score up to 500 endpoints in a single call, receiving score, grade, recommendation, confidence, and probed_at for each. * Endpoint history — Raw observation time-series (listing/delisting events, price changes, payTo changes, probe results) over a 1–90 day window. * Monitoring — Set up a 30-day watch for alerts on critical changes (payTo, price, asset, network, spec regressions, liveness), and renew watches for an additional 30 days. Auto-pay: If a funded Base USDC wallet is configured, paid calls are settled automatically within configurable spending limits; otherwise price quotes are returned for manual payment.

Which integrations are available for this server?

Allows sending notifications to Discord via incoming webhooks when monitored x402 endpoints change. Allows sending notifications to Slack via incoming webhooks when monitored x402 endpoints change.

x402 Endpoint Trust

by JonasFuchss

Overview Schema Related Servers Score Discussions

TypeScript

Remote

x402-trust-mcp MCP server

x402-trust-mcp

An MCP server that lets your agent check the trust & reliability of x402 endpoints before paying them.

Backed by x402.fuchss.app, which monitors the entire x402 ecosystem on Base 24/7: uptime probes, 402-envelope spec compliance, advertised-price history, and real on-chain USDC settlement volume per endpoint.

Why

Agents increasingly pay x402 endpoints autonomously. But ~⅔ of listed x402 endpoints are unreachable and ~⅓ of the reachable ones serve non-compliant payment envelopes. Before your agent sends USDC to an unknown endpoint, ask: is it alive, compliant, and does anyone actually pay it?

Related MCP server: x402-mcp

Tools

Tool	Cost	Description
`x402_ecosystem_stats`	free	Aggregate state of the x402 ecosystem (listings, reachability, compliance, 30d settlement volume).
`x402_trust_leaderboard`	free	Top-25 most trustworthy x402 endpoints.
`x402_trust_preview`	free	Showcase of what `x402_trust_score` returns — you don't choose the endpoint. Returns the complete paid-grade report (exact score, full breakdown, advertised price, on-chain settlement figures, all flags) for three endpoints: the best-scored, the median, and the worst-scored. See the full data shape across the quality range before you pay. To score your own endpoint, use `x402_trust_score` (paid). Takes no arguments.
`x402_trust_score`	paid	Trust score (0-100, grade A-F) for a specific endpoint, plus the provider-advertised `serviceName` and `description` (unverified provider claims, shown next to our independent metrics), a machine-readable pay/don't-pay verdict, the advertised price, a confidence band, and structured flags — everything to decide in one call.
`x402_endpoint_history`	paid	Observation time-series for a specific endpoint (listings, price changes, probes).
`x402_find_alternatives`	paid	Find semantically-similar endpoints that OUT-SCORE a given one. Use this to route away from a mediocre/dead/expensive endpoint toward a more reliable, better-settled one serving the same function. Each alternative carries score, grade, similarity (0-1), price, and a free per-endpoint page.
`x402_semantic_search`	paid	Free-text semantic search across the whole monitored catalog. Describe the capability you need in plain words, get the up to 25 closest endpoints ranked deterministically: cosine similarity bucketed to whole percentage points first (80.3% and 80.5% tie), then trust score, then described-before-undescribed, then id; matches below a 0.5 similarity floor are dropped. Missing description: no fixed malus, only the tiebreak loss at equal bucket + score (fallback embedding via service name + URL path tokens usually lowers similarity). Each match has resource, score, grade, similarity, description, and a free per-endpoint page. Discovery only: no verdicts or flag details (that is `x402_trust_score`).
`x402_trust_bulk`	paid	Score up to 500 endpoints in a single paid call from cached full-density snapshots. Picks the cheapest tier that fits your list (10/50/100/200/500). Returns score, grade, recommendation, confidence, and `probed_at` per endpoint.
`x402_watch_create`	paid	Start monitoring one endpoint for 30 days. Alerts on payTo change (takeover signal), price/asset/network change, spec regression, delisting, and liveness. Supports up to 5 webhook + 5 Slack/Discord URLs per watch, all connection-tested before payment. Returns a one-time bearer secret + poll/edit/cancel URLs + `next_steps`.
`x402_watch_events`	free	Poll the append-only event log of an active watch using the watch id and one-time secret. Use the `since` (endpoint events) and `watch_since` (lifecycle events) cursors to page forward; nothing between polls is lost.
`x402_watch_edit`	free	Change a watch's webhook/Slack URLs, liveness sensitivity, or subscribed events. Bearer-authed with the secret from `x402_watch_create`.
`x402_watch_cancel`	free	Soft-cancel a watch: drops the endpoint back to normal probe cadence immediately, but the event log stays readable via `x402_watch_events` until the original `expires_at`.
`x402_watch_renew`	paid	Extend an active watch by another 30 days. The secret stays the same.

Paid tools cost from $0.001 (a semantic search) or $0.005 (a single trust / similar lookup) up to ~$0.50 (500-endpoint bulk batch) or ~$0.20 for a 30-day watch, charged over x402 (USDC on Base). If you set X402_PRIVATE_KEY, the server auto-pays within your X402_MAX_USD limit; otherwise it returns the price quote for your host to pay.

Bulk scoring (`x402_trust_bulk`)

The bulk tool is the scale axis: score up to 500 endpoints in one call from the same data that powers the leaderboard. It auto-selects the cheapest tier that fits your request:

Tier	Max endpoints	Approx. price
10	10	~$0.045
50	50	~$0.20
100	100	~$0.325
200	200	~$0.40
500	500	~$0.50

Cached rows older than ~15 minutes are recomputed on-demand from the latest stored probes and settlements (no live network re-probe), so bulk scores usually reflect reality within minutes. Per-request recompute limits apply: at most 50 rows / 8 seconds are recomputed; the response tells you via recompute_limit_hit + recompute_limit. Each result carries score, grade, recommendation, confidence, probed_at, computed_at, and recomputed so you can see exactly which rows were freshly computed vs served from cache. URLs not in the observation set return found: false; you still pay for the batch.

Finding better alternatives (`x402_find_alternatives`)

Before paying an unknown endpoint, check whether a better-tested alternative exists for the same purpose. x402_find_alternatives returns up to 25 endpoints (default 5) that are semantically similar to a given URL — matched on advertised purpose via description embeddings — and that out-score it on our deterministic trust score. Each alternative returns score, grade, recommendation, cosine similarity (0-1), amountUsd price, and a free endpointPage URL. Same-host siblings and avoid-flagged endpoints are excluded; an empty alternatives array is a valid answer meaning nothing beats the subject. Cost is ~$0.005 per call.

Semantic search (`x402_semantic_search`)

Describe the capability you need in plain words and get the up to 25 closest endpoints in the monitored catalog. Ranking is deterministic: cosine similarity bucketed to whole percentage points first (80.3% and 80.5% are the same bucket), then trust score, then described-before-undescribed, then endpoint id, with matches below a 0.5 cosine-similarity floor dropped entirely (so a query can return fewer than the requested limit, or none). Endpoints that advertise no description are still matched via their service name and URL path tokens (host name as a last resort). The exact effect of a missing description: no fixed point deduction and no direct similarity malus; the only deterministic penalty is the described-before-undescribed tiebreak (equal bucket AND equal score: described wins). Beyond that it is purely indirect — the shorter fallback text typically yields lower cosine similarity than a prose description, so such endpoints tend to land in lower buckets, by a query-dependent amount. Each match returns id, resource, score, grade, raw cosine similarity (0-1; ranking buckets it), description (when advertised), and a free endpointPage URL. This is discovery, not verdicts: score/grade are null for unscored endpoints, and no recommendation or flag detail is included (use x402_trust_score for that). Cost is ~$0.001 per call.

Watch / alerting (`x402_watch_create`, `x402_watch_events`, `x402_watch_edit`, `x402_watch_cancel`, `x402_watch_renew`)

Create (x402_watch_create, paid) buys 30 days of change monitoring for one endpoint. Pay over x402; receive a one-time bearer secret, a poll_url, a renew_url, and machine-readable next_steps.
Poll (x402_watch_events, free) reads the append-only event log. It returns two streams: events (endpoint changes — payTo / price / asset / network / spec / delisting / liveness) and watch_events (lifecycle feedback — created / edited / cancelled / renewed / expiring / expired), each with their own cursor (next_cursor and watch_events_cursor). Page forward by passing the previous response's cursors as since / watch_since. Cursors/ids are global sequences shared across watches, so a watch's first event id may be >1 — always use the returned next_cursor, never assume events start at 1.
Edit (x402_watch_edit, free) changes webhook/Slack URLs, liveness sensitivity, or subscribed events. Bearer-authed with the secret.
Cancel (x402_watch_cancel, free) soft-cancels a watch: no new events accrue and probing drops back to normal cadence immediately, but the event log stays readable via x402_watch_events until the original expires_at. Cancel is not a delete.
Renew (x402_watch_renew, paid) extends the watch before expires_at. The secret stays the same.

Optional push delivery to one or more signed HTTPS webhooks and/or Slack/Discord incoming webhooks can be configured at creation time and updated via edit (up to 5 of each per watch). webhook_url and slack_url accept a single URL string or an array of URLs. Any URL is connection-tested before you are charged: the server POSTs a signed connection_test ping and, if it can't be delivered (3 attempts), rejects the change with notCharged: true so you can retry with a corrected URL. On success the response reports per-URL delivery under delivery.connection_test.

If you use a webhook, verify the x-signature header equals sha256= + HMAC-SHA256(body) keyed by the SHA-256 hex digest of your secret — i.e. the HMAC key is hex(sha256(secret)), not the raw secret. (The delivery worker only ever holds that hash, never the plaintext secret.)

`x402_trust_score` result

A single call returns everything an agent needs to decide whether and at what price to use an endpoint — no second round-trip, no raw-unit guessing:

Field	Meaning
`score` / `grade`	0-100 point score and its A-F grade.
`recommendation`	Machine verdict: `proceed` \| `caution` \| `avoid`. Already prices in data uncertainty — low confidence caps it at `caution` (a young endpoint is unproven, not untrustworthy); `avoid` is reserved for real negatives (error-severity flags, low score, recent payTo change).
`scoreRange`	`{ low, point, high }` — a confidence-adjusted band. Decide conservatively against `low`.
`confidence` / `confidenceDetail`	Overall confidence plus its parts: `observation` (data volume/age) vs `economic` (settlement coverage).
`gradeThresholds`	The score cutoffs for each grade, so the verdict is auditable.
`advertised`	The last observed 402 quote: `{ amount, amountUsd, asset, network, decimals, observedAtTs }`. Trust and cost in one call.
`serviceName` / `description`	The provider-advertised name and description (unverified claim from the 402 envelope). Shown next to our independent metrics so you can sanity-check what the provider says against what we've measured.
`flags` / `flagsDetailed`	Legacy string flags plus structured `{ code, severity, message }`. Rule of thumb: any flag with `severity: "error"` ⇒ avoid.
`breakdown` / `subscores`	The full deterministic math (uptime, compliance, latency, age, activity, stability → technical / spec / economic subscores).
`stats`	Observed evidence: probe counts, latency, payTo, `settledVolumeUsd30d`, distinct payers, and a `payToChanged*` hijack signal when the receiving wallet changed recently.

Everything is computed deterministically (no LLM) from continuous on-chain and probe observation, so the breakdown is fully auditable.

x402 V2 Payment Flow

This MCP server uses the canonical x402 V2 payment flow:

402 + PAYMENT-REQUIRED — The server responds with HTTP 402 and a base64-encoded PAYMENT-REQUIRED header containing the payment requirements (accepts, network, asset, amount, payTo).
Sign + retry with PAYMENT-SIGNATURE — The MCP client signs an EIP-3009 transferWithAuthorization for the selected accept and re-POSTs with the PAYMENT-SIGNATURE header (base64-encoded payment payload).
Settlement + PAYMENT-RESPONSE — The server settles the payment and responds with the data plus a PAYMENT-RESPONSE header.

Legacy X-PAYMENT / X-PAYMENT-RESPONSE headers are accepted as a fallback during the V1→V2 transition period but are not the default.

Accept selection: When a 402 response offers multiple accepts (e.g. Solana

Base USDC), the client selects the best compatible one (canonical USDC on an allow-listed chain) rather than blindly taking the first accept.

Install

Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):

{
  "mcpServers": {
    "x402-trust": {
      "command": "npx",
      "args": ["-y", "x402-trust-mcp"]
    }
  }
}

To enable autonomous payment for the paid tools, add a funded Base USDC wallet:

{
  "mcpServers": {
    "x402-trust": {
      "command": "npx",
      "args": ["-y", "x402-trust-mcp"],
      "env": {
        "X402_PRIVATE_KEY": "0xYOUR_BASE_WALLET_KEY",
        "X402_MAX_USD": "0.05"
      }
    }
  }
}

Configuration (env vars)

Var	Default	Description
`X402_TRUST_API_BASE`	`https://x402.fuchss.app`	API base URL.
`X402_PRIVATE_KEY`	(unset)	Base wallet private key. Enables auto-pay for paid tools. Accepted with or without the `0x` prefix (surrounding whitespace is trimmed); a set-but-malformed key logs a warning and leaves auto-pay off rather than failing silently.
`X402_MAX_USD`	`0.05`	Per-call auto-pay ceiling. 0 disables auto-pay.
`X402_MAX_TOTAL_USD`	`1.00`	Cumulative auto-pay cap per process. 0 = unlimited.
`X402_MAX_CALLS`	`1000`	Max paid calls per process. 0 = unlimited.
`X402_TIMEOUT_MS`	`20000`	Request timeout.

The free tools work with no configuration at all.

Security

X402_PRIVATE_KEY is a hot wallet — fund it with only what you're willing to spend on trust lookups. The key never leaves your machine; it signs EIP-3009 payment authorizations locally.

Policy checks enforced before signing:

Chain allow-list (Base mainnet by default)
Canonical USDC contract verification (no arbitrary tokens)
Optional payTo allow-list
Per-call spend ceiling (X402_MAX_USD)
Cumulative spend cap (X402_MAX_TOTAL_USD)
Call-count cap (X402_MAX_CALLS)

Verifying response signatures

Tool results are provider-signed: the result object of signed tools carries a top-level signature block with an Ed25519 signature over the JCS-canonicalized (RFC 8785) response without the signature field. This proves the content was assembled by x402-trust and not modified afterwards.

To verify a result:

Take the result object and remove its signature field.
Canonicalize with JCS (RFC 8785): object keys sorted by UTF-16 code unit order, no whitespace, ECMAScript number formatting.
SHA-256 the canonical UTF-8 bytes; the hex must equal signature.digest.
Verify signature.value (base64url, no padding) against the public key that signature.keyId resolves to in your PINNED copy of the key document (see below).

Trust anchor: pin, do not follow. signature.publicKeys is a discovery hint, never a trust source. A verifier that fetches the key URL from the response it is checking verifies against a key chosen by the sender, which proves nothing: a forged response would carry the attacker's own key URL and still verify. Pin one of these in your client instead:

the public key itself (strongest, works offline; add new keys on rotation), e.g. { "x402trust-2026-08": "i4jrHKvmZ98-IGgseDfMTjMV4lAaLAgk-EnBeRIJQ5Y" } (current at the time of writing; the key document always carries the full list, retired keys included), or
the key document URL https://x402.fuchss.app/.well-known/x402-trust-keys.json, fetched over HTTPS once at bootstrap and cached (rotation-friendly).

Retired keys stay published forever, so a response you froze as evidence remains verifiable. A worked test vector and a 20-line reference verifier live at https://x402.fuchss.app/schemas. Watch management responses (x402_watch_create, x402_watch_edit, x402_watch_cancel, x402_watch_renew) are unsigned by design: they carry capability secrets that must never be forwarded as evidence.

License

MIT

Available Tools

13 tools

x402_ecosystem_statsx402 ecosystem stats (free)A

Free aggregate snapshot of the entire x402 ecosystem (Base + Solana): how many endpoints are listed/active/delisted, what fraction are reachable and spec-compliant, and real on-chain USDC settlement volume / receivers / payers over the last 30 days. Use this to gauge market health before transacting.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided. The description fails to disclose data freshness (e.g., how often the snapshot updates), rate limits, or whether the output is static or dynamic. For a tool with zero annotations, the description carries the full burden and doesn't address these behavioral traits.

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?

Two sentences: first enumerates data points, second gives usage guidance. No redundant words. Every sentence earns its place.

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

Completeness3/5

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

For a zero-parameter, no-output-schema tool, the description is adequate but lacks details on output format, update frequency, or size limits. It covers the 'what' well but misses the 'how' and 'limitations,' leaving some gaps for an agent to navigate.

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?

The input schema has zero parameters, so schema description coverage is 100%. The description adds value by explaining the content of the snapshot, though this is more about output. Baseline for no params is 4, and the description does not detract.

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?

The description uses specific verbs like 'aggregate snapshot' and lists exact metrics (endpoints, settlement volume, etc.). It clearly distinguishes from sibling tools like x402_endpoint_history or x402_trust_score by focusing on ecosystem-wide stats.

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 description explicitly states 'Use this to gauge market health before transacting,' providing a concrete when-to-use scenario. It could be improved by explicitly naming when not to use (e.g., for individual endpoint details), but the context allows inferring differentiation from siblings.

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

x402_endpoint_historyx402 endpoint observation history (paid)A

Raw observation time-series for a SPECIFIC x402 endpoint: listing/delisting/relisting events, advertised price changes, payTo changes, and probe results (uptime, latency, quoted amount) over the requested window (1-90 days). Per-probe 'latencyMs' is measured from a single EU vantage point and includes network distance to the endpoint. Pay-per-call over x402; auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Lookback window in days (default 30)
`resource`	Yes	Full x402 resource URL

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden. It discloses pay-per-call behavior, auto-pay logic, and measurement specifics (single EU vantage point, includes network distance). This adds valuable behavioral context.

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?

Two sentences, no wasted words. The first sentence packs all essential details, the second adds pricing and measurement context. Highly efficient.

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?

Given no output schema, the description sufficiently describes the return (time-series of events and probe results). It covers input, output, pricing, and measurement caveats. It is complete for a history tool, though pagination or format details are omitted.

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 baseline is 3. The description adds significant meaning beyond the schema by explaining the types of events in the time-series (listing, delisting, price changes, probe results) and measurement details, enriching the understanding of the parameters.

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?

The description clearly states the tool provides 'Raw observation time-series for a SPECIFIC x402 endpoint' and lists the events included. It distinguishes from sibling tools that focus on ecosystem stats or trust scores.

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 description implicitly tells when to use: when you need historical data for a specific endpoint. It does not explicitly mention when not to use or alternatives, but the context of sibling tools makes the use case clear.

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

x402_find_alternativesFind better-scored alternatives to an x402 endpoint (paid)A

Given an x402 endpoint URL, returns the top semantically-similar endpoints (matched on advertised purpose via description embeddings) that currently OUT-SCORE it on the deterministic trust score. Use this to route away from a mediocre/dead/expensive endpoint toward a more reliable, better-settled one serving the SAME function — e.g. before paying, check if a higher-graded equivalent exists. Each alternative carries its trust 'score', 'grade', 'recommendation', cosine 'similarity' (0-1), 'amountUsd' price, and a free 'endpointPage' URL. Same-host siblings and 'avoid'-flagged endpoints are excluded. An empty 'alternatives' array is a valid answer meaning nothing beats the subject. Similarity is independent of latency/geography. Pay-per-call over x402 (~$0.005); auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max alternatives to return (1-25, default 5)
`resource`	Yes	Full x402 resource URL to find better alternatives for, e.g. https://api.example.com/v1/thing
`minScoreDelta`	No	Minimum trust-score advantage an alternative must have over the subject (default 5)

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description fully discloses behavioral traits: pay-per-call cost (~$0.005), auto-pay behavior, similarity independence from latency/geography, and the fields returned. It does not mention error handling or auth details beyond wallet configuration, but covers major behavioral aspects.

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?

The description is a single, well-structured paragraph with no redundancy. It front-loads the core purpose and progressively adds details (use case, output fields, exclusions, pricing). Every sentence earns its place without verbosity.

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?

Given no output schema, the description fully explains the return object (fields like score, grade, similarity, price, endpointPage URL). It covers purpose, parameters, usage, behavioral notes, and edge cases (empty array). An agent has sufficient information to invoke 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 baseline is 3. The description adds value by explaining how parameters are used (e.g., 'before paying' for resource, default limit, minScoreDelta threshold), and provides an example URL. This goes beyond the schema alone.

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?

The description clearly states the verb 'find' and resource 'better-scored alternatives to an x402 endpoint'. It specifies the action: given an endpoint URL, return semantically similar endpoints with higher trust scores. This distinguishes it from siblings like x402_trust_score (single score) and x402_trust_leaderboard (ranking), making the purpose unambiguous.

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?

Explicit usage guidance is provided: 'Use this to route away from a mediocre/dead/expensive endpoint... before paying, check if a higher-graded equivalent exists.' It also explains valid empty response and exclusions (same-host siblings, 'avoid'-flagged). Lacks direct comparison to sibling tools but the niche is clear.

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

x402_semantic_searchSemantic search over the x402 catalog (paid)A

Free-text SEMANTIC SEARCH across the entire monitored x402 endpoint catalog. Given a plain-language query (e.g. "weather forecast", "image generation", "EVM gas price oracle"), returns the up to 25 endpoints whose advertised purpose is semantically closest. Ranking is deterministic and fully specified: cosine similarity bucketed to whole percentage points first (80.3% and 80.5% are the same bucket, so sub-percent noise never outranks a better endpoint), then trust score (0-100), then described-before-undescribed, then endpoint id as a stable final tiebreak. Matches below a 0.5 cosine-similarity floor are dropped entirely, so a query can return fewer than the requested limit (or none). Endpoints that advertise no description are still matched: they are embedded from their service name and URL path tokens instead of a written description (host name as a last resort). The EXACT effect of a missing description: no fixed point deduction, and no direct similarity malus either; the only deterministic penalty is the described-before-undescribed tiebreak (at equal similarity bucket AND equal trust score, a described endpoint ranks first). Beyond that the effect is purely indirect: the shorter fallback text typically yields lower cosine similarity than a prose description, so undescribed endpoints tend to land in lower similarity buckets, by a query-dependent (never fixed) amount. Use this for DISCOVERY: find candidate endpoints for a capability before checking any of them in depth. Each match carries 'id', 'resource' URL, trust 'score' (0-100), 'grade' (A-F), raw cosine 'similarity' (0-1; ranking buckets it to whole percents), 'description' when advertised, and a free 'endpointPage' URL. 'score'/'grade' are null for endpoints not yet scored. Deliberately NO verdict/recommendation or flag detail: the per-endpoint trust report (x402_trust_score) carries those. Pay-per-call over x402 (~$0.001); auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max matches to return (1-25, default 25)
`query`	Yes	Free-text search query, e.g. "weather forecast". Describe the capability you need in plain words; matching is by meaning, not substrings.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly: deterministic ranking with exact tie-break order, the 0.5 similarity floor, the effect of missing descriptions, null score/grade behavior, payment/auth behavior, and the exact returned fields are all disclosed. There is no contradiction with any annotation because none exist.

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

Conciseness4/5

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

The description is well structured and front-loaded: purpose first, then ranking behavior, then edge cases, then output fields, then cost. It is verbose, especially in the missing-description paragraph, but nearly every sentence earns its place given the absence of annotations and output schema.

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?

Despite having no output schema and no annotations, the description is self-contained: it enumerates all returned fields, the null behavior for unscored endpoints, pricing, payment fallback, and the deterministic ranking semantics. An agent has everything needed to invoke the tool and interpret its result correctly.

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 fully at 100% coverage, so the description does not need to add much. It reinforces the semantic-matching nature of 'query' and the 'up to 25' limit, but it does not materially add new parameter-level constraints or syntax beyond the schema.

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?

The opening sentence states a specific verb ('SEMANTIC SEARCH'), a specific resource ('the entire monitored x402 endpoint catalog'), and a clear output ('up to 25 endpoints whose advertised purpose is semantically closest'). This makes the tool's role as a discovery/search tool obvious and distinguishes it from the trust-score, leaderboard, and watch 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?

The description explicitly says 'Use this for DISCOVERY: find candidate endpoints for a capability before checking any of them in depth.' It also explicitly excludes verdicts, recommendations, and flag details, and directs the agent to x402_trust_score for those, which is clear when-to-use and alternative guidance.

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

x402_trust_bulkx402 bulk trust scoring (paid)A

Score up to 500 x402 endpoints in a SINGLE paid call. Returns the authoritative full-density trust score (0-100, grade A-F or '?' when unmeasured, recommendation proceed|caution|avoid|parameterize|unverified|not-payable), confidence, probed_at, computed_at, and a recomputed flag for each requested resource. Cache rows older than ~15 minutes are recomputed on-demand from the latest stored probes and settlements (no live network re-probe), so bulk scores typically reflect reality within minutes. Per-request recompute limits apply: at most 50 endpoints / 8 seconds are recomputed; the response includes recompute_limit_hit and recompute_limit so you know if the cap was reached. The smallest tier that fits your request is selected automatically (10/50/100/200/500 endpoints; ~$0.045/$0.20/$0.325/$0.40/$0.50). Resources not in our observation set return found:false; you still pay for the batch. For a fresh live probe, use x402_trust_score. Pay-per-call over x402; auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description	Default
`tier`	No	Optional fixed tier size. If omitted, the cheapest tier that fits `resources` is used.
`resources`	Yes	List of full x402 resource URLs (https://...) to score. Duplicates are ignored; max 500.

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries full burden. It thoroughly discloses paid nature, cache staleness (~15 min), recompute limits, response flags (recompute_limit_hit), automatic tier selection, pricing, and found:false behavior. This is comprehensive behavioral transparency.

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?

Although longer than typical, every sentence adds essential operational detail (purpose, outputs, caching, limits, pricing, alternatives). The structure front-loads the primary purpose and then covers edge cases, making it remarkably information-dense without fluff.

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?

Given the tool has no output schema, the description comprehensively explains the return fields (trust score, grade, recommendation, confidence, timestamps, recomputed flag) and all relevant edge cases (not-found, recompute limits, payment behavior). This makes the tool complete for both selection and invocation.

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 baseline is 3. The description adds meaningful context beyond schema: automatic tier selection, pricing for each tier, and the implication that resources not in the observation set still cost money. It also clarifies the 'resources' parameter semantics with the found:false behavior, adding value beyond the raw schema.

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?

The description uses a specific verb ('Score') and resource ('x402 endpoints') in a clear scope ('up to 500' in a 'SINGLE paid call'). It distinguishes from siblings explicitly by naming x402_trust_score as the alternative for fresh live probes.

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?

Provides explicit usage context: suitable for bulk scoring using cached data, with clear guidance that live probing is handled by x402_trust_score. It also warns about paying even for resources not found and explains the per-request recompute limits, helping agents decide when to call this tool.

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

x402_trust_leaderboardx402 trust leaderboard (free)A

Free top-25 most trustworthy x402 endpoints, ranked by a deterministic trust score (uptime, envelope compliance, latency, age, on-chain settlement activity, price stability). Latency is measured from a single EU vantage point and includes network distance to the endpoint (so it is only lightly weighted). Use this to discover reliable paid endpoints.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses that it's free, top-25, deterministic trust score with components, and that latency is measured from a single EU point and lightly weighted. Addresses limitations honestly.

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 concise sentences, each serving a purpose: main output and ranking criteria, latency measurement detail, and use case recommendation. No wasted words.

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?

Without an output schema, the description explains the output content (top-25 endpoints, trust score factors) and pricing (free). Sufficient for a simple list tool with no parameters.

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?

Tool has zero parameters and schema coverage is 100%, so per guidelines baseline is 4. Description adds no parameter info but none is needed.

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?

Clearly states it lists the top-25 most trustworthy x402 endpoints based on a deterministic trust score. Distinguishes from siblings by specifying 'free' and 'top-25', differentiating it from other trust tools like x402_trust_score or x402_trust_bulk.

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?

Explicitly says 'Use this to discover reliable paid endpoints,' providing clear context for when to use. Does not mention when not to use or directly compare with alternatives, but the use case is well-defined.

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

x402_trust_previewx402 trust preview — full sample reports (free)A

FREE showcase of what x402_trust_score returns. You do NOT choose the endpoint: this returns the COMPLETE paid-grade trust report (every field — exact score, scoreRange, full component breakdown, advertised price, on-chain settlement figures, all flags) for THREE endpoints picked from the current population — the best-scored, the median, and the worst-scored ('samples' each carry 'role', 'populationRank', and the full 'report'). Use it to see exactly what the paid output looks like across the entire quality range BEFORE paying. It cannot score an endpoint you choose — to evaluate YOUR OWN endpoint, call x402_trust_score (paid). Takes no arguments.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A5/5.0

Behavior5/5

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

Discloses complete behavioral details: returns three specific samples with full reports, is free, and cannot score user-chosen endpoints. No side effects, but as a read-only preview, no additional disclosure is needed. With no annotations, the description fully covers behavioral traits.

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?

Every sentence is informative and necessary. The description is front-loaded with the key purpose and constraints, and flows logically without fluff.

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?

Given no output schema, the description fully explains what the sample reports contain (every field). It also addresses the use case and limitations. The tool is simple, and the description leaves no gaps.

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

Parameters5/5

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

The tool has zero parameters and schema coverage is 100%. The description adds meaning by explaining that you do not choose the endpoint, which clarifies the lack of parameters beyond the schema.

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?

The description clearly states the tool is a free showcase returning complete trust reports for three sample endpoints (best, median, worst). It distinguishes from x402_trust_score (paid) by explicitly noting it cannot score a user-chosen endpoint.

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 to use (to preview paid output before paying) and when not to use (to evaluate your own endpoint, instead use x402_trust_score). Also notes it takes no arguments.

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

x402_trust_scorex402 trust score for an endpoint (paid)A

Trust score (0-100, grade A-F, or '?' when unmeasured) for a SPECIFIC x402 endpoint -- cataloged or not (uncataloged endpoints are live-probed on first query, auto-adopted, score carries a low-confidence first-contact flag). PLUS a machine-readable verdict ('recommendation': proceed|caution|avoid|parameterize|unverified|not-payable), the advertised price ('advertised.amountUsd'), a confidence-adjusted band ('scoreRange'), and structured flags ('flagsDetailed' with code/severity/message; any severity 'error' means avoid). The 'parameterize' verdict (with 'templated':true) means the resource URL still contains an unresolved template placeholder (e.g. {slug}, :slug or %7B…%7D) but we DO have a real signal (scored probes or a discovery fallback): substitute a valid value first, then the health metrics apply to the resolved URL. The 'unverified' verdict (grade '?') means we have NO measurement at all (every probe excluded and no discovery payment requirements to fall back on): it is unknown, not bad, so verify the endpoint yourself before paying. The 'not-payable' verdict (grade '?') means the URL answers a 402 with an EMPTY accepts[] (an auth/API-key gate such as sign-in-with-x), so it is not an x402-payable resource at all and there is nothing to settle. For templated per-item endpoints that ARE payable, a varying payTo/price is EXPECTED (one wallet/price per item): the report surfaces 'stats.payToVaries'+'payToDistinct30d' and 'advertised.amountRange30d' as a 'payto-varies'/'price-varies' note rather than a 'payto-changed-recently' hijack error; always pay the payTo in the live 402 quote, not a cached listing. 'stats.scoredProbes30d' vs 'stats.excluded30d' show how many probes actually back the score. Includes the full component breakdown, the provider-advertised 'serviceName' and 'description' (unverified provider claims, shown next to our independent metrics), and 30-day on-chain stats. Note: 'stats.avgLatencyMs' is measured from a single EU vantage point and includes network distance to the endpoint (see 'stats.latencyVantage'), so a geographically distant endpoint reads slower even when its server is fast. One call answers WHETHER and at WHAT PRICE to use an endpoint. Call this BEFORE paying an unknown x402 endpoint to avoid dead, fraudulent, or recently-hijacked services. Pay-per-call over x402; auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes	Full x402 resource URL to evaluate, e.g. https://api.example.com/v1/thing

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description fully carries the transparency burden. It discloses live-probing for uncataloged endpoints, the low-confidence first-contact flag, the latency measurement from a single EU vantage point, the meaning of 'unverified' (unknown, not bad), and the expectation that payTo/price may vary for templated endpoints. It also warns that provider-advertised claims are unverified.

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 description is a single dense paragraph with no visual structure, making it harder to scan. Every sentence does convey distinct information, but the lack of bullets, sections, or numbering hurts readability. It is comprehensive but not concise; the sheer length may overload an agent trying to quickly extract key usage rules. It earns a 3 as a minimum viable score for structure.

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?

With no output schema, the description must explain return values, and it does so thoroughly: it lists the score, grade, verdict, price, scoreRange, flagsDetailed, component breakdown, provider claims, and 30-day stats. It covers edge cases (parameterize, unverified, not-payable) and caveats (latency, payTo variation), making the tool's behavior and outputs fully understandable for an agent.

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

Parameters5/5

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

Although the schema already describes `resource` as a full x402 resource URL, the description adds substantial nuance: it gives an example, explains how uncataloged endpoints are probed, and details how template placeholders like {slug} or :slug are treated with a 'parameterize' verdict. This goes well beyond the schema's simple description and helps the agent understand both the format and behavioral expectations for the input.

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?

The description clearly states it computes a trust score for a SPECIFIC x402 endpoint, with a verdict, price, and structured flags. It explicitly contrasts with broader tools by emphasizing specificity ('SPECIFIC x402 endpoint') and saying 'One call answers WHETHER and at WHAT PRICE to use an endpoint', which differentiates it from siblings like x402_ecosystem_stats or x402_trust_bulk.

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?

It gives explicit when-to-use guidance: 'Call this BEFORE paying an unknown x402 endpoint to avoid dead, fraudulent, or recently-hijacked services.' It also provides decision rules for each verdict (parameterize, unverified, not-payable), telling the agent what actions to take or not take for each case, and notes when auto-pay occurs vs. returning a quote.

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

x402_watch_cancelx402 watch — cancel early (free)A

Soft-cancel a watch immediately: no new events accrue, but the event log stays READABLE via x402_watch_events until the original expires_at (cancel is not a delete). Probing drops back to normal cadence as soon as no active watches cover the endpoint. Bearer-authed with the secret from x402_watch_create. Free and idempotent.

ParametersJSON Schema

Name	Required	Description	Default
`secret`	Yes	The one-time bearer secret returned by x402_watch_create.
`watch_id`	Yes	Watch id returned by x402_watch_create.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: soft-cancel (not delete), no new events, events readable until original expiry, probing cadence drops, auth requirement, free, idempotent. Comprehensive.

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 sentences, front-loaded with key information, no unnecessary words. Every sentence adds value.

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?

Covers what the tool does and its effects. No output schema but idempotency implies minimal response. Minor gap on exact return value, but overall complete for a cancellation tool.

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%, and description adds value by explaining the secret is from x402_watch_create and watch_id is from create. Provides provenance beyond the schema.

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?

Clearly states the tool performs a soft-cancel on a watch, distinguishing it from a delete. The verb 'cancel' and resource 'watch' are specific, and the description adds nuance about event log readability.

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?

Provides context on when to use (immediate soft-cancel), contrasts with delete, and mentions idempotency. Could be more explicit about alternatives among siblings, but the sibling list makes it clear this is the cancel tool.

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

x402_watch_createx402 watch — create 30-day endpoint monitor (paid)A

Start monitoring ONE x402 endpoint for 30 days. Get alerted on changes that break autonomous payment: payTo changes (possible takeover/rug — but for a templated per-item endpoint a payTo move is expected variance and is delivered as severity 'warn', not 'critical'), price changes, asset/network changes, 402-spec regressions, delisting, and liveness down/recovered. A self-healing endpoint that repeatedly blips is auto-detected as liveness_flapping and its individual down/up alerts are coalesced into a single flapping notice (plus one 'stopped flapping' notice when it stabilizes) so you are not spammed. Returns a one-time bearer secret + poll URL + renew URL + edit URL + cancel URL + machine-readable next_steps. Use x402_watch_events to poll the append-only log, or configure push delivery to one or more signed HTTPS webhooks and/or Slack/Discord incoming webhooks (max 5 each). webhook_url/slack_url accept a single URL string or an array of URLs. All URLs are connection-tested BEFORE payment — unreachable URLs are rejected with no charge (retry with a corrected URL). On success the response reports per-URL delivery in delivery.connection_test. Webhook signature: x-signature = 'sha256=' + HMAC-SHA256(body) keyed by hex(sha256(secret)), NOT the raw secret. Pay-per-call over x402 (~$0.20); auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description
`events`	No	Event types to subscribe to (default all): payto_change, price_change, asset_network_change, spec_regression, delisting, liveness_down, liveness_recovered, liveness_flapping, latency_regression.
`endpoint`	Yes	Full x402 resource URL to watch. It must already be in our observation set.
`slack_url`	No	Optional Slack or Discord incoming webhook URL(s). Single string or array; max 5.
`webhook_url`	No	Optional signed HTTPS webhook URL(s) for push delivery. Single string or array; max 5.
`liveness_sensitivity_n`	No	Consecutive missed probes before liveness_down surfaces to you (1=paranoid … 10=relaxed; default 2).

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly. It discloses critical behaviors: payTo changes on templated endpoints are severity 'warn' not 'critical', liveness_flapping coalesces alerts, all URLs are connection-tested before payment with no charge for unreachable ones, webhook signature details (HMAC-SHA256 keyed by hex of sha256 secret, not raw secret), and pay-per-call cost. This is exemplary transparency beyond the schema.

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?

The description is long due to the tool's complexity, but every sentence adds value: purpose, event semantics, flapping behavior, return URLs, alternatives, URL configuration, signature format, and cost. It is front-loaded with the primary purpose and flows logically. No tautology or filler.

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?

Given the tool's complexity, no annotations, and no output schema, the description is remarkably complete. It explains return artifacts (bearer secret, poll/renew/edit/cancel URLs, next_steps), payment flow, webhook signature construction, event types, and delivery testing. The only minor omission is a detailed list of event types (left to schema), but the description mentions them by name and provides enough for an agent to invoke 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. The description adds extra semantics: webhook_url/slack_url accept a single string or an array (max 5), all URLs are connection-tested before payment, and delivery is reported in 'delivery.connection_test'. These details go beyond the schema's property descriptions, enhancing understanding of parameter behavior.

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?

The description opens with a specific verb+resource: 'Start monitoring ONE x402 endpoint for 30 days.' It clearly differentiates from siblings by naming x402_watch_events for polling and mentioning renew/edit/cancel URLs returned on success. The scope (one endpoint, 30 days) and delivered event types are explicit.

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 description provides clear context on when to use this tool (start a new monitor) and explicitly names an alternative for consuming events: 'Use x402_watch_events to poll the append-only log.' It also describes payment behavior and that URLs are connection-tested before payment, but does not give explicit 'when not to use' exclusions beyond implying this is for creation. This is clear context without a full when-not matrix.

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

x402_watch_editx402 watch — edit delivery URLs / sensitivity / events (free)A

Edit an active watch: change webhook/Slack URLs, liveness sensitivity, or subscribed events. Bearer-authed with the secret from x402_watch_create. Newly-added URLs are connection-tested before the change is persisted; if any new URL fails, the existing config is unchanged. Delivery fields are full-replace per channel (omit to leave that channel unchanged). Returns the updated watch view.

ParametersJSON Schema

Name	Required	Description
`events`	No	Event types to subscribe to (default all). Omit to keep current events.
`secret`	Yes	The one-time bearer secret returned by x402_watch_create.
`watch_id`	Yes	Watch id returned by x402_watch_create.
`slack_url`	No	Replace Slack/Discord URL(s). Single string or array; max 5. Omit to keep current URL(s).
`webhook_url`	No	Replace webhook URL(s). Single string or array; max 5. Omit to keep current webhook(s).
`liveness_sensitivity_n`	No	1=paranoid … 10=relaxed. Omit to keep current value.

TDQS

A4.4/5.0

Behavior4/5

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

Despite no annotations, the description discloses key behaviors: bearer authentication, connection testing for new URLs, atomicity (unchanged config on failure), full-replace semantics, and return of updated watch view. Missing some edge-case error behavior, but adequate.

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?

The description is three sentences, front-loaded with the main action, and every sentence adds essential information without redundancy.

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?

Given no output schema, the description mentions returns the updated watch view, which is sufficient. It covers the main functional aspects, though error handling details are omitted. Overall, complete for a mutation tool.

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 baseline is 3. The description adds value by explaining connection testing and full-replace behavior, which goes beyond the schema's parameter descriptions.

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?

The description clearly states the tool's purpose: 'Edit an active watch: change webhook/Slack URLs, liveness sensitivity, or subscribed events.' It uses specific verbs and resources, and distinguishes itself from sibling tools like create, cancel, and renew.

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 description provides clear context: requires a secret from x402_watch_create, and explains the full-replace behavior per channel. However, it does not explicitly exclude cases where this tool should not be used (e.g., for creating a new watch).

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

x402_watch_eventsx402 watch — poll event log (free)A

Read the append-only event log for an active x402 watch. Returns two streams: events (endpoint changes — payTo/price/asset/spec/delisting/liveness) and watch_events (lifecycle feedback — created/edited/cancelled/renewed/expiring/expired). Nothing between two polls is lost. Provide the watch_id and the one-time secret from x402_watch_create. Advance since with the returned next_cursor (endpoint events) and watch_since with watch_events_cursor (lifecycle events). Cursors/ids are GLOBAL sequences shared across watches (a watch's first event id may be >1); always page by the returned cursor rather than assuming they start at 1. Cancelled watches remain READABLE until expires_at (no new events accrue). If the watch has push delivery, still poll to reconcile missed webhooks.

ParametersJSON Schema

Name	Required	Description
`since`	No	Endpoint-event cursor: the `next_cursor` from a previous poll. Omit for the first poll.
`secret`	Yes	The one-time bearer secret returned by x402_watch_create.
`watch_id`	Yes	Watch id returned by x402_watch_create.
`watch_since`	No	Lifecycle-event cursor: the `watch_events_cursor` from a previous poll. Omit for the first poll.

TDQS

A4.6/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It reveals that nothing is lost between polls, cursors are global sequences, and cancelled watches stay readable. This provides comprehensive behavioral context beyond a simple read operation.

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

Conciseness4/5

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

The description is a single paragraph of about 10 sentences, packing substantial information without excessive verbosity. Could benefit from light structuring (e.g., separating streams), but remains clear and focused.

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?

No output schema, but description covers both event streams, cursor usage, reliability guarantees, lifecycle behavior, and push reconciliation. This provides all necessary context for correct usage without needing to infer.

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%, and the description adds valuable context: since and watch_since are cursors from previous polls, and secret/watch_id come from creation. It explains cursor advancement and global sequence nature, exceeding schema descriptions.

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?

The description clearly states the tool reads an append-only event log for an x402 watch, returning two streams. It distinguishes from sibling tools (create, cancel, edit, renew) by focusing on polling and event retrieval.

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 description explains when to poll, how to use cursors, and that cancelled watches remain readable. It mentions push delivery reconciliation, but does not explicitly list scenarios where alternative tools should be used instead.

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

x402_watch_renewx402 watch — renew 30 days (paid)A

Extend an active x402 watch by another 30 days before it expires. The secret stays the same. Pay-per-call over x402 (~$0.20); auto-pays if a wallet is configured, otherwise returns the price quote.

ParametersJSON Schema

Name	Required	Description	Default
`watch_id`	Yes	Watch id returned by x402_watch_create.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses that secret stays same and payment model, but omits behavior on invalid watch_id or expired watch, and does not mention idempotency or side effects.

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?

Two sentences with no superfluous words. Information is front-loaded and efficiently conveys core functionality, payment, and secret persistence.

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

Completeness3/5

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

No output schema, so description should explain return format. It vaguely mentions 'returns the price quote,' but does not specify structure or cover error cases like missing watch or expired watch. Lacks completeness for a mutation tool.

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 coverage is 100% and parameter description in schema is adequate ('Watch id returned by x402_watch_create'). The tool description adds no extra meaning about the parameter itself, only behavioral context.

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?

Clearly states the tool extends an active watch by 30 days, distinguishing it from sibling tools like x402_watch_create (creates) and x402_watch_events (lists events).

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?

Specifies timing ('before it expires') and payment behavior (auto-pay or price quote). However, it does not explicitly state when not to use it (e.g., if watch expired) or mention alternatives like creating a new watch.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev1.11.2Aug 22, 2026
- Addedx402_semantic_search
1 tool updatev1.7.0Jul 6, 2026
- Addedx402_find_alternatives

1 tool updatev1.6.0Jul 2, 2026

Changedx402_watch_create1 field changed

changedInput schema / properties / events / description

Previous value: -"Event types to subscribe to (default all): payto_change, price_change, asset_network_change, spec_regression, delisting, liveness_down, liveness_recovered, latency_regression."New value: +"Event types to subscribe to (default all): payto_change, price_change, asset_network_change, spec_regression, delisting, liveness_down, liveness_recovered, liveness_flapping, latency_regression."

1 tool updateJul 1, 2026

Changedx402_watch_events2 fields changed

changedInput schema / properties / since / description

Previous value: -"Cursor: the highest event_id from a previous poll. Omit for the first poll."New value: +"Endpoint-event cursor: the `next_cursor` from a previous poll. Omit for the first poll."

addedInput schema / properties / watch_since

Added value: +{
+  "description": "Lifecycle-event cursor: the `watch_events_cursor` from a previous poll. Omit for the first poll.",
+  "type": "string"
+}

3 tool updatesv1.5.0Jul 1, 2026

Addedx402_watch_cancel

Changedx402_watch_create6 fields changed

addedInput schema / properties / slack_url / $ref
```
Added value: +"#/properties/webhook_url"
```

changedInput schema / properties / slack_url / description

Previous value: -"Optional Slack or Discord incoming webhook URL for push delivery."New value: +"Optional Slack or Discord incoming webhook URL(s). Single string or array; max 5."

removedInput schema / properties / slack_url / type
```
Removed value: -"string"
```

addedInput schema / properties / webhook_url / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / webhook_url / description

Previous value: -"Optional signed HTTPS webhook URL for push delivery."New value: +"Optional signed HTTPS webhook URL(s) for push delivery. Single string or array; max 5."

removedInput schema / properties / webhook_url / type
```
Removed value: -"string"
```

Addedx402_watch_edit

4 tool updatesv1.4.0Jul 1, 2026
- Addedx402_trust_bulk
- Addedx402_watch_create
- Addedx402_watch_events
- Addedx402_watch_renew
5 tool updatesv1.0.0Jun 24, 2026
- First observedx402_ecosystem_stats
- First observedx402_endpoint_history
- First observedx402_trust_leaderboard
- First observedx402_trust_preview
- First observedx402_trust_score

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct purpose: ecosystem stats, leaderboard, preview, single score, history, alternatives, bulk score, and watch lifecycle. Even closely related tools like trust_score vs trust_bulk vs trust_preview are clearly separated by scope (specific vs batch vs system-sampled).

Naming Consistency4/5

All names share the x402_ prefix and snake_case, but the suffix pattern varies: some are noun phrases (trust_leaderboard, endpoint_history), some are verbs (find_alternatives, watch_create), and some are ambiguous (trust_score, trust_bulk). The prefix and predictable domain grouping keep it mostly consistent.

Tool Count5/5

12 tools is well-scoped for a trust/scoring/monitoring service: discovery, scoring, history, alternatives, bulk operations, and a full watch lifecycle. No redundant tools; each covers a distinct feature.

Completeness5/5

The surface covers the domain comprehensively: ecosystem stats, trust discovery/leaderboard, per-endpoint scoring, historical data, alternatives, bulk scoring, and a complete watch CRUD (create, events, edit, cancel, renew). There are no obvious dead ends or missing lifecycle operations.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

blindoracleOAuth
io.github.craigmbrown
The trust layer for the x402 agent economy: verifiable agent identity, payment & audit.
Blockchain Finance Autonomous Agents
2
pulsefeed-x402 A
io.github.Nikolife2016
Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.
Blockchain Payments & Billing Security
111
EP AgentIAM
io.github.achilliesbot
AI agent execution safety via x402 micropayments: risk scoring, integrity, memory checks
Autonomous Agents Security AI & Machine Learning
2
three.ws Agent WalletOAuth
io.github.nirholas
Give your AI agent an x402 wallet: discover and pay for services in USDC, or earn from your own.
Payments & Billing Cryptocurrency Blockchain
223

Related MCP Servers

x402 MCP Payment
Blockchain Cryptocurrency App Automation
motok2031
F
license
Not graded
quality
C
maintenance
Enables AI agents to access paid content by integrating cryptocurrency payments through the x402 protocol, allowing LLMs to verify payments and retrieve paid resources automatically.
Updated 9 months ago (2025-11-23 10:16 UTC)
1
-
x402-mcpofficial
Blockchain Cryptocurrency Payments & Billing
x402node
A
license
C
quality
D
maintenance
MCP server bringing 100+ x402-paid APIs to AI agents (Claude, Cursor, MCP-aware clients). Auto-discovers tools from CDP Bazaar; handles USDC micropayments on Base.
Updated 2 months ago (2026-07-18 20:36 UTC)
100
60
1
MIT
dyoe-agent-tools-mcp
Autonomous Agents Cryptocurrency Web Scraping
bjyoe2016
F
license
A
quality
C
maintenance
Pay-per-call tools for AI agents including trust checks, due diligence, market data, and human-verified approvals, settled in USDC on Base via the x402 protocol.
Updated 2 months ago (2026-07-01 10:19 UTC)
16
-
x402 Ads MCP
Marketing Blockchain Cryptocurrency
forgemeshlabs
A
license
A
quality
A
maintenance
x402 Ads lets AI agents buy and verify ad placements with per-request USDC payments. Agents can discover inventory, submit campaign context, receive structured placement options, and pay through x402 without API keys or accounts. Built for autonomous promotion, attribution, and pay-per-action agent commerce.
Updated 5 days ago (2026-09-01 18:41 UTC)
7
256
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JonasFuchss/x402-trust-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

x402-trust-mcp

Why

Tools

Bulk scoring (x402_trust_bulk)

Finding better alternatives (x402_find_alternatives)

Semantic search (x402_semantic_search)

Watch / alerting (x402_watch_create, x402_watch_events, x402_watch_edit, x402_watch_cancel, x402_watch_renew)

x402_trust_score result

x402 V2 Payment Flow

Install

Configuration (env vars)

Security

Verifying response signatures

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

x402-mcpofficial

Latest Blog Posts

MCP directory API

Bulk scoring (`x402_trust_bulk`)

Finding better alternatives (`x402_find_alternatives`)

Semantic search (`x402_semantic_search`)

Watch / alerting (`x402_watch_create`, `x402_watch_events`, `x402_watch_edit`, `x402_watch_cancel`, `x402_watch_renew`)

`x402_trust_score` result