Skip to main content
Glama

Apiosk Connect

by io.github.obcraft

Apiosk plan

apiosk_plan

Turn a research goal that needs several API calls into ONE plan with ONE price ceiling: the steps in the order they run, which of them the plan can and cannot reach, and a signed plan_token that authorises exactly this version. Use it when the answer needs more than one call — a lookup whose result feeds a second call, or several facts about the same company — and use apiosk_discover plus apiosk_execute when a single call will do. Pass the user's question directly; the Gateway shares the App's reader and asks for missing context. Supply intent only when you already have a structured goal with known subjects and required fact types. The gateway compiles it, shares a lookup two branches both need instead of buying it twice, and prices the whole plan once. Where this host can ask, the user is shown the plan and its one price and answers Approve or Deny here; read that answer instead of asking again. Nothing is reserved and nothing is called: this tool spends nothing, and only apiosk_execute_plan starts the work.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intentNoThe goal as the gateway plans in: what the answer is about, and which facts it must contain. Passed through untouched.
questionYesThe goal in the user's own words, including the company and information needed. The Gateway interprets it when intent is omitted and asks for missing context.
max_price_usdcNoOptional hard ceiling on the plan's total. A plan above it is refused with its price rather than quietly trimmed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed2 schema fields changed
    • changedInput schema / properties / question / description
      Previous value: -"The goal in the user's own words. Shown on the plan card and recorded with the approval; the compiler never reads it."New value: +"The goal in the user's own words, including the company and information needed. The Gateway interprets it when intent is omitted and asks for missing context."
    • changedInput schema / required
      Previous value: -[
-  "question",
-  "intent"
-]New value: +[
+  "question"
+]
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that nothing is reserved or called, that only apiosk_execute_plan starts the work, that the gateway may share lookups between branches to avoid double-buying, and that the user is shown the plan for approval. This goes well beyond the readOnlyHint/openWorldHint annotations and gives the agent accurate expectations about side effects and flow.

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?

The description is long but every sentence carries operational value: purpose, when-to-use, parameter selection, gateway behavior, approval flow, and cost guarantee. It is front-loaded with the core definition and then logically expands into usage and behavioral caveats without 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?

Given the nested schema, output schema presence, and ten sibling tools, this description is complete enough. It explains what the tool returns conceptually (a plan, reachability, signed token), how the user interacts, what happens with missing context, and what the tool does not do. An agent has enough context to select and invoke it correctly.

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?

The schema covers all parameters in detail, so the baseline is 3, but the description adds meaningful guidance on when to pass `question` directly versus when to supply `intent`, and explains how missing context is handled. It doesn't discuss `max_price_usdc`, but the schema already documents that parameter fully.

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 states a specific verb ('Turn a research goal... into ONE plan') and a clear resource (a plan with steps, reachability, and a signed plan_token). It also distinguishes itself from apiosk_discover and apiosk_execute, so an agent can tell exactly what this tool does even among many siblings.

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 when to use this tool ('when the answer needs more than one call'), when not to ('use apiosk_discover plus apiosk_execute when a single call will do'), and when to supply intent vs question. It even instructs the agent to read the approval answer instead of asking again, which is precise operational guidance.

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