Skip to main content
Glama

Apiosk Connect

by io.github.obcraft

Apiosk compare

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, with provider labels the user can choose by name. 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
NameRequiredDescriptionDefault
queryNoWhat 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).
capabilityNoA capability slug, to price every provider of one task directly, skipping the search.
settlementNo'apiosk' keeps only listings Apiosk proxies and settles; 'direct' keeps only federated listings you pay the provider for yourself.
optimize_forNoWhich 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_msNoHard 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_usdcNoHard per-call price ceiling. Candidates above it are rejected, and each rejection says so.
min_reliabilityNoHard floor on measured success rate. Accepts 0..1 or 0..100. An unmeasured provider is rejected rather than assumed to meet it.
require_all_inputsNoReject any candidate that does not accept every input in the capability's contract.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / max_price_usdc / description
      Previous value: -"Hard per-call price ceiling in USDC. Candidates above it are rejected, and each rejection says so."New value: +"Hard per-call price ceiling. Candidates above it are rejected, and each rejection says so."
  2. Changed2 schema fields changed
    • removedInput schema / properties / candidates
      Removed value: -{
-  "description": "Advanced: Apiosk candidate ids (UUIDs) as issued by GET /v1/discover on the gateway over plain HTTP. Passing them makes the set you compared provably the set you discovered. Ids from the apiosk_discover TOOL are a different namespace and are rejected — use `query` instead. External x402 hits never carry an id, because there is no measurement or input mapping to score them on.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
    • changedInput schema / properties / capability / description
      Previous value: -"A capability slug, to work over every provider of one task directly."New value: +"A capability slug, to price every provider of one task directly, skipping the search."
  3. Changed2 schema fields changed
    • removedOutput schema / description
      Removed value: -"Structured JSON result of the tool call. Mirrors the human-readable text content; the exact fields depend on the tool (an `error` field is present when the call fails)."
    • addedOutput schema / properties
      Added value: +{}
  4. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses that unmeasured dimensions come back null rather than a plausible default, and unmeasured providers are rejected from latency/reliability filtering rather than assumed to comply. It also clarifies the offer_id vs offer_token split and explicitly states it spends nothing.

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?

Although longer than many tool descriptions, each sentence adds a distinct operational detail: output shape, ID/token split, transparency rows, chaining, null behavior, and cost safety. The opening sentence front-loads the main result, and there is no filler.

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 an 8-parameter tool with a full output schema and read-only annotations, the description covers the workflow position, output format, candidate filtering behavior, and cost safety. Nothing necessary for correct invocation or interpretation 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?

The input schema already describes all 8 parameters with 100% coverage, so the tool description does not need to repeat them. It reinforces the chaining requirement with 'same plain-words query', but adds little parameter-level meaning beyond what the schema already provides.

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 opens with a concrete outcome — 'Turn a job into priced offers you can act on' — and enumerates the core outputs: price per call, 0-100 score, measured p95 latency, and measured success rate. It frames itself as the comparison step after apiosk_discover, distinguishing it from sibling search/discovery tools.

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?

It explicitly says to chain it after apiosk_discover by passing the same plain-words query, and notes that execution still happens via the offer_token from discover — positioning compare as the non-executing middle step. It also gives an alternate entry path through capability slug, skipping the search, which clarifies when each usage mode applies.

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

All Apiosk Connect toolsInspect
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.6/5.0
Disambiguation5/5

Each tool maps to a clear stage in the workflow: discovery, comparison, offer selection, execution, approval polling, plan creation, plan execution, job status, resolution, and cancellation. Even the discovery-stage tools (discover, compare, apiosk) are explicitly chained so an agent can tell them apart by purpose and output.

Naming Consistency4/5

Most tools follow a consistent apiosk_ prefix with snake_case and verb-led names like apiosk_discover, apiosk_execute, and apiosk_cancel_job. The bare apiosk tool and noun-style status tools (job_status, approval_status) are minor deviations from an otherwise predictable pattern.

Tool Count5/5

Eleven tools is well within the ideal range and each tool earns its place by covering a distinct user or agent action in the buying, planning, executing, and job-management lifecycle. There is no redundancy or padding.

Completeness5/5

The surface covers the full lifecycle: connect, discover, compare, quote, approve, execute single calls, create plans, execute plans, monitor jobs, resolve ambiguities, and cancel running jobs. There are no obvious dead ends or missing required operations for the stated purpose.

Resources