MCP adapter for x402station.io, the independent risk-signal layer for x402 agentic commerce. Exposes Preflight by x402station.io plus Forensics, Catalog Decoys, Alternatives, Credits, Watch, and Whats New. Any agent speaking the Model Context Protocol gets endpoint evidence before signing PAYMENT-SIGNATURE — decoy, zombie, price-trap, never-paid, latency, signature/settlement checks — before paying.
x402station.io independently probes every endpoint listed on agentic.market every 10 minutes and merges probe history with CDP settlement data. Policy engines decide and enforce; x402station.io measures and reports. We do not route, take custody, or endorse.
# Claude Code / Cursor / Windsurf / Continue — works anywhere with MCP
npm install -g x402station-mcp
# or use npx in the config, no global install needed:Related MCP server: crest-verify
The adapter charges real USDC per paid call through x402 itself. You need a wallet private key that holds Base mainnet USDC.
Add to ~/.claude/claude_desktop_config.json (or wherever your MCP servers live):
{
"mcpServers": {
"x402station": {
"command": "npx",
"args": ["-y", "x402station-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY_HERE"
}
}
}
}Same shape — every MCP host understands command / args / env. See your tool's MCP docs.
Variable | Required | Default | Purpose |
| yes for any paid tool call | — | 0x-prefixed 64-hex-char private key. Account must hold Base mainnet USDC. |
| no |
| Override for dev / testing. |
preflight(url) — $0.001 USDCAsk whether it's safe to pay this x402 URL. Returns:
{
"ok": true,
"warnings": [],
"metadata": {
"service": "...",
"price_usdc": "0.01",
"uptime_1h_pct": 100,
"avg_latency_ms": 412
}
}ok is true only when no critical warning fires. Warnings include unknown_endpoint, no_history, dead, zombie, decoy_price_extreme, never_paid_zombie, proxy_markup, wildcard_402, spa_fallback, suspicious_high_price, slow, and new_provider.
forensics(url) — $0.001 USDCDeep 7-day report. Superset of preflight. Returns hourly uptime, latency p50/p90/p99, status-code distribution, concentration-group stats, decoy probability. Extra warnings: dead_7d, mostly_dead, slow_p99, price_outlier_high, high_concentration.
catalog_decoys() — $0.005 USDCFull blacklist. Returns every active endpoint currently flagged critical, plus per-reason counts. Pull periodically and cache locally — cheaper than preflighting every URL.
agent wants data from some_endpoint.com
│
├─ preflight("https://some_endpoint.com/data") ← $0.001
│ ok: false, warnings: ["decoy_price_extreme"]
│
└─ skip; try the next candidateFor bulk discovery, do catalog_decoys() once per day and treat the result as a set-difference against any URLs you're about to hit.
x402station checks whether the endpoint is safe (decoy / zombie / price-trap / never-paid) before an agent pays. It pairs naturally with a payload safety check — screening the payment metadata for PII before signing:
agent intent: pay some_endpoint.com
├─ x402station preflight(url) ← is the ENDPOINT safe?
├─ presidio-x402 screen_payment_metadata() ← is the PAYLOAD safe?
└─ pay()presidio-hardened-x402-mcp screens payment metadata for PII before signing. The two servers are developed independently, on purpose — keeping the signals uncorrelated is the point. This is a composition pointer, not an endorsement; see their repo for the screening tool's behaviour and limits.
Service: https://x402station.io
Manifest: https://x402station.io/.well-known/x402
Dataset: https://huggingface.co/datasets/x402station/preflight-dataset-v0_1
x402 spec: https://x402.org
General + commercial: hello@x402station.io
Bug reports: https://github.com/sF1nX/x402station-mcp/issues
Security disclosures (RFC 9116): https://x402station.io/.well-known/security.txt
MIT
Given a URL flagged by preflight (or a taskClass hint), returns up to 5 healthy sibling endpoints in the same provider/domain/category/price-band. Filters out 7-day-dead and 1-hour-erroring candidates; ranks by uptime + latency. Costs $0.005 USDC. Use this immediately after preflight returns ok=false — it answers 'where do I go instead?'. Pass {url} when you have a specific URL the agent was about to pay; pass {taskClass} (e.g. 'llm-completions', 'Inference') when discovering by service category; or both for a richer match.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL flagged by preflight (or otherwise rejected). Looked up in the catalog to extract provider / domain / category / price band as match keys. | |
| taskClass | No | Service category hint (e.g. 'llm-completions', 'Inference'). Used as a fallback match key when `url` is unknown to the catalog, OR alone for category-only discovery. | |
| limit | No | Max alternatives to return (1..10, default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: filters out 7-day-dead and 1-hour-erroring candidates, ranks by uptime+latency, costs $0.005 USDC, and falls back to taskClass if url is unknown. It lacks details on edge cases like missing both parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence paragraph efficiently conveys purpose, input, behavior, and usage hint. Every sentence is informative with no redundancy, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use case, filtering criteria, cost, and parameter guidance. Missing return format details and error handling (e.g., no alternatives found), but is sufficient given no output schema and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds context beyond field descriptions: explains how url and taskClass are used as match keys, the ranking logic, and implies default limit of 5. This enriches the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'returns up to 5 healthy sibling endpoints' when given a flagged URL or taskClass hint. It distinguishes itself from sibling tools like preflight by specifying it is used after preflight returns ok=false, providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Use this immediately after preflight returns ok=false'. It also explains the different parameter combinations (url, taskClass, or both) and when to choose each, providing strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk-prepaid preflight bundle. Pay $0.50 USDC once for 1000 prepaid /api/v1/preflight calls. Effective rate $0.0005/call (50% off the per-call $0.001 tier). Returns { creditId, balance: 1000, expiresAt }. STORE THE creditId — it's the bearer token and is not retrievable later. Pass it via X-Credit-Id header on subsequent /api/v1/preflight calls; on exhaustion (balance=0) or expiry (90 days) the middleware falls through to per-call x402 automatically. Use this once you've decided to do high-volume preflight work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses cost, return structure, the need to store creditId (not retrievable later), header usage, expiration (90 days), and fallback behavior. Lacks details on error handling but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of six sentences, front-loaded with the main purpose. It covers cost, returns, usage, and fallback without unnecessary words. Could be more structured but is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values ({ creditId, balance, expiresAt }) and provides complete usage instructions including header and fallback. It covers the lifecycle well, though missing prerequisites like account setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so baseline score of 4 applies. The description does not need to add parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Bulk-prepaid preflight bundle' and specifies paying $0.50 USDC for 1000 calls, making the action and resource clear. It distinguishes from siblings like 'preflight' (which performs calls) and 'credits_status' (which checks balance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this once you've decided to do high-volume preflight work,' providing a clear context for use. It implicitly contrasts with per-call pricing via the fallback mechanism, but does not explicitly list when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every active x402 endpoint currently flagged decoy_price_extreme / zombie / dead_7d / mostly_dead in one JSON payload, plus per-reason counts. Costs $0.005 USDC. Pull periodically (hourly/daily) and cache locally as a blacklist — cheaper than preflighting every URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description fully discloses cost and caching recommendation. It implies a read-only operation with no side effects. Lacks details on rate limits or error responses, but for a simple data retrieval tool, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then immediately followed by actionable usage guidance and cost. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers purpose, cost, and usage pattern. Minor gaps: does not mention authentication requirements or typical result size. Still fairly complete for a simple blacklist tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds value by specifying what is returned (active endpoints + counts), going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns active flagged x402 endpoints with per-reason counts. Verb 'returns' and specific resource ('catalog of decoys/zombie blacklist') make purpose unambiguous. Distinguishes from siblings by noting it's a blacklist meant for periodic caching, unlike preflight or other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to pull periodically and cache locally, and contrasts with 'preflighting every URL' as a cheaper alternative. Provides cost context ($0.005 USDC). Could be more explicit about when not to use, but gives clear context on the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no payment required. Returns { creditId, balance, initialBalance, used, paidAmount, createdAt, expiresAt, expired, paymentTx, paymentNetwork }. UUID-only access — anyone holding the creditId can read state, same as decrement. 404 covers both 'malformed UUID' and 'no such credit' (same body so an attacker scraping random UUIDs can't tell them apart).
| Name | Required | Description | Default |
|---|---|---|---|
| creditId | Yes | The creditId UUID returned by buy_credits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond a simple read: it explains that the tool is free, that anyone with the creditId can access it (security implication), and that 404 errors intentionally blur malformed UUIDs and non-existent credits to prevent enumeration. This is valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the key information (free, return fields) and then adding security notes. Every sentence serves a purpose; no redundancy or filler. It is maximally efficient for its informational load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is complete: it lists the return fields, explains the access model, and addresses security. Given the low complexity and good schema coverage, no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the creditId parameter with format and origin. The description adds meaning by framing the parameter as a secret that gives anyone holding it read access, echoing the decrement permission model. This enhances the parameter's semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool reads a credit's balance and expiry. It lists the returned fields, making the purpose explicit. However, it does not explicitly differentiate from siblings like buy_credits or preflight, leaving some ambiguity for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that no payment is required and that anyone with the UUID can read state, but it does not provide explicit guidance on when to use this tool versus alternatives like buy_credits or forensics. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep history for one x402 endpoint: hourly uptime over 7 days, latency p50/p90/p99, status-code distribution, concentration-group stats (how crowded this provider's namespace is), and a decoy probability score [0, 1]. Costs $0.001 USDC. Superset of preflight — if you're running forensics you don't need preflight too.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full URL of the x402 endpoint to analyse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses cost ($0.001 USDC) and the scope of data (7-day history). It does not mention potential failure cases or permissions, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load all critical information: data provided, cost, and relationship to sibling tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return data (list of metrics). Could mention pagination or error handling, but the depth is sufficient for a paid tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers the single parameter with a clear description. The description adds that the URL must be for an x402 endpoint, but this is minor beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'deep history for one x402 endpoint' and lists specific metrics (uptime, latency, status-code distribution, etc.), differentiating from siblings like preflight by explicitly stating it's a superset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'superset of preflight — if you're running forensics you don't need preflight too.' Also mentions cost, helping agents decide when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask x402station whether a given x402 URL is safe to pay. Returns {ok, warnings[], metadata}. Costs $0.001 USDC (auto-signed with AGENT_PRIVATE_KEY). Call this BEFORE any other paid x402 request to avoid decoys (price ≥ $1k), zombie services, and dead endpoints. ok:true only when no critical warning fires.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full URL of the x402 endpoint the agent is about to pay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: costs $0.001 USDC, auto-signed with AGENT_PRIVATE_KEY, returns ok only when no critical warning fires. Warns about specific threats (decoys ≥$1k, zombie services, dead endpoints).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and output, second provides usage guidance and cost. No wasted words; critical information presented first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return structure and conditions. Covers cost, signing, and specific dangers to avoid. For a simple tool with one parameter, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'url' has schema description ('The full URL of the x402 endpoint') and description adds context ('given x402 URL') and ties it to safety check purpose. Schema coverage is 100%, so baseline 3; description adds value by connecting parameter to tool's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an x402 URL is safe to pay, specifies the return value format ({ok, warnings[], metadata}), and distinguishes it from sibling tools by emphasizing it should be called before paid requests to avoid decoys, zombies, and dead endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call 'BEFORE any other paid x402 request' to avoid specific risks (decoys, zombies, dead endpoints). Also mentions cost ($0.001 USDC) and auto-signing. Lacks explicit when-not-to-use guidance, but the positive directive is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current state of a watch: active/expired, alerts remaining (out of 100 prepaid), last 10 alert deliveries with their delivery_status, and the last computed signal snapshot. Free — no payment required, secret-gated. The secret is the one returned by watch_subscribe.
| Name | Required | Description | Default |
|---|---|---|---|
| watchId | Yes | The watchId UUID returned by watch_subscribe. | |
| secret | Yes | The 64-char hex secret returned by watch_subscribe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the tool reads current state (active/expired, alerts, deliveries, signal), is free, and requires the secret from watch_subscribe. It does not mention error handling or side effects, but for a read-only status tool, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence lists all returned fields. Second notes free and secret-gated. Third ties secret to watch_subscribe. Front-loaded main purpose, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description explains return fields sufficiently (state, alert count, deliveries, signal snapshot). Lacks details on error responses or data format for signal snapshot, but overall adequate for a 2-param read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (UUID watchId, 64-char hex secret). Description adds value by specifying the secret is the one returned by watch_subscribe, linking to a related tool. This extra context goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'returns the current state of a watch' and enumerates specific fields (active/expired, alerts remaining, last 10 deliveries, signal snapshot). The verb 'returns' and resource 'watch status' are specific, and it distinguishes from sibling tools like watch_subscribe and watch_unsubscribe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that the tool is free and secret-gated, linking the secret to watch_subscribe, which implies usage after subscribing. However, it lacks explicit guidance on when not to use it or comparisons to siblings like watch_unsubscribe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay $0.01 USDC for a 30-day watch + 100 prepaid alerts on one x402 endpoint. When subscribed signals fire or clear (e.g. endpoint goes zombie, price flips to decoy_price_extreme), x402station POSTs a JSON payload signed with HMAC-SHA256 to your webhookUrl. Returns watchId + secret — STORE THE SECRET, it's the HMAC seed for verifying delivery payloads and is not retrievable later. signals defaults to the critical preflight subset {dead, zombie, decoy_price_extreme}; pass other names to subscribe to non-critical signals too.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint URL to watch. | |
| webhookUrl | Yes | Where x402station should POST alert payloads. Must be HTTPS, reachable from the public internet, and contain no userinfo (no user:pass@host). Loopback (127.0.0.1, ::1, localhost), private (RFC1918, link-local 169.254/16 incl. cloud metadata, CGNAT/Tailscale 100.64/10) and IPv6 ULA / multicast / NAT64 / 6to4 / Teredo hosts are rejected client-side; the server applies the same SSRF guard if you bypass this check. | |
| signals | No | Signal names to alert on. Defaults to ['dead', 'zombie', 'decoy_price_extreme']. Full vocabulary covers preflight + forensics signals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers key behavior: cost, duration, prepaid alerts, returned watchId and secret, HMAC verification, and that the secret is non-retrievable. It does not mention cancellation or error scenarios but is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the purpose and cost. It is concise but could be slightly more structured (e.g., separating return info). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions returns (watchId + secret) and explains the secret's role. It covers subscription details and defaults, though it omits error cases or endpoint validation. Sufficient for a tool with few parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds value by stating the default signals and reinforcing webhookUrl constraints (HTTPS, no userinfo, SSRF guard). This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool subscribes to webhook alerts for x402 endpoint state changes, specifying the cost, duration, and alert count. It distinguishes from sibling tools like watch_status and watch_unsubscribe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the subscription process, default signals, and the need to store the secret, but lacks explicit guidance on when to use this tool versus alternatives like watch_status or watch_unsubscribe. However, the context of cost and setup is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivates the watch — no further alerts will be queued or delivered. The subscription is set is_active=false but the row + alert history is retained for audit. Free — no payment required, secret-gated. There is no refund for unused prepaid alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| watchId | Yes | The watchId UUID returned by watch_subscribe. | |
| secret | Yes | The 64-char hex secret returned by watch_subscribe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: deactivation, cessation of alerts, row+history retention, free, secret-gated, and no refund. This is comprehensive for the tool's action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences with no redundancy. It is front-loaded with the primary action and uses minimal but informative language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the main points. It lacks potential error cases but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described. The description does not add new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deactivates a watch and explains the effect: no further alerts, is_active=false, and retention of history. This distinguishes it from the sibling watch_subscribe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it deactivates a watch, is free, secret-gated, and there is no refund. It implies when to use (stop alerts) but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polling-friendly catalog diff. Body { since?, limit? } (default since=now-24h, limit=200, max 500). Returns added_endpoints[] (first_seen_at >= since AND is_active=true), removed_endpoints[] (flipped to is_active=false since), service-level counts, polls_in_window, and current active totals. Cheap ($0.001 USDC) so hourly polling stays under $1/month — perfect for aggregator agents that need a fresh delta without re-pulling the whole catalog. Internal ingest cron runs every 5 min, so polling more often than that returns identical data.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ISO 8601 timestamp. Default = now() - 24h. Cannot be older than 30 days or in the future. | |
| limit | No | Per-list cap (1..500, default 200). Applied independently to added_endpoints and removed_endpoints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: cost ($0.001 USDC), internal cron interval (5 min), and that faster polling yields unchanged data. It also explains the logical conditions for inclusion in added/removed lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact 5 sentences, each delivering critical info. The main purpose is front-loaded. Slightly verbose in the pricing example, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates all returned fields (added_endpoints, removed_endpoints, counts, polls_in_window, active totals) and explains behavior and constraints, making it fully informative for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions. The description adds value by stating defaults (since=now-24h, limit=200) and clarifying the limit applies independently to each list, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'polling-friendly catalog diff' that returns added and removed endpoints since a given timestamp, distinguishing it from sibling tools like the full catalog or subscription-based tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends use for 'aggregator agents that need a fresh delta without re-pulling the whole catalog' and notes that polling more often than every 5 minutes returns identical data. However, it does not list specific alternative tools or conditions to avoid usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.10alternativesbuy_creditscatalog_decoyscredits_statusforensicspreflightwatch_statuswatch_subscribewatch_unsubscribewhats_newScored across 10 tools
Each tool serves a distinct function: preflight checks, alternative endpoints, credit management, forensics, catalog blacklists, watch subscriptions, and catalog diffs. Descriptions are detailed, leaving no ambiguity about tool purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., buy_credits, watch_subscribe, whats_new), making predictions and selection straightforward for an agent.
With 10 tools, the server covers its domain of endpoint safety monitoring, credit management, and subscription alerts without being overly bloated or sparse.
The tool surface covers the main workflow: preflight checks, alternatives, credit buying, status, forensics, blacklisting, watching, and polling. A minor gap is the lack of a free endpoint status query for a single URL, but the paid preflight covers it.
Free token-safety scans + paid x402 verdicts, signals, radar & EVM swap quotes for AI agents.
Free token-safety scans + paid x402 verdicts, signals, radar & EVM swap quotes for AI agents.
Pre-execution safety layer for autonomous agent wallets via MCP and x402.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
