svgapp.ai

Generate Mascot Pose

generate_mascot_pose

Generate a new pose, emotion, action, or UI state for the active SVG App mascot while preserving mascot continuity.

Use when the user wants the SAME reusable mascot/character to appear in another pose, such as waving, confused, celebrating, pointing, sleeping, holding a sign, holding an object, explaining a feature, empty state, error state, onboarding state, success state, loading state, or account setup state.

Before calling, read svgapp.conf.json from the project root and use activeMascotId as mascotId when available.

Mascots are useful in UIs when a screen needs warmth, guidance, personality, or state-specific feedback: onboarding, empty states, 404/error pages, success confirmations, feature announcements, docs/help panels, upgrade prompts, and friendly dashboard moments. Use a specific pose that matches the screen's job rather than dropping in the neutral base mascot.

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. If the final image needs to sit on arbitrary UI backgrounds, call remove_image_background after completion.

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": {
      "mascotId": "<mascotId>",
      "prompt": "<prompt>",
      "name": "<name>"
    },
    "name": "generate_mascot_pose"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Short pose name for the library, for example 'Empty Search State' or 'Celebrating Deployment'.
`prompt`	Yes	Describe the exact pose/action/emotion/UI state. Include screen context and any object the mascot should interact with, for example 'holding a magnifying glass over an empty search result panel, curious but upbeat'.
`mascotId`	Yes	The mascot id to preserve. Usually use activeMascotId from svgapp.conf.json. If missing, call list_mascots or create_mascot first.
`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.

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.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) by disclosing that generation is asynchronous, that imageUrl/assetUrl are placeholders that redirect later, and that get_generation_status must be polled before download. It also flags the remove_image_background follow-up step for arbitrary UI backgrounds — exactly the operational detail an agent needs.

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?

Front-loaded with purpose and trigger, then prerequisites, then async behavior — a sensible order. The paragraph cataloguing UI contexts (warmth, onboarding, 404, upgrade prompts, dashboard moments) is somewhat expansive and partly overlaps the pose examples, but it still earns its place as use-case guidance.

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?

Covers the full workflow an agent must follow for this async, non-idempotent generation tool: resolve mascotId, generate, poll status, then optionally remove background. With an output schema and annotations already present, nothing material is left unexplained.

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 description coverage is 100%, so all four parameters are already documented, including the activeMascotId guidance. The description largely restates the schema's mascotId advice rather than adding new syntax, formats, or constraints, so it sits at the baseline.

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 and resource ('Generate a new pose, emotion, action, or UI state for the active SVG App mascot') plus a scoping constraint ('preserving mascot continuity'). This clearly separates it from create_mascot (new character) and create_mascot_animation (motion) among the 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?

Explicitly names the trigger condition ('when the user wants the SAME reusable mascot/character to appear in another pose') and enumerates concrete pose/state examples. It also gives a prerequisite (read svgapp.conf.json, use activeMascotId) and alternatives to call when the id is missing (list_mascots or create_mascot).

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.