PayAPI Market

Submit a listing to PayAPI Market

submit_listing

List one or more APIs. The minimum is a paid URL (url, paid_route_url, or urls) and contact_email (email is accepted as the same field). Price, payTo, network, description and name are read from the HTTP 402 when you omit them. Category defaults to Data, which the listing schema accepts. urls takes at most 20 routes. Each route is probed and returned in results as listed, pending or rejected, with a code and a hint when it is turned away. A no-input GET that returns a valid 402 may omit sample_input. Placeholder examples are rejected. NEVER sets payment_verified or makes the listing live. PayAPI Market may test it with a real paid call (up to $0.10 USDC on Base). Listing is free. Providers keep 100%. Rate limited: max 10 submissions per hour per wallet and per contact email, 50 per day per IP and per payTo address. The cap still applies inside a urls array. If this wallet already submitted this API, the result is the existing listing id and the message "This API has already been submitted." No second row is created. The same wallet and email can update a listing that is still pending review.

Input Schema

Name	Required	Description
`url`	No	One https route that returns HTTP 402. Use this, paid_route_url, or urls.
`name`	No	API name. Read from the 402 when omitted.
`urls`	No	Up to 20 paid routes in one call. Each is probed on its own.
`email`	No	Same as contact_email.
`payTo`	No	Base wallet that receives USDC. Read from the 402 when omitted.
`price`	No	Price per request in USDC. Read from the Base accept when omitted.
`method`	No	How we call the paid route. Read from the 402 when omitted. GET uses sample_input as a query string. POST uses it as a JSON body.
`network`	No	Only listings that accept USDC on this network: base, solana, algorand, or a CAIP-2 id. Omit for all. Each listing reports its rails in `networks`.
`base_url`	No	Base URL of the API (https only, no localhost or tunnels). Defaults to the paid route origin.
`category`	No	API category. Defaults to Data when omitted. There is no Other category.
`networks`	No	Networks this API accepts (e.g. ["base"], ["base", "solana"]). The Base rail is read from the 402.
`sample_url`	No	Optional free sample or health URL. Called unpaid, before any paid check.
`description`	No	API description. Read from the 402 or /.well-known/x402 when omitted.
`mcp_endpoint`	No	Optional: MCP endpoint URL if this is an MCP server
`sample_input`	No	Example request. A query string for GET (city=London) or a JSON body for POST ({"city":"London"}). Read from the 402 when omitted. A no-input GET with a valid 402 may leave this empty. Placeholders are rejected.
`contact_email`	Yes	Contact email for the provider. Required. email is the same field.
`provider_name`	No	Optional: provider/company name (defaults to API name)
`paid_route_url`	No	The exact route that requires x402 payment. Same as url.
`input_param_to_vary`	No	Optional parameter name to change between two free sample calls, for example city.
`settles_after_success`	No	Confirm the paid route settles only after a successful response. Required only when the server switch is on.
`example_expected_output`	No	Optional JSON shape or short sample the free check compares against.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedOct 31, 2026

changedInput schema / properties / base_url / description

Previous value: -"Base URL of the API (http(s) only, no localhost/tunnels)"New value: +"Base URL of the API (https only, no localhost or tunnels). Defaults to the paid route origin."

changedInput schema / properties / category / description

Previous value: -"API category"New value: +"API category. Defaults to Data when omitted. There is no Other category."

changedInput schema / properties / contact_email / description

Previous value: -"Contact email for the provider"New value: +"Contact email for the provider. Required. email is the same field."

changedInput schema / properties / description / description

Previous value: -"API description"New value: +"API description. Read from the 402 or /.well-known/x402 when omitted."

addedInput schema / properties / email

Added value: +{
+  "description": "Same as contact_email.",
+  "type": "string"
+}

changedInput schema / properties / method / description

Previous value: -"How we call the paid route. GET uses sample_input as a query string. POST uses it as a JSON body."New value: +"How we call the paid route. Read from the 402 when omitted. GET uses sample_input as a query string. POST uses it as a JSON body."

changedInput schema / properties / name / description

Previous value: -"API name"New value: +"API name. Read from the 402 when omitted."

changedInput schema / properties / networks / description

Previous value: -"Networks this API accepts (e.g. [\"base\"], [\"base\", \"solana\"])"New value: +"Networks this API accepts (e.g. [\"base\"], [\"base\", \"solana\"]). The Base rail is read from the 402."

changedInput schema / properties / paid_route_url / description

Previous value: -"The exact route that requires x402 payment (http(s) only)"New value: +"The exact route that requires x402 payment. Same as url."

changedInput schema / properties / payTo / description

Previous value: -"Wallet address that receives payments (Base: 0x... address, Solana: base58 address)"New value: +"Base wallet that receives USDC. Read from the 402 when omitted."

changedInput schema / properties / price / description

Previous value: -"Price per request in USDC"New value: +"Price per request in USDC. Read from the Base accept when omitted."

changedInput schema / properties / sample_input / description

Previous value: -"Required example request. A query string for GET (city=London) or a JSON body for POST ({\"city\":\"London\"}). Placeholders are rejected."New value: +"Example request. A query string for GET (city=London) or a JSON body for POST ({\"city\":\"London\"}). Read from the 402 when omitted. A no-input GET with a valid 402 may leave this empty. Placeholders are rejected."

addedInput schema / properties / url

Added value: +{
+  "description": "One https route that returns HTTP 402. Use this, paid_route_url, or urls.",
+  "type": "string"
+}

addedInput schema / properties / urls

Added value: +{
+  "description": "Up to 20 paid routes in one call. Each is probed on its own.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "description",
-  "paid_route_url",
-  "price",
-  "payTo",
-  "contact_email",
-  "category",
-  "sample_input"
-]New value: +[
+  "contact_email"
+]

Changed7 schema fields changedOct 31, 2026

addedInput schema / properties / example_expected_output

Added value: +{
+  "description": "Optional JSON shape or short sample the free check compares against.",
+  "type": "string"
+}

addedInput schema / properties / input_param_to_vary

Added value: +{
+  "description": "Optional parameter name to change between two free sample calls, for example city.",
+  "type": "string"
+}

addedInput schema / properties / method

Added value: +{
+  "description": "How we call the paid route. GET uses sample_input as a query string. POST uses it as a JSON body.",
+  "enum": [
+    "GET",
+    "POST"
+  ],
+  "type": "string"
+}

changedInput schema / properties / sample_input / description

Previous value: -"Optional: sample request body for POST routes"New value: +"Required example request. A query string for GET (city=London) or a JSON body for POST ({\"city\":\"London\"}). Placeholders are rejected."

addedInput schema / properties / sample_url

Added value: +{
+  "description": "Optional free sample or health URL. Called unpaid, before any paid check.",
+  "type": "string"
+}

addedInput schema / properties / settles_after_success

Added value: +{
+  "description": "Confirm the paid route settles only after a successful response. Required only when the server switch is on.",
+  "type": "boolean"
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "description",
-  "paid_route_url",
-  "price",
-  "payTo",
-  "contact_email",
-  "category"
-]New value: +[
+  "name",
+  "description",
+  "paid_route_url",
+  "price",
+  "payTo",
+  "contact_email",
+  "category",
+  "sample_input"
+]

AddedOct 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Discloses behavior an agent cannot infer from annotations: real paid probes up to $0.10 USDC on Base, per-route probing with listed/pending/rejected outcomes, dedupe that returns the existing listing id without creating a second row, and hard rate limits (10/hr per wallet and per email, 50/day per IP and per payTo, applied per element inside urls). The non-live, non-verified boundary is stated explicitly. Minor tension with idempotentHint=false (duplicate submits are described as side-effect-free for the same wallet/API pair), but the description's disclosure is richer than the annotation, not contrary to it.

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?

Front-loaded with the minimum viable input set before the edge cases, which is the right ordering for a 21-parameter tool. It runs long and repeats the 'read from the HTTP 402 when you omit them' idea that the schema already states per-field, and the quoted duplicate-submission message is more verbosity than the agent needs. Still, nearly every sentence carries operational weight.

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 21-parameter mutation with no output schema, the description covers the full contract: required inputs, derivable defaults, probe outcomes and their status vocabulary, cost exposure, rate limits, dedupe behavior, and the update-while-pending path. An agent could call this correctly and set expectations without opening any other artifact.

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 earns extra by adding cross-field semantics the schema cannot express - that contact_email is the only schema-required field yet a paid route (url, paid_route_url, or urls) is also mandatory, that email is an alias, that urls caps at 20, and which fields are recovered from the 402 when omitted. Defaults for category and the rejection of placeholder examples are also clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title plus opening line 'List one or more APIs' identifies a marketplace submission, and the body makes clear it probes routes and creates/reuses a listing. The verb 'List' is unfortunately identical to the sibling list_apis, so an agent skimming the first sentence alone could misread the intent. The remainder of the description resolves this, but sibling differentiation isn't stated explicitly.

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?

Gives concrete entry criteria (minimum is a paid URL plus contact_email, email is an accepted alias), explains what can be omitted because it is re-derived from the 402, and states the 'NEVER makes the listing live' boundary. It also covers the resubmission path (same wallet + same API returns the existing id). What's missing is any pointer to siblings such as search_apis for checking whether an API is already listed.

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

All PayAPI Market 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.

Resources

Need Help?