Apiosk MCP Server

Overview Schema Source Related Servers Score Discussions Admin

Publish a paid x402 route

publish_x402_route

Idempotent

Monetize your existing API by creating a paid x402 route that collects USDC per call before forwarding to your upstream endpoint.

Instructions

Publish an API endpoint as a paid x402 route on the Apiosk gateway. The route gets a paid URL that returns 402 Payment Required until the caller pays in USDC, then forwards to your upstream API. New routes enter Apiosk's review queue (status pending_review) and go live on approval. Requires an Apiosk provider token (Authorization: Bearer sk_live_…).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Human-readable API name, e.g. 'Weather API'.
`path`	No	Public path under the route's gateway slug, e.g. /weather. Defaults to the last segment of upstream_url.
`slug`	No	Optional gateway slug override (lowercase letters, numbers, hyphens). Defaults to a slug derived from name.
`tags`	No
`price`	Yes	Price per call in USDC, e.g. "0.01".
`method`	No	Defaults to GET.
`network`	No	Settlement network. Defaults to base.
`currency`	No	Only USDC is supported.
`description`	No
`input_schema`	No
`upstream_url`	Yes	Full HTTPS URL of your existing endpoint the gateway forwards paid requests to.
`output_schema`	No
`settlement_address`	Yes	Wallet that receives 98% of each payment (Apiosk keeps a 2% platform fee).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedv1.8.0Sep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

It discloses important runtime behavior beyond annotations: the URL returns 402 until paid in USDC, then forwards to the upstream; routes begin as pending_review and go live on approval; and a provider token is required. This does not contradict the readOnly/idempotent/destructive hints.

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?

Four sentences, and each earns its place: purpose, payment behavior, moderation lifecycle, and authentication. The most decision-relevant information is front-loaded.

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?

Together with the rich schema and annotations, the description covers the core publish flow, auth requirement, and review state. The only notable omission is the purpose of the optional nested schema parameters, which prevents a perfect completeness score.

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 descriptions already cover 9 of 13 parameters, including defaults and examples, so the description does not need to repeat them. It reinforces the payment and upstream concepts but leaves the four undocumented optional fields (tags, description, input_schema, output_schema) unexplained.

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 names a specific action and resource: publish an API endpoint as a paid x402 route on the Apiosk gateway. It also distinguishes this from update/unpublish/test siblings by describing the create-and-submit lifecycle.

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 intended use is clear: you publish a new endpoint as a paid x402 route and it enters review; this context is enough for an agent to select it over read or mutation siblings. It does not explicitly name alternatives like update_x402_route, so it stops short of a 5.

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

Install Server