Ludo AI Game Assets
Server Details
Generate game assets with AI: sprites, 3D models, animations, sound effects, music, and voices.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Ludo-AI/ludo-mcp
- GitHub Stars
- 4
- Server Listing
- Ludo AI Game Assets
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 24 of 24 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: image generation, editing, style transfer, background removal; audio generation (sound effects, ambiance, music, speech, voice); sprite animation, pose, rotation, motion transfer; 3D model creation; video creation; plus separate history retrieval tools and API validation. No two tools overlap in functionality.
The majority of tools follow a clear verb_noun pattern (e.g., createImage, editImage, removeBackground, generatePose). A few tools break the pattern, such as 'validateApiKeyEndpoint' (camelCase, noun-heavy) and 'listAnimationPresets' (verb_noun but with plural noun). Overall consistent with minor deviations.
With 24 tools, the count is on the high side but still appropriate for a comprehensive game asset generation server covering images, sprites, 3D, audio, video, and history retrieval. Each tool serves a distinct need, though the set could potentially be trimmed (e.g., merging some get*Results into a single endpoint).
The server offers a broad range of creation and manipulation tools for game assets. Notable gaps include the lack of an audio mixing/combining tool, no tool for editing 3D models after creation, and no bulk processing. However, the core generation and basic editing workflows are well covered, with history lookup and validation included.
Available Tools
24 toolsanimateSpriteAInspect
Animate a static sprite into a spritesheet driven by a motion text prompt (image-to-spritesheet): supply an initial_image (URL or base64) plus a motion_prompt like "walking" or "attack slash", and optionally a final_image to interpolate between a start and end frame. Synchronous: the call blocks until the spritesheet is rendered and returns a single sprite result directly (spritesheet URL, frame layout, and optionally a GIF or individual frame URLs when requested) with no separate polling step. The chosen model must support sprite animation and the duration must be valid for it; incompatible model/duration combinations return HTTP 400. Credits are charged only on success, based on the produced duration and never more than the duration you requested. For best results, call generatePose first to put the character into the desired pose, then animate it here; use listAnimationPresets to discover named presets, and prefer transferMotion when you already have a reference video or preset to copy motion from rather than describing it in text. Pass an optional request_id to tag the result so you can locate it later via getSpriteResults. Requires an API key (user scope).
Credits: cost varies by model and duration (credits/sec): Blitz 1.9/s (min 4), Eagle 2.6/s (min 4), Eagle with Audio 3.1/s (min 4), Chaos 1.4/s (min 4); see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating an animated spritesheet from a static image. Input images can either be provided in base64 or URL. If the image was generated using Ludo, ideally it should be generated using the "sprite", "sprite-vfx" or "ui_asset" type. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: synchronous blocking call, credits charged only on success (never more than requested), error handling for incompatible model/duration, and ability to tag results with request_id for later retrieval via getSpriteResults. It also includes pricing details per model.
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 relatively long but well-structured: core purpose first, then details on synchronous behavior, pricing, sibling tool guidance, and parameter usage. Every sentence contributes meaningful information. Slight room for trimming, but not excessive for the complexity.
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?
Given no output schema and high complexity (nested object with many parameters), the description provides comprehensive context: input format, output details (spritesheet URL, frame layout, optional GIF/individual frames), pricing, error behavior, synchronous nature, and sibling tool relationships. It covers everything an agent needs to use the tool correctly.
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 schema has 100% description coverage, but the description adds extra semantic value: model quality ratings, legacy aliases (standard→blitz, new→chaos), explanation of frame_size special values (0, -1, -9), and usage tips for augment_prompt and crop. This goes beyond the schema's explanations.
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: animating a static sprite into a spritesheet using a motion text prompt. It specifies required inputs (initial_image and motion_prompt) and an optional final_image for interpolation. It distinguishes from siblings like generatePose and transferMotion, making the purpose unambiguous.
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 provides explicit guidance on when to use this tool versus alternatives: 'For best results, call generatePose first to put the character into the desired pose, then animate it here; use listAnimationPresets to discover named presets, and prefer transferMotion when you already have a reference video or preset to copy motion from.' It also notes synchronous behavior (no polling), API key requirement, and that incompatible model/duration returns HTTP 400.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create3DModelAInspect
Convert a single source image into a textured 3D model (image-to-3D). Synchronous: the call blocks while the mesh is generated, decompressed, and re-uploaded, then returns a downloadable GLB model_url plus an array of snapshot image URLs rendered from different angles (handy for previews). Accepts optional mesh controls: target_num_faces (max triangle count, 1000-200000, default 50000), texture_size (1024 or 2048, default 2048), and texture_type ("pbr", "simple", or "none", default "pbr"). Credits are charged only on success. Pass an optional request_id to tag the result so you can locate it later via get3DModelResults. Requires an API key (user scope).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden fully. It discloses synchronous blocking, output format (GLB url + snapshots), credit charging only on success, and API key requirement. Missing details like failure modes or rate limits, but adequate for a straightforward mutation tool.
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 about 100 words, well-structured with first sentence on purpose, then behavioral details, then parameters, then extras. It is front-loaded and efficient, though could be slightly more terse.
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?
No output schema is provided, but the description explains the return format (model_url + snapshot URLs) and mentions credit cost and request_id for tracking. This covers the essential context for an agent to use the tool, though error handling is omitted.
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 description reiterates parameter defaults and ranges, which are also in the schema, but adds context like the purpose of request_id and the exact credit cost per call. Since schema descriptions exist, the description adds moderate additional value.
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 converts a source image into a textured 3D model (image-to-3D), with specific verb and resource. It distinguishes itself from siblings like get3DModelResults by mentioning blocking behavior and output format, making purpose unambiguous.
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 explains the synchronous blocking behavior and credit charging, and suggests using request_id for later retrieval via get3DModelResults. However, it does not explicitly state when not to use this tool or contrast it with alternatives like createImage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createAmbianceAInspect
Produce a looping background ambiance soundscape from a text description, such as "windy forest at dusk" or "busy tavern interior". Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. The description field is required and duration is capped at 10 seconds (0 means auto-pick based on the description). Credits are charged on success. Use this for continuous, atmospheric background loops; use createSoundEffect for short discrete sound effects, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 2 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a seamless looping ambiance soundscape from a text description |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses synchronous execution (no polling), duration cap at 10 seconds, credits charged on success, API key requirement, and the return of a URL. No contradictions.
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?
Description is about 120 words, well-structured with a clear first sentence followed by relevant details. No fluff.
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?
No output schema, but description mentions returns 'a single audio result containing a URL'. Also covers credits and authentication. Complete for the context.
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%, but the description adds context: duration cap (10s), auto-pick for 0, use of request_id for retrieval. These details augment the schema descriptions.
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 verb 'Produce' and resource 'looping background ambiance soundscape from a text description'. It distinguishes from siblings by specifying 'Use this for continuous, atmospheric background loops; use createSoundEffect for short discrete sound effects, etc.'
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?
Explicitly provides when to use this tool and alternatives: 'Use this for continuous, atmospheric background loops; use createSoundEffect for short discrete sound effects, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample.' Also mentions synchronous nature and blocking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createAudioTransformAInspect
Remix an existing audio sample (a sound effect, ambiance, or music clip) into a variation guided by a text prompt, for example turning a track into an 80s synthwave or metal version. Both the sample and the prompt are required; the sample is uploaded as a URL or base64 audio and must be at most 15MB or the call returns HTTP 400, and duration must be one of the allowed values (0 means match the source, otherwise multiples of 10 up to 180 seconds). Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. The optional modification_strength (0 to 1, default 0.5) controls how far the result departs from the original. Credits are charged on success. Use this to transform existing audio you already have; use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for remixing an audio sample (sound effect, ambiance or music) into a variation guided by a text prompt |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses synchronous blocking behavior, credit charge on success, return format (single audio result with URL), scale of modification_strength, allowed durations, and error condition for size. No contradictions.
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?
Front-loaded with main purpose, every sentence adds value. Slightly long but information-dense and well-structured.
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?
Despite no output schema, explains return format (single audio result with URL), synchronous behavior, credit consumption, optional request_id for later retrieval, prerequisites (API key), and error condition. Comprehensive for a complex tool with nested parameters.
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 baseline is 3. The description adds contextual meaning: synchronous nature, credit cost, and clarifies duration constraint 'multiples of 10 up to 180 seconds'. However, for most parameters it repeats schema info without significant expansion.
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 verb (remix), resource (existing audio sample), and distinguishes from sibling tools by explicitly contrasting with createSoundEffect, createAmbiance, and createMusic which generate from scratch.
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?
Explicitly says when to use ('transform existing audio you already have') and when not ('use ... to generate audio from scratch'). Lists required elements, size limit, duration constraints, synchronous behavior, and credit consumption.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createImageAInspect
Generate game-art images from a text prompt alone, selecting an image_type (e.g. sprite) and optionally art_style, perspective, and aspect_ratio. Synchronous: the call blocks until generation finishes and returns an array of image results, each with a url; request n (1-8) to control how many variations come back. Because it generates purely from text it takes no source image, so there is no upload size limit to trip. Credits are charged only on success, scaled to the number of images produced. Use createImage to make new images from scratch; use generateWithStyle to match a reference image's art style, editImage to modify an existing image, and removeBackground to cut out a subject. Pass an optional request_id to tag the results so you can retrieve them later via getImageResults. Requires an API key (user scope).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating an image from text prompt |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses synchronous blocking, return format (array of image results with URLs), credit charging behavior (only on success, scaled by n), and the optional request_id for later retrieval. With no annotations, it covers major traits but omits failure behavior or rate limits, so not perfect.
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 well-structured, front-loaded with purpose, then behavior, sibling comparison, and cost. It is detailed but not overly verbose. Minor trim could improve conciseness, but it remains effective.
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?
Given the tool's complexity (many parameters, no output schema), the description covers most essentials: usage, return type, cost, synchronous nature, and sibling differentiation. It lacks error details but is otherwise comprehensive.
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?
With 100% schema coverage, the schema already documents parameters. The description adds value by explaining synchronous behavior, credit scaling with n, and the purpose of request_id (retrieval via getImageResults). This extra context moves it above baseline.
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 generates game-art images from a text prompt, specifying key parameters (image_type, art_style, perspective, aspect_ratio). It explicitly distinguishes itself from siblings like generateWithStyle and editImage, earning top marks.
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 offers explicit guidance on when to use createImage (make new images from scratch) versus alternatives (generateWithStyle, editImage, removeBackground). It also highlights a benefit (no upload size limit) and notes credit costs, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createMusicAInspect
Produce a piece of music from a text description, such as "epic orchestral battle theme" or "calm piano melody", with optional lyrics. Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. The description field is required; duration must be one of the allowed values (0 means auto, otherwise multiples of 10 up to 180 seconds) and out-of-range values return HTTP 400. Credits are charged on success. Use this for songs and musical scores; use createSoundEffect for short sound effects, createAmbiance for looping background soundscapes, and createAudioTransform to remix an existing audio sample. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating music from a text description |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses synchronous execution ('call blocks until generation finishes'), credit consumption (3 credits per call), error handling (out-of-range duration returns HTTP 400), and optional request_id tagging. No annotations provided, so description carries full burden and does so thoroughly.
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?
Well-structured: starts with purpose, then behavioral notes, sibling comparison, and credit cost. Each sentence adds information; no redundancy or fluff.
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?
Covers prerequisites, constraints, alternatives, synchronous behavior, credit cost, and hints at output (single audio result with URL). Lacks a full output schema, but mention of URL suffices for agent use.
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 covers all parameters with descriptions, but the tool description adds value by explaining duration constraints (multiples of 10 up to 180 seconds, 0 means auto) and that augment_prompt defaults to true. The description enriches the schema rather than repeating it.
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 it 'Produce a piece of music from a text description' and distinguishes from siblings by name and purpose, such as 'createSoundEffect' for short effects and 'createAmbiance' for looping backgrounds.
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?
Explicitly says 'Use this for songs and musical scores; use createSoundEffect for short sound effects, createAmbiance for looping background soundscapes, and createAudioTransform to remix an existing audio sample.' Also gives context about synchronous nature, credits, and API key requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createSoundEffectAInspect
Produce a short sound effect (SFX) from a text description, such as "laser gun firing" or "footsteps on gravel". Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. The description field is required, duration is capped at 10 seconds (0 means auto-pick based on the description), and you may set loop to true for a seamlessly looping effect. Credits are charged on success. Use this for short, discrete sounds; use createAmbiance for a continuous looping background soundscape, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 2 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a sound effect from a text description |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses synchronous blocking, credit consumption (2 credits), success charging, and optional request_id for later retrieval. No annotations provided, so description fully covers 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?
Well-structured, front-loaded with purpose, then behavior, usage, credits. Every sentence adds value without redundancy.
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?
Completes all aspects: purpose, behavior, usage, parameters, credits. No output schema but describes return value as audio URL. Sufficient for agent to use correctly.
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?
Adds context beyond schema: duration cap at 10s, loop for seamless looping, description required, augment_prompt togglable. Schema coverage 100% but description enhances understanding.
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 it produces a short sound effect from text, and distinguishes from siblings like createAmbiance, createMusic, and createAudioTransform.
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?
Explicitly states when to use this tool vs alternatives: 'Use this for short, discrete sounds; use createAmbiance for a continuous looping background soundscape, etc.' Also mentions synchronous behavior and API key requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createSpeechAInspect
Convert text to speech by cloning the voice from an audio sample you provide (voice-cloning text-to-speech). Both text and sample are required; the text is limited to 1000 characters and the sample is supplied as a URL or base64 audio that must be at most 15MB, with violations returning HTTP 400. Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. Credits are charged on success. Use this when you have a reference voice sample to clone; use createSpeechPreset to speak with a built-in named preset voice instead, and createVoice to design a brand-new voice from a text description rather than cloning one. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for text-to-speech generation using voice cloning |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes synchronous blocking behavior, credit consumption, error conditions (HTTP 400 for violations), and result URL retrieval. Since no annotations are provided, the description fully covers behavioral traits.
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?
Description is well-structured but slightly lengthy due to credits note and multiple constraints. However, it is front-loaded with main purpose and each sentence adds value. A minor trim could improve conciseness.
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?
Completely addresses all aspects: purpose, usage, behavior, parameters, alternatives, and return format. Without output schema, it correctly mentions returning a single audio result with URL. Sibling tools are listed and differentiated.
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?
Adds significant meaning beyond schema: explains text max length (1000 chars), sample format (URL or base64, ≤15MB), and request_id purpose for later retrieval via getAudioResults. Schema coverage is 100% but description provides extra constraints and usage context.
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 starts with a clear action 'Convert text to speech by cloning the voice from an audio sample', specifying the verb and resource. It distinguishes itself from siblings by naming createSpeechPreset and createVoice as alternatives with different use cases.
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?
Explicitly states when to use this tool (when you have a reference voice sample) and when to use alternatives (createSpeechPreset for built-in presets, createVoice for designing new voice from description). Also covers constraints like text length and sample size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createSpeechPresetAInspect
Convert text to speech using a named built-in preset voice, with optional emotion and language settings. Both text and voice_preset_id are required and the text is limited to 1000 characters; invalid input returns HTTP 400. Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. Credits are charged on success. Use this when you want a ready-made catalog voice and do not need to supply your own sample; use createSpeech to clone a voice from an audio sample instead, and createVoice to design a new voice from a text description. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for text-to-speech generation using a voice preset |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses synchronous blocking behavior, return of a URL, credit charge on success, and error response for invalid input (HTTP 400). No annotations provided, so description carries full burden and does so thoroughly.
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, front-loaded with purpose, and every sentence provides necessary information without redundancy. Two paragraphs efficiently cover all key aspects.
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?
Despite no output schema, description mentions return type (audio result with URL) and covers input, constraints, behavior, sibling distinctions, and credits. Could add more about URL format, but overall complete.
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 baseline is 3, but description adds value by explaining the request_id's purpose (tagging results for retrieval via getAudioResults) and reiterating constraints. This extra context justifies a 4.
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 converts text to speech using a built-in preset voice, with optional emotion and language settings, and distinguishes from sibling tools createSpeech and createVoice.
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 says when to use this tool versus alternatives: use createSpeechPreset for ready-made catalog voices, createSpeech for cloning from a sample, createVoice for designing from text. It also notes requirements and constraints (text limit, required params).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createVideoAInspect
Generate a short video clip from a source image and a motion text prompt (image-to-video). Synchronous: the call blocks until rendering finishes and returns the video URL and its actual duration in seconds — there is no separate polling step. Optionally pass final_image to interpolate between a start and end frame. The chosen model and duration must be compatible (incompatible combinations return HTTP 400); see the model and duration fields for the values each model accepts. Credits are charged only on success, based on the produced duration and never more than the duration you requested. Pass an optional request_id to tag the result so you can locate it later via getVideoResults. Related tools: use createImage for static images, animateSprite for sprite-sheet animation, and getVideoResults to list videos you generated earlier. Requires an API key (user scope).
Credits: cost varies by model and duration (credits/sec): Blitz 1/s, Eagle 1.3/s, Eagle with Audio 1.8/s, Chaos 0.6/s; see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a video from a source image and motion prompt |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: synchronous blocking, credit charges only on success, returned video URL and duration, error on incompatible combos (HTTP 400), and optional request_id tagging. No annotations are provided, so the description carries full burden and does so thoroughly.
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 well-structured with front-loaded purpose, followed by key behavioral details, optional parameters, credits, and related tools. It is slightly verbose but every sentence adds necessary context, earning a high score.
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?
Given the complexity (synchronous, credits, model-duration compatibility, multiple optional parameters) and the absence of an output schema, the description covers all essential aspects: how it works, what it returns, error conditions, pricing, and related tools. It is complete for an AI agent to use the tool correctly.
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 input schema already provides detailed descriptions for each parameter, achieving 100% schema coverage. The description adds value by explaining model-duration compatibility, credit costs per model, and the effect of final_image, which adds meaning beyond the schema.
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 explicitly states the tool's function as generating a short video clip from a source image and motion text prompt, and distinguishes it from related tools like createImage and animateSprite.
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 specifies synchronous behavior, model-duration compatibility, credit charging policy, and mentions alternatives (createImage, animateSprite, getVideoResults). It provides clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
createVoiceAInspect
Design a new voice from a character description (such as "deep-voiced warrior" or "cheerful young girl") and have it speak a short line of text, returning a sample of that newly created voice. Both voice_description and text are required, the spoken text is limited to 200 characters or the call returns HTTP 400, and type selects "human" or "non-human" voices. Synchronous: the call blocks until generation finishes and returns a single audio result containing a URL; there is no separate polling step. Credits are charged on success. Use this to invent and audition a voice from a description; use createSpeech for text-to-speech that clones a specific voice from an audio sample, and createSpeechPreset for text-to-speech using a named preset voice. Pass an optional request_id to tag the result so you can locate it later via getAudioResults. Requires an API key (user scope).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a voice sample from a character description |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses synchronous blocking, credit charge on success, HTTP 400 for text over 200 chars, type options, and API key requirement. Could mention idempotency or retry behavior, but overall thorough.
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?
Description is well-structured with front-loaded purpose and clear sibling differentiation. Every sentence adds value, though slightly lengthy. Could be trimmed by a few words without losing clarity.
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?
Covers all relevant aspects: purpose, parameters, return value (URL), error handling (400), synchronous nature, credits, API key requirement. No output schema but description compensates with return description. Sibling tools clearly differentiated.
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%, baseline 3. Description adds meaning by explaining each parameter's role: voice_description and text as required, text length limit, type values, request_id for tagging, and augment_prompt for control. Adds value beyond schema.
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?
Description explicitly states the tool creates a new voice from a character description and returns a sample. It clearly distinguishes from sibling tools by naming createSpeech and createSpeechPreset with specific use cases.
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?
Provides explicit guidance on when to use this tool versus alternatives: 'Use this to invent and audition a voice from a description; use createSpeech for...'. Also states required parameters, character limit, synchronous behavior, and credit consumption.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
editImageAInspect
Modify an existing image according to text instructions: supply a source image (URL or base64) and a prompt describing the changes (e.g. "add clouds", "warmer color scheme"), with an optional reference_image for extra style or content guidance. Synchronous: the call blocks and returns an array of image results, each with a url; request n (1-4) to control the number of edited variations. Provided images are uploaded and validated, and any image larger than 15MB is rejected with HTTP 400. Credits are charged only on success, scaled to the number of images produced. Use editImage to transform a specific existing image; use createImage to generate from text alone, generateWithStyle to borrow a reference's art style, and removeBackground for the dedicated background-removal case. Pass an optional request_id to tag the results so you can retrieve them later via getImageResults. Requires an API key (user scope).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for editing an existing image based on text instructions |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses key behavioral traits: synchronous blocking, image size limit (15MB), validation on upload, credit charging only on success, and a rate of 0.5 credits per result. It could improve by mentioning error types or retry behavior, but it is quite transparent for a tool with no annotations.
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 well-structured and front-loaded with the core purpose and usage. Every sentence adds value, but it is slightly longer than necessary. However, the information density is high and no statements are redundant.
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 all critical aspects: input format, output (array of images with urls), constraints (size limit), credit cost, optional request_id for retrieval, and clear differentiation from siblings. Given the complexity and lack of output schema, the description is sufficiently complete for an agent to use the tool correctly.
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?
Input schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of each parameter beyond schema descriptions, e.g., image can be URL or base64, prompt can include examples, n controls variations, reference_image for style, and request_id for retrieval. It also clarifies default values like n=1 and augment_prompt=true.
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 modifies an existing image based on text instructions, using a verb+resource pattern. It gives concrete examples of prompts and distinguishes from sibling tools like createImage, generateWithStyle, and removeBackground, ensuring the agent understands what this tool uniquely does.
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 explains when to use editImage versus alternatives: 'Use editImage to transform a specific existing image; use createImage to generate from text alone...' It also notes the synchronous blocking behavior, credit consumption, and prerequisites like API key scope, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generatePoseAInspect
Re-pose an existing sprite into a new target pose while preserving the character, taking a source image (URL or base64), a pose name (or "Other" with a free-text description), and an optional n (1-4) for how many variations to produce. Only works with sprite image types (not icons, screenshots, etc.). Synchronous: the call blocks and returns an array of pose results, each containing the generated image url, the pose and description used, and a suggested motion_prompt tuned for that pose. Credits are charged only on success, scaled by the number of images generated. This is typically the first step before animating: call generatePose to set the character's pose, then feed the result (and its suggested motion_prompt) into animateSprite for the best animation quality; use rotateSprite instead when you want to change the camera angle rather than the pose. Pass an optional request_id to tag the results so you can locate them later via getSpriteResults. Requires an API key (user scope).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a new pose for an existing sprite |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States it is synchronous, blocks, charges credits only on success, and requires API key. No annotations provided, but description covers key behavioral traits.
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?
Single concise paragraph with all essential info, front-loaded with purpose. Could be slightly more structured, but effective.
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?
Covers usage flow, constraints, credit cost, relationship to siblings, and return format. No output schema, but description sufficiently outlines what is returned.
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%, but description adds context like request_id for tagging, credit cost per result, and flow guidance, adding value beyond schema.
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 re-poses an existing sprite while preserving character, distinguishes from siblings by referencing animateSprite and rotateSprite.
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?
Explicitly says when to use (before animating) and when not (use rotateSprite for camera angle), and notes limitations (only sprite images, not icons).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generateWithStyleAInspect
Generate new images that match the visual style of a reference image: supply a style_image (URL or base64) plus a text prompt describing what to create and an image_type (defaults to sprite). Synchronous: the call blocks and returns an array of image results, each with a url; request n (1-4) to control the number of variations. The style_image is uploaded and validated, and an image larger than 15MB is rejected with HTTP 400. Credits are charged only on success, scaled to the number of images produced. Use this instead of createImage when style consistency with an existing asset matters; use editImage to alter the content of a specific image rather than borrow its style, and removeBackground to isolate a subject. Pass an optional request_id to tag the results so you can retrieve them later via getImageResults. Requires an API key (user scope).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating new content while maintaining the visual style of a reference image |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description covers synchronous blocking behavior, return format (array with url), n variations (1-4), style image validation including 15MB limit, credit charging (0.5 per result) only on success, and API key requirement (user scope).
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 comprehensive and well-structured, front-loading the core purpose. While slightly verbose, every sentence adds value and unnecessary words are minimal.
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?
Despite no output schema, the description covers return format, credit cost, validation, synchronous nature, and references getImageResults for retrieval. Given tool complexity and sibling context, it is fully complete.
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% with clear descriptions for each parameter. The tool-level description adds overall context but does not significantly enhance individual parameter semantics beyond the schema. Baseline 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 clearly states the tool generates new images matching a reference image's style using style_image and prompt. It explicitly distinguishes from siblings createImage, editImage, and removeBackground.
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 provides explicit when-to-use guidance: use instead of createImage when style consistency matters, use editImage for content alteration, removeBackground for subject isolation. It also mentions optional request_id for retrieval via getImageResults.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get3DModelResultsAInspect
List 3D models you previously generated through the API, most recent first. This is a free read-only history lookup (no credits, no generation); it does not create anything. Pass an optional request_id query parameter to return only the results tagged with that id when you originally called create3DModel. Requires an API key (user scope).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Filter results by request_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States read-only, free, no generation, most recent first ordering. Does not mention rate limits or pagination, but for a simple list operation this is sufficient.
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 short sentences, each providing essential information: purpose, behavioral note, parameter usage. No wasted words.
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?
Given one optional parameter and no output schema, description fully explains tool behavior and usage. Sibling list includes many creation tools, making the read-only distinction valuable.
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 describes request_id as 'Filter results by request_id' (100% coverage). Description adds context that results are tagged with that id from create3DModel call, adding meaning beyond schema.
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?
Description clearly states 'List 3D models you previously generated through the API, most recent first.' It specifies the verb (List), resource (3D models), and scope (most recent first). Distinct from sibling creation tools like create3DModel.
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?
Explicitly says it is a read-only history lookup, free, and does not generate. Requires API key. Mentions optional request_id for filtering. Lacks explicit when-not-to-use compared to create3DModel, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getAudioResultsAInspect
List audio clips you previously generated through the API, most recent first. This is a free read-only history lookup (no credits, no generation); it does not create anything. Pass an optional request_id query parameter to return only the results tagged with that id when you originally called createSoundEffect, createAmbiance, createMusic, createAudioTransform, createVoice, createSpeech, or createSpeechPreset. Requires an API key (user scope).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Filter results by request_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read-only nature, no credit cost, ordering (most recent first), and filter capability. No annotations provided, so description covers essential behavioral traits. Could add pagination info, but sufficient for simple list tool.
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, front-loaded with main purpose, then details. No fluff, every sentence adds value. Efficiently structured.
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?
Complete for a simple list tool with one optional parameter and no output schema. Covers what is listed, order, filter, and authentication. No missing pieces.
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% with one parameter. The description adds value by explaining that request_id refers to the id from creation calls (createSoundEffect, etc.), going beyond the schema's generic description.
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?
Clearly states it lists previously generated audio clips, most recent first. Identifies the resource (audio clips) and action (list). Differentiates from creation tools by noting it's a read-only history lookup.
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?
Explains that it's a free read-only operation (no credits, no generation) and describes the optional request_id filter with specific creation tool names. Mentions API key requirement. Lacks explicit comparison to sibling 'get*' tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getImageResultsAInspect
List images you previously generated through the API, most recent first. This is a free read-only history lookup (no credits, no generation); it does not create anything. Pass an optional request_id query parameter to return only the results tagged with that id when you originally called createImage, editImage, generateWithStyle, generatePose, rotateSprite, or removeBackground. Requires an API key (user scope).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Filter results by request_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully bears the burden and clearly states it is read-only, free, does not create anything, and requires an API key with user scope. It does not mention pagination or limits, but that is acceptable for a simple list endpoint.
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: first states purpose, second emphasizes read-only nature, third explains the optional parameter. No wasted words.
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?
Given no output schema and one optional parameter, the description covers the core functionality. It could mention return format or pagination, but the simplicity of the tool makes it adequate.
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 description adds significant value beyond the schema's 'Filter results by request_id' by explaining that the parameter returns results tagged with that ID from specific creation tools (createImage, editImage, etc.), which is helpful for agent understanding.
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 verb 'List' and the resource 'images' with scoping ('previously generated through the API, most recent first'), distinguishing it from sibling creation tools like createImage, editImage, etc.
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 positions it as a read-only history lookup with no credits or generation, but does not explicitly exclude alternative tools like get3DModelResults; however, the sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getSpriteResultsAInspect
List spritesheets you previously generated through the API, most recent first. This is a free read-only history lookup (no credits, no generation); it does not create anything. Pass an optional request_id query parameter to return only the results tagged with that id when you originally called animateSprite or transferMotion. Requires an API key (user scope).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Filter results by request_id |
Tool Definition Quality
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 tool is read-only, free, requires an API key, and lists results. However, it could mention pagination or rate limits.
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 three sentences, front-loaded with the main purpose, and every sentence adds value. No wasted words.
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?
Given the low complexity (one optional parameter, no output schema), the description adequately covers purpose, usage, and authentication. Missing details like output format are acceptable for a simple list 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 schema has 100% coverage with one parameter (request_id) described. The description adds meaningful context by explaining it filters results tagged with that id from animateSprite or transferMotion calls.
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 it lists previously generated spritesheets, using the verb 'list' and specifying the resource. It distinguishes from siblings like animateSprite and transferMotion by being a read-only history lookup.
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 provides clear context for when to use the tool (retrieve previous results) and explains the optional request_id filter. However, it does not explicitly state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getVideoResultsAInspect
List videos you previously generated through the API, most recent first. This is a free read-only history lookup (no credits, no generation); it does not create anything. Pass an optional request_id query parameter to return only the results tagged with that id when you originally called createVideo. Requires an API key (user scope).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Filter results by request_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It clearly states the tool is read-only, free (no credits), non-generative, and provides filtering behavior. While it doesn't mention pagination or rate limits, the description is sufficient for a simple listing tool.
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 two sentences with no wasted words. It front-loads the purpose ('List videos you previously generated through the API, most recent first') and adds essential details efficiently.
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 tool with one optional parameter and no output schema, the description is complete. It explains what the tool does, how to use it (including the filter), and prerequisites (API key). The sibling tools cover other media types, so context is adequate.
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, request_id, is described in the schema as 'Filter results by request_id'. The description adds value beyond the schema by explaining that it returns results tagged with that id from a previous createVideo call. With 100% schema coverage, baseline is 3, and the added context justifies a 4.
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 lists videos generated through the API, most recent first, with a specific verb ('list') and resource ('videos'). It distinguishes from siblings like createVideo by emphasizing it's read-only, and from other get-* tools by focusing on videos.
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 provides explicit usage context: it's a free read-only history lookup, does not create anything, and requires an API key with user scope. It also explains the optional request_id parameter for filtering. However, it does not explicitly state when not to use or mention alternatives, though the sibling list implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listAnimationPresetsAInspect
List the available animation presets along with their perspectives and the eight supported compass directions (N, NE, E, SE, S, SW, W, NW). Synchronous GET with no request body: it returns an animations array (each with id, name, category, description, duration, and preview_url), a deduplicated perspectives array, and the directions list. This is a free discovery endpoint and does not charge credits. Use it to obtain the preset_id, perspective, and direction values that transferMotion needs, and to find motion preset names you can reference when animating; pair it with transferMotion (to apply a preset onto a sprite) and animateSprite (text-prompt animation). Requires an API key (user scope).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it's a synchronous GET, no request body, free discovery endpoint, does not charge credits, and requires API key. Also outlines return structure.
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?
Well-structured and front-loaded, though slightly verbose. Every sentence adds value, but could be tightened slightly.
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?
Given no output schema and no annotations, the description compensates fully by detailing return arrays, fields, API key requirement, and usage context. No gaps.
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?
No parameters exist, so baseline 4 is appropriate. Description doesn't need to add param info but effectively explains output fields.
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?
Clearly states it lists animation presets with perspectives and directions. Distinguishes from siblings by specifying its role in obtaining values for transferMotion and animateSprite.
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?
Explicitly says when to use: to get preset_id, perspective, direction for transferMotion and to find motion preset names for animating. Also mentions pairing with specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
removeBackgroundAInspect
Remove the background from a single image, returning the subject isolated on a transparent background. Supply the source image (URL or base64); optionally set crop to trim the result to the content, and creative_edit (default true) for higher-quality output that may not match the input pixel-for-pixel. Synchronous: the call blocks and returns a single image result with a url (not an array). The image is uploaded and validated, and an image larger than 15MB is rejected with HTTP 400. Credits are charged only on success. Use removeBackground for this dedicated cutout task; editImage can also remove backgrounds via a prompt but is better for broader edits, while createImage and generateWithStyle produce new images rather than process an existing one. Pass an optional request_id to tag the result so you can retrieve it later via getImageResults. Requires an API key (user scope).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for removing the background of an image |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses synchronous blocking, returns single image with url, image validation, 15MB limit, credits charged on success, and creative_edit behavior. Missing rate limits or error details beyond 400, but covers most key behaviors.
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?
Description is around 150 words, front-loaded with purpose. Every sentence serves a purpose: purpose, parameters, behavior, siblings, optional parameter, auth. Slightly verbose but efficient overall.
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?
Given no annotations, no output schema, and simple nested parameter, description covers all needed aspects: input, behavior, limitations, credit cost, sibling differentiation, and auth. Agent can confidently invoke.
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%. Description adds value beyond schema: clarifies 'URL or base64-encoded' for image, explains crop trims to content, creative_edit may not match input, and request_id for retrieval via getImageResults. Baseline 3, elevated for added context.
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?
Description clearly states 'Remove the background from a single image, returning the subject isolated on a transparent background'. It uses a specific verb and resource, and distinguishes from siblings by naming editImage, createImage, and generateWithStyle, explaining their different purposes.
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?
Explicitly guides: 'Use removeBackground for this dedicated cutout task; editImage can also remove backgrounds via a prompt but is better for broader edits, while createImage and generateWithStyle produce new images'. Also mentions synchronous nature, credit cost, and size limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rotateSpriteAInspect
Re-render an existing sprite from a different camera viewpoint while keeping the same character and pose, taking a source image (URL or base64), a required camera_rotation azimuth (one of 0, 45, 90, 135, 180, -135, -90, -45 degrees), an optional camera_elevation (0, 30, or 60 degrees; omit to keep the current elevation), and an optional n (1-4) for the number of variations. Only works with sprite image types (not icons, screenshots, etc.). Synchronous: the call blocks and returns an array of rotate-sprite results, each with the generated image url and the camera_rotation and camera_elevation that were applied. Credits are charged only on success, scaled by the number of images generated. Use this to produce alternate view angles of a character; use generatePose instead to change the character's pose rather than the camera, and animateSprite or transferMotion to bring a sprite to life. Pass an optional request_id to tag the results so you can retrieve them later via getSpriteResults. Requires an API key (user scope).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for rotating the camera view of an existing sprite |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers all behavioral traits: synchronous blocking call, only works with sprite images, credits charged on success scaled by number of images, optional request_id for retrieval via getSpriteResults. It also mentions camera_rotation and camera_elevation constraints.
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 comprehensive but slightly lengthy. It front-loads the core purpose and then details parameters. Every sentence adds value, but could be marginally more concise. Still well-structured.
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?
Given no annotations, no output schema, and a moderately complex tool (6 parameters, synchronous, credits), the description is complete. It covers purpose, usage, all parameters, behavioral traits, constraints, sibling differentiation, and result retrieval.
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% with parameter descriptions, but the tool description adds context beyond schema: e.g., image type limitations, synchronous behavior, credit scaling, and retrieval via request_id. This adds value beyond the schema.
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 re-renders a sprite from a different camera viewpoint while preserving character and pose. It specifies it works only with sprite images (not icons/screenshots) and contrasts with sibling tools like generatePose, animateSprite, and transferMotion, providing clear differentiation.
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?
Explicitly states when to use (produce alternate view angles) and when not to (use generatePose for pose change, animateSprite/transferMotion for animation). Also notes API key requirement and credit consumption only on success.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transferMotionAInspect
Transfer motion from a reference video or a named animation preset onto a static sprite image, producing an animated spritesheet that mimics the reference movement. Provide the sprite as image (URL or base64) plus either a video URL or a preset_id together with perspective and direction. Synchronous: the call blocks and returns a single sprite result directly (spritesheet URL, plus optional GIF, individual frames, or with-background spritesheet when requested) with no polling step. It returns HTTP 400 if neither a video nor a complete preset_id/perspective/direction triple is supplied, if the named preset, perspective, or direction cannot be resolved, or if the model/duration combination is invalid. Credits are charged only on success, based on the spritesheet's actual produced duration (which may be shorter than requested if the reference video is shorter). Use this when you have an existing motion clip or preset to copy; prefer animateSprite to generate animation purely from a text prompt, and call listAnimationPresets first to get valid preset_id, perspective, and direction values. Pass an optional request_id to tag the result so you can retrieve it later via getSpriteResults. Requires an API key (user scope).
Credits: cost varies by model and duration (credits/sec): Tango 4/s (min 4); see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for transferring motion from a video onto a static sprite image, producing an animated spritesheet. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses synchronous blocking behavior, credit charging only on success, potential shorter duration, optional outputs, and authentication requirements. Missing rate limits but covers essential traits.
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?
Well-structured and front-loaded with core purpose. While somewhat lengthy, every sentence adds value. Could be slightly tighter, but overall effective.
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?
Comprehensive: covers synchronous behavior, error codes, credit model, return fields, optional outputs, and references to pricing docs. Complete given complexity and lack of output schema.
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 baseline is 3. The description adds significant context beyond schema by explaining the conditional requirement (video vs preset), how credits depend on duration, and optional output flags. This extra value merits a 4.
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: transferring motion from a video or preset onto a sprite. It distinguishes from sibling tools by explicitly recommending animateSprite for text-prompt animation and listAnimationPresets for preset discovery.
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?
Provides explicit when-to-use guidance, prerequisites (image + video or preset_id/perspective/direction), and error conditions (HTTP 400). Also mentions when to prefer alternatives and to call listAnimationPresets first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validateApiKeyEndpointAInspect
Validates an API key. Returns 200 if valid, 403 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the HTTP response codes (200 for valid, 403 for invalid), which is useful, but lacks other critical behavioral details such as authentication requirements, rate limits, error handling beyond these codes, or whether this is a read-only operation. The description does not contradict any annotations since none exist.
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 extremely concise with two sentences that directly state the tool's purpose and outcome. Every word earns its place, and it's front-loaded with the core functionality, making it efficient and easy to parse.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and the basic return codes, but for a validation tool, it lacks details on error conditions beyond 403, performance characteristics, or integration context, which could help an agent use it more effectively.
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 input schema has 0 parameters with 100% coverage, so the description doesn't need to compensate for missing parameter documentation. The description adds no parameter-specific information, which is appropriate here, but it does provide context about the tool's function that goes beyond the empty schema.
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 specific action ('Validates an API key') and the resource involved ('API key'), making the purpose immediately understandable. It distinguishes this tool from all sibling tools, which are focused on media creation/editing tasks, by being the only one handling API key validation.
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 provides no guidance on when to use this tool versus alternatives or in what context it should be invoked. It doesn't mention prerequisites, dependencies, or typical scenarios where API key validation would be needed, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.