Apiosk MCP Server

Overview Schema Source Related Servers Score Discussions Admin

apiosk_discover

Read-onlyIdempotent

Find paid x402 APIs for any data capability across multiple discovery sources. Returns a normalized, ranked list with execution instructions, turning a data need into a payable API call.

Instructions

Find the best paid x402 API for a data capability across discovery sources (Apiosk catalog + federated external listings). Decompose the user's request into capability segments first, then call this once per capability. Returns a normalized, ranked list; each result's executable_via says whether to call apiosk_execute (Apiosk-settled) or apiosk_inspect_x402 + apiosk_fetch_paid (external). Use this instead of apiosk_search when the goal is 'get real paid data for X', not just browsing.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	Yes	The data capability to find, e.g. 'realtime USD exchange rate' or 'company registry lookup by domain'.
`sources`	No	Discovery sources to query. Default ['apiosk','bazaar']. Use ['all'] for every directly wired free REST source. Paid sources 'x402scan' and 'apify' are opt-in and return their payable endpoint for apiosk_inspect_x402 + apiosk_fetch_paid; discovery never spends automatically. Add 'wellknown' with probe_hosts for a specific host.
`segments`	No	Optional: the user's request pre-decomposed into distinct data capabilities. Each is searched and merged.
`max_results`	No	Maximum results to return (default 8, max 25).
`probe_hosts`	No	For the 'wellknown' source: explicit hostnames to probe for a /.well-known/x402 document (e.g. 'x402.example.com'). No speculative crawling — only hosts you name here are probed.
`max_price_usdc`	No	Optional per-call price ceiling in USDC. Results above this are dropped.

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.7/5.0

Behavior5/5

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

Annotations already mark read-only/idempotent/non-destructive, and the description goes further: discovery never spends automatically, paid sources are opt-in, and wellknown probing is limited to named probe_hosts with no speculative crawling. This adds safety and side-effect transparency beyond annotations.

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 with no filler: capability discovery, decomposition instruction, return/routing behavior, and alternative choice. Front-loads the core purpose; every sentence carries distinct information.

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 a full output schema and complete schema parameter descriptions, the description covers the workflow, alternatives, safety behavior, and downstream routing. Nothing necessary for correct invocation is missing.

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 cover 100% of parameters (query, sources, segments, max_results, probe_hosts, max_price_usdc), so the description doesn't need to explain them; it adds only workflow context around segments and routing. Baseline 3 applies.

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 ('Find'), a precise object ('best paid x402 API for a data capability'), and explicitly differentiates from apiosk_search with a concrete condition. It also identifies the discovery sources and outcome (normalized ranked list). The distinction from siblings is clear.

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 instructs to decompose request into capability segments and call once per capability; names alternative apiosk_search and states when to use this instead ('get real paid data for X' vs browsing). It also explains routing via executable_via to downstream tools, which is actionable selection guidance.

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

Install Server