Apiosk MCP

Compare the candidates on price and measured performance

apiosk_compare

Read-onlyIdempotent

Turn a job into priced offers you can act on: price per call, a 0-100 score, measured p95 latency and measured success rate, side by side. The result comes back with a finished table in presentation to print as-is, numbered so the user can answer with a number. The Apiosk offers include offer_id for quote reconciliation, but execution still happens via the offer_token you keep from apiosk_discover. The reviewed Apiosk offers come back beside the live x402 endpoints the gateway swept from the wider ecosystem for the same job — those rows are there for transparency and ranking context. Chain it after apiosk_discover by passing the same plain-words query. Dimensions Apiosk has not measured come back null, never a plausible default. Reads only; spends nothing.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	No	What you need, in plain words — the SAME words you gave apiosk_discover. This is how the chain works over MCP: pass the query forward, not the ids from apiosk_discover (those name results across every source it searched and are not the Apiosk catalogue's candidate ids).
`capability`	No	A capability slug, to price every provider of one task directly, skipping the search.
`settlement`	No	'apiosk' keeps only listings Apiosk proxies and settles; 'direct' keeps only federated listings you pay the provider for yourself.
`optimize_for`	No	Which dimension the weighting favours. Default 'price'. Choosing latency or reliability also sorts measured candidates above unmeasured ones, because an unmeasured provider cannot win a race it never ran.
`max_latency_ms`	No	Hard ceiling on measured p95 latency, in milliseconds. Judged on the tail rather than the median, because a ceiling is a promise about the slow case: a provider with a fast median and a long tail still blows your timeout one request in twenty. A provider Apiosk has never proxied is rejected rather than assumed to meet it.
`max_price_usdc`	No	Hard per-call price ceiling. Candidates above it are rejected, and each rejection says so.
`min_reliability`	No	Hard floor on measured success rate. Accepts 0..1 or 0..100. An unmeasured provider is rejected rather than assumed to meet it.
`require_all_inputs`	No	Reject any candidate that does not accept every input in the capability's contract.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Reads only; spends nothing' reinforces them without contradiction. Beyond annotations, it discloses the numbered `presentation` table format, the offer_id-vs-offer_token distinction, the mixed Apiosk/ecosystem result composition, and the 'null, never a plausible default' policy for unmeasured dimensions — substantial added context.

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?

One dense paragraph where nearly every sentence earns its place: purpose, output format, token semantics, result composition, chaining, null policy, safety. It is front-loaded with the core purpose, though it is slightly redundant with the query parameter's own chaining note and packs many distinct ideas without structural breaks.

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?

The tool has an output schema, so return-value detail is already covered elsewhere. Combined with rich annotations and 100% schema coverage, the description fills the remaining gaps an agent needs: workflow position after apiosk_discover, presentation-table output, and the null-handling policy. Nothing required for correct invocation appears missing.

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 description coverage is 100%, so the baseline is 3, and the schema's own parameter descriptions are rich (defaults, enum semantics, unmeasured-provider rejection for each filter). The tool description adds cross-cutting meaning: it instructs reusing the exact query from apiosk_discover and clarifies how offer_id (reconciliation) and offer_token (execution) relate to the quote flow, going beyond what the schema states.

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 action and scope: 'Turn a job into priced offers' with concrete comparison dimensions (price per call, 0-100 score, measured p95 latency, measured success rate). It also positions itself in the workflow — 'Chain it after apiosk_discover' — which distinguishes it from the sibling discover/execute tools without needing to open their schemas.

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?

Explicitly instructs when to call it: 'Chain it after apiosk_discover by passing the same plain-words query.' It clarifies execution is not this tool's job — 'execution still happens via the offer_token you keep from apiosk_discover' — which implies apiosk_execute is the follow-up. It stops short of explicitly naming alternative tools or stating when-not-to-use, so it misses the top bar.

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

All Apiosk MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation3/5

discover, compare, and the bare apiosk tool all take a plain-words job and return offers or prices, so an agent could easily pick the wrong one at the start. The descriptions clarify that discover is the initial sweep, compare is the side-by-side follow-up, and apiosk is a single-best-offer shortcut, but the boundaries are not immediately obvious from names alone.

Naming Consistency4/5

Most tools follow an apiosk_<verb> pattern such as discover, compare, execute, and connect, and all names are lowercase snake_case. The bare apiosk tool and the noun-style apiosk_approval_status are minor deviations from the otherwise consistent scheme.

Tool Count5/5

Six tools map cleanly to the paid-API purchase lifecycle: connect, discover, compare, execute, approval status, plus a single-best-offer shortcut. The count is well-scoped for the server's purpose and each tool has a distinct role in the workflow.

Completeness5/5

The workflow is covered end to end: account status, discovery, price comparison, execution, approval polling, and payment-retry guidance. There are no obvious dead ends or missing lifecycle operations for making and completing a paid API call.

Resources

Need Help?