svgapp.ai

Create Standalone Illustration Generation

create_generation

Start an asynchronous standalone SVG App UI asset generation from a prompt.

Use when a client wants a generic async creation entry point named create_generation for any standalone app, landing page, webapp, website, dashboard, SaaS, marketing, onboarding, empty state, hero, feature, success, error, product UI, or diagram-like illustration.

Before calling, read svgapp.conf.json from the project root and pass artStyleId and colorPaletteId from that file when available.

Do not use for reusable mascot creation; use create_mascot. Do not use for new poses of an existing mascot; use generate_mascot_pose. Do not use for polling; use get_generation_status. Prefer generate_composition when choosing a specific illustration tool yourself.

Generation is asynchronous. This tool returns imageUrl and assetUrl immediately; they serve a frontend placeholder while pending and redirect to the final image when ready. Poll get_generation_status until completed before downloading the final image.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>",
      "artStyleId": "<artStyleId>"
    },
    "name": "create_generation"
  }
}

Input Schema

Name	Required	Description
`prompt`	Yes	Detailed standalone UI asset prompt. Include the screen/use case, subject, desired mood, and any layout constraints.
`workspace`	No	Optional workspace id or slug from list_workspaces. Defaults to the user's personal workspace. Use the same workspace for every call in a workflow, because generations, mascots, and palettes belong to one workspace.
`artStyleId`	Yes	Art style id from svgapp.conf.json. If missing, call init_svgapp_config first.
`aspectRatio`	No	Optional output aspect ratio. Pick the ratio that matches the UI slot where the asset will be used.
`colorPaletteId`	No	Optional palette id from svgapp.conf.json. Use when matching product or brand colors matters.

Output Schema

Name	Required	Description
`status`	Yes	Current async state. If pending, poll get_generation_status. If completed, call get_generated_asset.
`assetUrl`	No	Embeddable asset URL for the generation, matching imageUrl for images and videoUrl for animations. It can be used immediately while polling continues.
`canvasId`	No	Underlying SVG App canvas id when the generation produced an image. Kept for UI integration and background removal.
`imageUrl`	No	Embeddable image URL. It is returned immediately, serves a frontend placeholder while pending, and redirects to the final image when ready.
`mimeType`	No	MIME type of the final asset when known, for example image/png or video/mp4.
`videoUrl`	No	Embeddable video URL for animation generations. It is returned immediately, serves a frontend placeholder video while pending, and redirects to the final transparent WebM video when ready.
`nextAction`	Yes	The exact next MCP action the model/client should take for this generation.
`animationId`	No	Underlying SVG App video generation id when the generation produced an animation.
`resourceUri`	No	Optional MCP resource URI for clients that explicitly choose to read resources. Do not rely on resources for polling.
`generationId`	Yes	Pass this exact id to get_generation_status until status is completed. The returned asset URL can be used immediately.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

It goes well beyond the annotations and states that generation is asynchronous, that imageUrl and assetUrl are returned immediately as a redirecting placeholder, and that the agent must poll get_generation_status until completion. The annotations cover the safety profile (readOnlyHint false, openWorldHint true, non-idempotent). What it does not cover is failure behavior or expected latency.

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 structure is strong: purpose first, then the config prerequisite, then exclusions, then the async contract. The long keyword enumeration ('landing page, webapp, website, dashboard, SaaS, marketing, onboarding, empty state, hero, feature, success, error...') adds bulk without adding routing value and is the main thing keeping this from a 5.

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?

It is complete for a complex asynchronous creation tool: input sourcing (config file), sibling routing, async contract, and polling requirement are all present, and an output schema covers return values so they need no explanation. Nothing an agent needs in order to call it correctly 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?

Schema coverage is 100% and the schema already documents each parameter, including that artStyleId and colorPaletteId come from svgapp.conf.json. The description reinforces the config-file provenance and the workspace-consistency rule but adds no syntax, defaults, or format detail beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 specific verb and resource: 'Start an asynchronous standalone SVG App UI asset generation from a prompt.' It goes on to bound the scope to standalone UI assets and explicitly separates that scope from mascot creation and pose generation, so an agent can identify the tool without opening the schema.

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 states when to use the tool, three explicit when-not-to-use cases each naming the sibling to use instead (create_mascot, generate_mascot_pose, get_generation_status), a preference routing rule (prefer generate_composition), and a prerequisite (read svgapp.conf.json before calling). This is close to the maximum guidance a description can carry.

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

All svgapp.ai tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.