Skip to main content
Glama
tong0619453646-dev

APIKO MCP

by tong0619453646-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Generate or edit an image (billable)

generate_image

Creates an approved, paid image generation or edit task using a selected model and budget, returning a task to poll when async.

Instructions

BILLABLE: creates a paid image task charged to the user's APIKO balance. Only call after estimate_cost on the same input and the user's explicit approval of the model and cost. With reference images in input.images it edits (POST /v1/images/edits), otherwise it generates. The input is validated against the model schema first. Runs async when the model supports it and waits up to wait_seconds; if not done, poll with get_task. Never call again to check progress.

Input Schema

NameRequiredDescriptionDefault
inputNoModel request fields exactly as listed in get_model input_schema (e.g. {"prompt": "...", "resolution": "2k"}). Leave out model and async.
modelYesExact image model id.
promptNoShortcut for input.prompt; give the prompt once.
max_cost_usdNoBudget the user approved; the call is refused if the estimate (or its upper bound) is higher or cannot be computed.
wait_secondsNoSeconds to wait for the result (default 30).
client_request_idNoYour id for this one approved request (8-96 chars of letters, digits, . _ -). Reusing it with the same input returns the earlier task instead of charging twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations give readOnlyHint=false and openWorldHint=true, but the description adds the crucial non-obvious traits: it is billable against the user's balance, input is validated against the model schema before any charge, execution is async with a bounded wait, and re-invocation is not the progress-check path. These are behaviors an agent could not infer from the annotations.

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?

The billing warning is front-loaded and every sentence carries an operative rule, but the paragraph is dense and stacks approval, routing, validation, async, and polling rules into one block. Slight structural cost, no wasted content.

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 a billable, async, branchy tool with six parameters, nested input, no output schema, and non-idempotent annotations, the description covers the spend guardrails, execution mode, wait/poll handoff, and duplicate-charge avoidance. Nothing an agent needs in order to call it safely is 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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema only implies: input.images as the switch that routes to the edit endpoint, and wait_seconds as the boundary after which the agent must switch to get_task. The billing implications of model and max_cost_usd are reinforced by the 'approved model and cost' precondition.

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+resource (creates a paid image task) and further specifies the two modes: edit when input.images is present, generate otherwise, with the underlying endpoints named. This separates it cleanly from estimate_cost, get_task, and generate_video in the sibling list.

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?

Explicit preconditions (call only after estimate_cost on the same input and explicit user approval of model and cost), explicit edit-vs-generate branch, and an explicit exclusion: 'Never call again to check progress' with get_task named as the polling alternative.

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

Deploy Server

Other Tools