SCRIPTMASTERLABS — x402 Gateway

omnilist_run

Destructive

OmniList (PAID $1.00 USDC on Base via x402). File-once listing run for an x402 server or MCP server: give ONE server record and OmniList presence-checks it, files it where it is missing, and reads back a receipt at x402-list, 402index, x402dash, nohumans.directory and the MCP Registry (PREPARED artifact there — publishing needs the namespace owner's own key). Every venue is free to file; the $1.00 pays for the run, the venue know-how, and the verified per-venue report (states: FILED with receipt id, PENDING_REVIEW, ALREADY_PRESENT by read-back, PREPARED, BLOCKED with the exact reason). Runs execute live against third-party venues, so this tool starts the run and returns a run_id; fetch the finished report with omnilist_report or GET /x402/omnilist/runs/<run_id>. Use for: getting a new x402/MCP server into the directories agents actually browse. Don't use when: you expect a guaranteed listing (venue review decisions belong to the venues) or a free run (there is none — unpaid calls return the payment challenge). Settlement to the canonical SML payTo on Base.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "kind": "<kind>",
      "description": "<description>",
      "contact_email": "<contact_email>"
    },
    "name": "omnilist_run"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	What the record describes.
`name`	Yes	Server name, e.g. "OMNIGATE".
`tools`	No	Tool inventory for the MCP Registry artifact: every tool name + price is declared in the generated server.json.
`website`	No	Website / product page URL.
`networks`	No	Network slugs the server settles on, e.g. ["base"].
`endpoints`	No	Individual payable endpoint URLs for endpoint-level venues (402index, x402dash).
`description`	Yes	One-paragraph description; the first sentence is load-bearing.
`api_base_url`	No	Base URL of the x402 API surface, for plain HTTP APIs.
`mcp_endpoint`	No	Remote MCP endpoint (streamable-http), when the server speaks MCP.
`contact_email`	Yes	Contact email filings are made under (x402-list gates one filing per email per 7 days).
`registry_name`	No	MCP Registry name you own, e.g. "com.example/my-server" — used for the PREPARED server.json artifact.
`payment_header`	No	Base64 X-PAYMENT EIP-3009 payload (standard rail) for $1.00 USDC on Base.
`wallet_address`	No	Agent wallet address (informational).
`payment_tx_hash`	No	Base USDC tx hash (sovereign rail) paying $1.00 to the canonical SML receiver.
`settler_address`	No	Single settler / signer address (facilitators) — alias for a one-entry settler_addresses list.
`facilitator_slug`	No	Facilitator slug on x402-list (lowercase letters, digits, hyphens) — required for x402-list facilitator filings.
`settler_addresses`	No	Settler / signer addresses (facilitators).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026

addedInput schema / properties / facilitator_slug

Added value: +{
+  "description": "Facilitator slug on x402-list (lowercase letters, digits, hyphens) — required for x402-list facilitator filings.",
+  "maxLength": 128,
+  "type": "string"
+}

addedInput schema / properties / settler_address

Added value: +{
+  "description": "Single settler / signer address (facilitators) — alias for a one-entry settler_addresses list.",
+  "maxLength": 128,
+  "type": "string"
+}

AddedNov 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag destructive/openWorld/non-idempotent, and the description adds substantive context beyond them: the $1.00 USDC-on-Base charge, that venues run live and thus the call returns a run_id rather than a final result, the MCP Registry artifact needing the owner's key, and the closed set of outcome states. It stops short of quantifying cost per venue attempt or retry behavior.

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?

Dense but front-loaded: cost, then what it does, then the async return, then use/don't-use. The single long paragraph packs a lot and every clause carries information, though splitting the run_id/return mechanics from the pricing prose would improve scanability.

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

Completeness5/5

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

For a 17-parameter, non-idempotent, open-world mutation with no output schema, the description covers everything an agent needs: the payment rails, that it returns a run_id instead of the report, how to retrieve the report, and the enumerated per-venue outcome states.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 17 parameters including the payment_header/payment_tx_hash rails and the facilitator fields. The description reinforces the payment and one-record framing but adds no per-parameter syntax or format guidance beyond what is already structured.

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?

States a specific verb and resource ('File-once listing run for an x402 server or MCP server'), names the venues and the PREPARED limitation, and implicitly distinguishes itself from omnilist_report by noting that the run is started here and the report is fetched elsewhere.

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?

Contains explicit 'Use for:' and 'Don't use when:' sections with the two real exclusions (no guaranteed listing, no free run — unpaid calls return the payment challenge), plus routing to omnilist_report for the finished report.

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

All SCRIPTMASTERLABS — x402 Gateway tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.