Generate AI images and videos from 89 models on one credit balance, refunds on failure.
Scored across 4 tools
Each tool targets a distinct action: image generation, video generation, status polling, and model listing. There is no meaningful overlap despite generate_image and generate_video sharing a prefix.
All tool names follow a consistent verb_noun snake_case pattern: generate_image, generate_video, get_generation_status, list_models. The naming style is uniform and predictable.
Four tools is well-scoped for a focused media generation server: two generation entry points, one status poller, and one model catalog. No tool is redundant and the count feels appropriately lean.
The set covers the essential lifecycle: discover models, launch image or video generation, and retrieve results or status. Nothing critical is missing for the advertised domain, and the async video workflow is supported by the status endpoint.
Generate an image from a text prompt (optionally with input images for editing or reference). Waits for the result and returns the image URL. Costs credits from the connected Imaginode account; failures are refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model key from list_models (kind image). Default: nano-banana-2. | |
| prompt | Yes | What to generate, in natural language. English works best. | |
| image_urls | No | Optional input image URLs (editing or reference). Must be media hosted on the Imaginode account (Firebase Storage URLs from the media library or previous generations). | |
| aspect_ratio | No | Optional aspect ratio like 16:9, 1:1, 9:16. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It covers synchronous waiting, URL return, credit cost, and refund on failure, which are important operational facts not present in the schema. It could go further on error behavior or storage side effects, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose, then add synchronous behavior, output format, and cost/refund policy. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, 1-required tool with no annotations and no output schema, the description is complete: it states what to provide, that it blocks for the result, what it returns, and the credit consequence. The schema covers parameter details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema: 'text prompt' and 'input images for editing or reference' largely restate the existing parameter descriptions. It does not introduce new semantic detail about model, aspect ratio, or URL constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: generate an image from a text prompt, optionally with input images. This clearly distinguishes it from sibling generate_video and aligns with the image-specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use for text-to-image generation and image editing/reference, and it states that the tool waits for the result, implying no need to poll get_generation_status. It does not explicitly name generate_video as the video alternative, so it stops short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a video generation from a text prompt (optionally with a start image). Returns immediately with a request_id and the cost in credits: poll get_generation_status every 30 seconds until it completes (typically 1 to 5 minutes, up to 30 for long jobs). Failures are refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| audio | No | Generate audio, for models that support it. | |
| model | No | Model key from list_models (kind video). Default: seedance-2. | |
| prompt | Yes | What to generate, in natural language. English works best. | |
| duration | No | Duration in seconds, among the model's durations (see list_models). | |
| image_url | No | Optional start image URL (image-to-video). Must be media hosted on the Imaginode account (Firebase Storage URL from the media library or a previous generation). | |
| resolution | No | Resolution among the model's resolutions (see list_models). | |
| aspect_ratio | No | Aspect ratio like 16:9 or 9:16 (text-to-video only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it discloses that the call returns immediately, is asynchronous, costs credits, requires polling, has typical and maximum durations, and that failures are refunded. This gives the agent a realistic model of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core action, response shape, polling instruction, expected latency, and failure policy. Every sentence earns its place and no unnecessary detail is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the crucial async flow and what the agent receives in return, which is especially valuable given there is no output schema. However, it does not explicitly guide the agent to list_models for choosing valid model, resolution, or duration options, so a small gap remains for non-default invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description only adds light context around prompt and image_url via 'text prompt' and 'optionally with a start image', but that is consistent with the baseline expectation for fully-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Start a video generation'), the input ('text prompt, optionally with a start image'), and the immediate result (request_id and credit cost). It clearly distinguishes this from image generation and status polling at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to poll get_generation_status every 30 seconds and gives expected completion time, which is strong usage context. It does not explicitly contrast with generate_image or list_models, but the video-generation purpose is clear enough that the usage context is not ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a generation started with generate_video (or a generate_image that timed out). Returns running, completed (with output URLs) or failed (refunded).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request_id returned by the generate tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does well by revealing the three possible states: running, completed (with output URLs), and failed (refunded). This communicates key behavioral outcomes beyond a simple 'check status' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence establishes what the tool does, and the second sentence efficiently enumerates the possible return states without any filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter status tool, the description covers the core behavior and return states well, especially given there is no output schema. It could optionally mention polling behavior or error cases, but the essential information an agent needs to invoke and interpret results is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that request_id is returned by the generate tool. The description adds slight extra context by linking the parameter to generate_video and generate_image, but it does not significantly extend the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking the status of a generation. It specifies exactly which generations are relevant (generate_video or a timed-out generate_image), and this clearly differentiates it from siblings like generate_image and generate_video, which start generations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context: after starting a generation with generate_video or after a timed-out generate_image. It does not explicitly mention when not to use it relative to list_models, but the contrast with generation-starting siblings is apparent and sufficient for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available AI models with their kind (image, video), default cost in credits (1 credit = $0.012, or €0.01 when billed in euros) and billable options. Call this before generating if you need a specific model, otherwise sensible defaults are used.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only return models of this kind. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the returned information—model kind, cost in credits, billable options—and adds the credit-to-currency conversion. Listing is inherently read-only, so no destructive side effects are expected, and the description supports that understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the tool's purpose and output, and the second provides actionable usage guidance. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description provides sufficient context: what is listed, the meaning of cost, and when to invoke it. No critical information appears missing for an agent to decide whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is optional and fully described in the schema with an enum of 'image' and 'video'. The description mentions kind but adds little beyond the schema's parameter description. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (List), a clear resource (available AI models), and the key output fields (kind, default cost in credits, billable options). This clearly distinguishes it from sibling tools like generate_image, generate_video, and get_generation_status, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call this tool: before generating if a specific model is needed, otherwise defaults are used. It does not name sibling tools as alternatives, but the conditional guidance is clear enough to guide selection without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_imagegenerate_videoget_generation_statuslist_modelsGenerate text, images, speech, music, and video with any AI model, from one credit balance.
Image, video, audio, face-swap, talking avatars and chat across 300+ AI models, one balance.
Generate image, video, audio, 3D and vector media with 100+ AI models. Pay per generation.
Make AI videos and images from a description, on one credit balance. Sign in to generate.
Add one secure layer between your agents and this server.
