RYLA

ryla_generate_image

Generate Studio-quality images for an existing character with full creative control (scene, outfit, pose, lighting, expression, style). This is the primary, full-featured image tool -- prefer it over ryla_generate_base_image. Character must already exist; use ryla_list_characters to find a characterId. Returns a jobId; poll with ryla_generation_status.

Input Schema

TableJSON Schema

Name	Required	Description
`nsfw`	No	Enable unrestricted fan content generation
`seed`	No	Base seed; each image increments it
`count`	No	Number of images to generate
`scene`	Yes	Scene preset or description
`loraId`	No	LoRA id to use, if not the default for this character
`outfit`	No	Outfit description
`poseId`	No	Pose preset id, e.g. "standing-casual"
`quality`	No	Quality tier: "standard" (HD, default) or "ultra" (4K)
`useLora`	No	Use the character LoRA for face consistency, if trained
`lighting`	No	Lighting preset, e.g. "natural.goldenHour"
`shotType`	No	Camera framing, e.g. "close-up-portrait", "full-body"
`expression`	No	Facial expression preset, e.g. "positive.smile"
`aspectRatio`	Yes	Image aspect ratio
`characterId`	Yes	Character UUID to generate images for
`environment`	No	Environment preset or description
`stylePreset`	No	Visual style preset (default ultraRealistic)
`loraStrength`	No	LoRA strength, 0.1-2.0
`realismStyle`	No	Apply realism post-processing style
`promptEnhance`	No	Enable AI prompt enhancement (default true)
`enableFaceSwap`	No	Route through face-swap for the reference image
`referenceMethod`	No	Reference image method (default instantid)
`antiDetectPreset`	No	Anti-detection intensity (default moderate); advanced/maximum require Pro
`socialMediaReady`	No	Apply anti-AI-detection post-processing
`referenceImageUrl`	No	Reference image URL for face consistency (InstantID/PuLID), as an alternative to LoRA
`referenceStrength`	No	Reference image strength, 0.1-1.0

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool is asynchronous by returning a jobId that must be polled, and it clarifies the dependency on an existing character. It could have mentioned credit consumption or Pro restrictions, but the core operational behavior is transparent enough for correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences pack in the purpose, scope, primary alternative, prerequisite, and follow-up step with no wasted words. The most important differentiator, 'primary, full-featured image tool,' appears early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 25-parameter tool with no annotations and no output schema, the description covers the essential invocation lifecycle: find the character, generate, and poll the status. It also names the key alternative. It leaves some operational details like pricing or Pro gating to the schema, but the core flow is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds useful context that characterId must reference an existing character and that the result is a jobId, but it does not add parameter-level format or default details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: generate studio-quality images for an existing character. It also names the distinguishing property, full creative control, and explicitly positions itself as the primary full-featured image tool versus ryla_generate_base_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly says to prefer this tool over ryla_generate_base_image and states the prerequisite that the character must already exist, directing the agent to ryla_list_characters. It also explains the async workflow with jobId and ryla_generation_status. It does not enumerate all sibling alternatives, but the main competing image tool is explicitly covered.

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

All RYLA tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation4/5

Most tools map to a distinct generation type or resource, and the ryla_generate_* family is easy to partition by output type. The main ambiguity is ryla_generate_base_image vs ryla_generate_image, but the description for ryla_generate_image explicitly positions it as the primary Studio tool and clarifies the required characterId.

Naming Consistency4/5

The ryla_ prefix and snake_case are applied consistently, and generate_* forms a clear pattern for most action tools. A few names deviate from the verb_noun pattern (ryla_generation_status, ryla_server_info, ryla_account_credits_balance), but they are still predictable.

Tool Count5/5

At 11 tools, the set is well-scoped for a media generation server: generation types, status polling, account checks, and character lookup are each covered. The count supports the domain without feeling bloated.

Completeness3/5

The generation lifecycle is well-covered: jobs can be submitted, polled, status checked, and outputs viewed via the gallery. However, character management is almost entirely absent: there is no way to create, update, or delete a character through the MCP, and the list_characters description explicitly pushes creation to the external app, leaving a notable workflow gap.

Resources

Need Help?