RYLA

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

With no annotations provided, the description carries the full burden, and it clearly signals a read-only operation through the verb 'check' and the noun 'balance', implying no side effects. It also specifies that the balance belongs to the authenticated user, hinting at authentication requirements. While it lacks details like rate limits or error behavior, the simplicity of the operation means the description is sufficiently transparent.

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 a single, compact sentence that front-loads the action ('Check') and the resource ('RYLA credit balance'), followed by the user scope. It contains no filler or redundant information, making it highly concise 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?

Given the tool has no parameters, no annotations, and no output schema, the description adequately covers the essential context: what action is performed, on whose account, and what resource is queried. It does not specify the response format or units, but 'current credit balance' reasonably implies a numeric value, and the tool's low complexity makes this a minor gap.

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 zero parameters, so there are no parameter semantics to describe. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the action and return value rather than parameters.

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 uses a specific verb ('check') with a clear resource ('RYLA credit balance') and scope ('authenticated user'), making the tool's function immediately obvious. It is clearly distinct from the sibling tools, which are all about generation, gallery, or server info, so there is no ambiguity about what this tool 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 implies usage in the context of checking an authenticated user's balance before or after generation tasks, but it does not explicitly state when to use this tool over alternatives or when not to use it. No sibling tool handles balance checks, so context is inferred rather than explicitly articulated.

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

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

Since no annotations are provided, the description carries the full burden of transparency. It mentions 'most recent,' which gives a scope hint. However, it fails to disclose crucial operational details like pagination behavior, latency guarantees, or how the 'recent' window is defined.

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 definition is highly concise, using a single sentence to state its function efficiently without any unnecessary filler 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 that the parameters are fully described in the schema and the goal is simply listing history, the description is adequate. It clearly defines the scope (user's recent jobs) without needing to explain how to return the data.

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 description coverage is 100%, meaning the schema already provides excellent detail on both `limit` and `detail`. The description adds no meaningful semantic information beyond what is already present in the structured fields, meeting the baseline criteria.

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 uses a specific verb ('List') and clearly defines the resource being accessed (authenticated user's most recent generated images/jobs). This scope is distinct from all the generation and status sibling tools listed.

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?

While it does not explicitly state 'use this when you want a list,' its specific function as listing 'most recent' jobs clearly differentiates it from the creation, generation, or modification tools. The purpose itself implies its correct use case.

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

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

With no annotations provided, the description carries the full burden and does meaningful work: it discloses URL expiry ('about an hour'), states 'Read only: never regenerates anything,' and implies the operation is a pure retrieval. It does not say what happens when a character has no reference sheet yet or whether URLs require authentication, which are the remaining gaps.

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?

Four short sentences, each carrying distinct information: what is returned, how to use it, expiry, and the read-only guarantee. The most actionable detail (the referenceImageUrl hand-off) is front-loaded immediately after the purpose.

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?

With no output schema, the description must convey return values, and it does — two URL sets plus their one-hour lifetime. Only the failure mode (character existing but with no generated sheet) is unaddressed, for an otherwise simple single-parameter read 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?

There is a single required parameter with 100% schema description coverage, so the schema already establishes characterId as a UUID. The description adds the useful semantic link that the character is the subject whose reference images are returned, giving a baseline-plus score.

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 opens with a specific verb and resource — 'Get fresh URLs of a character's reference material: its base image and the 16-shot reference sheet' — and enumerates exactly what is returned. It is clearly distinct from the sibling ryla_generate_character_sheet, which creates the sheet rather than retrieving URLs for it.

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

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

It gives concrete downstream routing: 'Pass any of these as referenceImageUrl to ryla_generate_image to keep the face consistent,' which tells the agent both the purpose and the next call. It does not state explicit exclusions (e.g., what to do if no sheet exists yet, or when to prefer ryla_list_characters), so it falls short of a full when/when-not treatment.

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

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

With no annotations provided, the description carries the full behavioral burden and does well by revealing that this is asynchronous (returns a jobId), requires Pro plan, and needs a pre-existing character. It does not mention error cases, costs, or rate limits, which prevents a higher score.

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 compact and front-loaded: it states the purpose, the plan requirement, prerequisite, and polling flow in four sentences with no filler. Every sentence contributes useful information for an agent.

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 an asynchronous tool with no output schema and no annotations, the description covers the main flow well: prerequisites, plan requirement, jobId return, and status polling. Minor omissions like error/error polling specifics and detailed failure behaviors mean it is not fully complete, but it is strong for a generation 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?

Schema coverage is 100% and each parameter already has detailed descriptions, including constraints, defaults, enums, and the audioUrl/voiceNoteId relationship. The description adds only the idea that characterId must reference an existing character, which is mostly a usage note rather than new parameter-level semantics, so the baseline 3 applies.

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

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

The description states a specific action and resource: generating a talking avatar video from a character face plus audio and names related workflow steps. It does not explicitly differentiate from overlapping siblings like ryla_generate_lip_sync or ryla_generate_video, so it stops short of full sibling 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?

The description sets clear preconditions (Pro plan required, character must already exist) and gives a workflow: use ryla_list_characters to get characterId and poll ryla_generation_status for jobId. It does not explicitly state when to choose an alternative generation tool, so it lacks an explicit exclusion or alternative comparison.

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

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

With no annotations, the description conveys the key asynchronous behavior: it returns a jobId rather than the image and tells the agent to poll ryla_generation_status. It does not cover credit costs or content-safety side effects, but the async pattern is a meaningful disclosure.

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 short sentences with no filler; the action and input dimensions are front-loaded and the async follow-up is stated efficiently. Every part earns its place.

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 generation tool with no output schema, the description covers the response protocol via jobId and the polling instruction, while the schema covers the inputs. Missing sibling-selection guidance and cost/safety warnings are the main gaps, but the tool remains invocable.

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?

All four parameters are already described in the schema, so the description adds no detailed parameter semantics beyond summarizing vibe/niche/promptInput. The schema carries the burden, so the baseline of 3 is appropriate.

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

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

States a clear action — generate base character images — and the input dimensions (niche/vibe/prompt). The mention of jobId distinguishes it from direct-return generation tools, but it does not name a sibling like ryla_generate_character_sheet, so differentiation is implicit rather than explicit.

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 text implies usage for base character generation and provides a follow-up polling step. It does not state when to choose this tool over siblings such as ryla_generate_image or ryla_generate_character_sheet, nor does it give exclusions, leaving selection to inference from the name.

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

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

With no annotations, the description carries the burden and does disclose two non-obvious traits: cost behavior ('flat, no extra credits') and async behavior (returns a sheetJobId that must be polled). It does not say what happens if a sheet already exists, whether the operation is reversible, or what auth/entitlements are required.

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, front-loaded sentences with the primary action first and the workflow steps after; nothing is padded. The parenthetical about the retired sheet is slightly inside-baseball but earns its place by disambiguating against legacy tooling.

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 two-parameter, no-output-schema generation tool, the description covers what it produces, that it is async, how to poll, and what it costs. Remaining gaps (output contents, error cases, nsfw implications) are minor rather than blocking.

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 both parameters are already documented in the schema. The description only adds a pointer on where characterId comes from (ryla_list_characters) and says nothing about the nsfw flag's intent, so it adds marginal meaning over the schema — baseline 3 applies.

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?

States a specific verb and resource ('Build the 18-shot identity reference sheet for an existing character') and scopes it to existing characters, which cleanly separates it from the generate_base_image / generate_image siblings. The parenthetical pinning it as the live replacement for the retired character sheet removes ambiguity about which tool is current.

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?

Gives an explicit prerequisite path ('Use ryla_list_characters to find a characterId') and the follow-up step ('poll with ryla_generation_status'), so the agent knows the surrounding workflow. It stops short of naming when NOT to use it, e.g. how it differs in outcome from generate_base_image or generate_image.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Returns the generation result.' It does not disclose whether generation is asynchronous, whether credits are consumed, or what the result format looks like. The existence of ryla_generation_status suggests async behavior that this description leaves unaddressed.

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?

A single concise sentence with no filler; both the operation and the return expectation are front-loaded. Every phrase contributes meaningful information.

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?

This is a 5-parameter generation tool with no output schema and no annotations, so more context is needed about return format, async behavior, and parameter roles. The description only states a basic purpose and a vague return, which is insufficient for fully correct invocation.

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

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

Schema description coverage is 100%, so the baseline applies. The description adds no parameter-level detail beyond repeating 'reference base image,' which is already in the baseImageUrl schema. The phrase 'Swap a character face' could mislead an agent into thinking characterId is required, when the schema marks it optional.

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 uses the specific verb 'Swap' and identifies the resource ('a character face onto a reference base image'), clearly distinguishing this tool from sibling generation tools like ryla_generate_image and ryla_generate_base_image. The return statement also sets an explicit expectation of an output.

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?

No guidance is provided on when to choose this tool over its siblings, nor are prerequisites such as having a characterId or an accessible base image URL mentioned. An agent must infer usage purely from the schema and sibling names.

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

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

With no annotations, the description carries the burden and does well: it discloses the asynchronous lifecycle (returns a jobId, must be polled) and the precondition that a character must already exist. It does not mention credit consumption (only hinted at in the schema for quality/antiDetectPreset) or any plan gating, so a mutation/cost-bearing operation remains partially opaque.

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?

Four short sentences, front-loaded with purpose, then differentiation, then prerequisite, then lifecycle. Every sentence carries distinct information with no repetition of the schema.

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 28-parameter tool with no output schema and no annotations, the description covers purpose, sibling routing, prerequisite, and the return/polling contract, which is the essential remaining gap. It leaves out cost/credit implications and plan-gated options (e.g. advanced anti-detect presets), which would be genuinely useful for an expensive generation call.

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

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

Schema description coverage is 100% and each parameter already documents enums, defaults, ranges and conditional requirements (scene/aspectRatio vs templateId), so the schema does the heavy lifting. The description only names the creative dimensions generically (scene, outfit, pose, lighting, expression, style) without adding syntax, precedence, or trade-off guidance beyond what the schema states.

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?

States a specific verb ('Generate') and resource ('Studio-quality images for an existing character') plus the controllable dimensions, and explicitly differentiates itself from the sibling ryla_generate_base_image. An agent can distinguish it from ryla_generate_face_swap or ryla_upscale_image without opening a schema.

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?

Gives an explicit preference rule ('primary, full-featured ... prefer it over ryla_generate_base_image'), a prerequisite ('Character must already exist'), and a discovery path ('use ryla_list_characters to find a characterId'). It also states the follow-up step ('poll with ryla_generation_status'), which is the exact alternative an agent needs after calling.

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

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 discloses the requirement for RYLA-hosted URLs, Pro plan, and the possibility of the feature being unavailable (with an error explanation). It does not describe the output format (e.g., video URL or job ID), whether the operation is asynchronous, or other error scenarios. This is adequate but not comprehensive for a generation 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, front-loaded with the core purpose, followed by critical constraints and availability caveats. Every sentence earns its place with no fluff or repetition. It is efficient 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?

Given the tool has three required parameters, no output schema, and no annotations, the description covers prerequisites and potential unavailability but omits key behavioral details like the return value (likely a job ID or video URL) and whether the operation is async (hinted by sibling ryla_generation_status). It does not address error handling beyond the unavailable-feature case, nor cost or time. This is a moderate gap for an agent to successfully invoke and monitor the 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?

Schema coverage is 100% and each parameter already has a description in the schema. The tool description reiterates that both URLs must be RYLA-hosted and owned, which reinforces the schema but adds no new meaning. The 'prompt' parameter is not elaborated beyond the schema's 'desired output' description. Thus, the description adds minimal 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 generates a talking video via lip-syncing a portrait image to an audio track, with a specific resource and verb. It mentions the underlying tech (kie.ai InfiniTalk), making the purpose unmistakable. However, it does not explicitly name sibling tools or contrast with them, so it doesn't fully differentiate from alternatives like ryla_generate_avatar_video or ryla_generate_video.

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 prerequisites: both URLs must be RYLA-hosted and owned, a Pro plan is required, and the feature may not be available. It implies when to use this tool (for lip-sync talking videos) and warns about potential unavailability. It does not mention alternative tools or when not to use this one, but the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries the full burden and does well: it discloses the async job model (returns a jobId), the default image-selection behavior, and per-second/per-resolution pricing (720p=240, 480p=120, 1080p=470, unrestricted x2). It stops short of failure modes, rate limits, or what happens on insufficient credits, so not a 5.

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 what the tool does, then prerequisites, defaults, cost, and follow-up. Every sentence is load-bearing — the pricing list and the polling pointer are actionable rather than filler.

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

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

For a 9-parameter async generation tool with no output schema and no annotations, the description supplies the missing context: cost model, default behavior, returned jobId, and the polling sibling. An agent has everything needed to invoke it correctly and handle the result.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real value by mapping resolution values to credit cost and explaining the default sourceImageId resolution path. It does not add meaning to prompt, wantAudio, aspectRatio, or nsfw beyond the schema text.

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?

States a specific verb and resource ('Generate a video from an existing character image'), names the underlying model (image-to-video, Wan 3.0), and makes the prerequisite explicit ('Character must already exist'). An agent can tell this apart from sibling generators like generate_avatar_video and generate_video_swap without opening any schema.

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?

Gives explicit routing: use ryla_list_characters to get a characterId, pass sourceImageId (from ryla_account_gallery_list) to pick an image, poll with ryla_generation_status. It also states the default behavior when sourceImageId is omitted, so there is no ambiguity about the alternative.

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

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

No annotations are present, so the description carries the full burden. It discloses the Pro plan requirement, the need for pre-existing assets (video and character), and the async behavior (returns jobId, poll with status). It doesn't cover side effects or error conditions, but for a generation tool this is reasonably transparent.

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 sentences, front-loaded with the main purpose, followed by prerequisites and async flow. No fluff, every sentence earns its place.

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 7 parameters and no output schema, the description covers the essential flow: what it does, prerequisites, how to get the result (jobId + polling). It doesn't enumerate all optional parameters, but the schema already does that. Missing error handling details, but the core is 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. The description adds value by clarifying that videoUrl must be an uploaded RYLA video and that the character must already exist, which complements the schema. It also notes that outfitPrompt/backgroundPrompt are only used when their enabled flags are true, though the schema already says that.

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 and resource: 'Swap a character face into an existing video (face swap onto uploaded footage)'. It clearly distinguishes this from the sibling ryla_generate_face_swap (which likely targets images) by specifying 'existing video' and 'uploaded footage'.

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 prerequisites: videoUrl must be an already-uploaded RYLA video, character must exist, and Pro plan is required. It also names the sibling ryla_list_characters for finding characterId and ryla_generation_status for polling. It doesn't explicitly state when not to use this tool, but the conditions are clear enough.

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

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

No annotations are provided, so the description carries the full burden. It usefully reveals that the character must already exist and that the output is speech audio (TTS). However, it does not disclose whether generation is asynchronous, whether the result needs polling via ryla_generation_status, how credits are consumed, or what the actual return payload looks like.

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

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

Two sentences with no filler. The primary purpose is front-loaded, and the second sentence delivers the only critical prerequisite and sibling routing needed. Every word earns its place.

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?

With no output schema and no annotations, the description must explain the full call flow. It explains what to do before the call, but never says what the tool returns or how to retrieve the generated audio. The omission is significant given that the sibling ryla_generation_status strongly suggests an asynchronous generation workflow.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters in detail. The description only reinforces the importance of characterId by pointing to ryla_list_characters; it does not add semantic meaning beyond what the schema provides.

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 the specific action ('Generate speech audio (TTS)') and the exact resource ('in an existing character's voice'). This clearly differentiates it from the sibling generation tools such as ryla_generate_image, ryla_generate_video, and ryla_generate_face_swap, which all target different modalities.

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 states a prerequisite ('Character must already exist') and directly names the sibling tool to use when that prerequisite is unmet ('use ryla_list_characters to find a characterId'). This gives the agent concrete routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose read-only safety, whether the call blocks or requires polling, what status values are possible, or when a job is terminal.

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 a single front-loaded sentence with no wasted clauses. It is appropriately terse for this simple lookup, though it leaves important context to the schema.

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?

There is no output schema and no annotations, so the description should explain more about the return value and polling behavior. It does not describe status values, output URLs, or how slim/full differ beyond what the input schema says.

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

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

Schema description coverage is 100%, and the schema fully documents both jobId and the slim/full detail enum. The description only echoes jobId and adds no parameter meaning beyond the schema, so the 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?

States a specific verb ('Check') and resource ('status of a generation job') with the required jobId. It is distinguishable from the ryla_generate_* sibling tools because it reports status rather than initiating generation, though it does not name those siblings.

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 usage is implied by the schema note that jobId comes from a ryla_generate_* tool call, but the description itself gives no explicit when-to-use, when-not-to-use, or polling guidance. An agent can infer the workflow, but must rely on schema text.

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

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

No annotations exist, so the description carries the burden: the verb 'List' makes the read-only nature evident, it declares the auth scope (authenticated user's characters), and it explains the meaning of the `loraReady` field in relation to `useLora: true`. It stops short of describing the full shape of a returned character or any pagination/empty-state 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?

Three short sentences, front-loaded with purpose, then the field that drives a downstream decision, then the negative constraint. Nothing is redundant and the constraint is not buried.

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?

With no output schema, the description must partially stand in for return values; it covers `loraReady` and `characterId` but not the other fields a character entry likely carries. For a zero-parameter read tool this is nearly sufficient, but a brief note on the other returned fields would close the gap.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description instead spends its words on the return-derived `characterId` value the caller needs downstream.

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?

Specific verb ('List') plus scoped resource ('the authenticated user's existing characters'), with a parenthetical defining what a character is ('AI influencers'). It also positions itself against the generate_* siblings by explaining that its output feeds their characterId parameter.

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 the condition that selects this tool ('so you can pick a characterId for the other generation tools') and adds a hard exclusion: there is no character-creation tool, so creation must happen in the RYLA app. Both when-to-use and when-not-to-use are covered.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: it returns ids rather than content, and unrestricted/NSFW templates are hidden unless the flag is set — a non-obvious gating rule. It never states read-only semantics or pagination behavior, which is why it is not a 5.

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, front-loaded with the core action, then the return value, then the hand-off to the generation tool. Every sentence contributes new information with no restatement of the name or schema.

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

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

For a 4-parameter, output-schema-less listing tool, the description covers the action, the returned field (ids), and the key gating flag. The main remaining gap is that pagination semantics and read-only guarantees are left entirely to the schema and annotations (absent), but nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline would be 3; the description earns above that by clarifying that `search` matches name or tag and that `unrestricted` acts as a visibility gate rather than a filter on results already returned. It adds no guidance on page/limit usage.

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?

Specific verb plus resource ('Find RYLA templates'), with the resource defined inline as 'ready-made looks: scene, outfit, pose' and the return value stated ('Returns template ids'). This clearly separates it from the ryla_generate_* siblings, which produce media rather than list existing assets.

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

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

The description gives the downstream path explicitly ('Pass an id as `templateId` to ryla_generate_image'), which tells the agent when this tool is the right prerequisite. It does not state any exclusions or when a different listing tool (e.g. ryla_list_characters) should be preferred, so it falls short of full routing guidance.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. 'Get' implies a read-only operation, but the description does not disclose whether the tool makes a live connection, returns static configuration, or may expose sensitive connection details. It also does not describe the response shape.

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?

One concise, front-loaded sentence communicates the tool's purpose with no filler or redundancy. Every word adds meaning.

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 zero-parameter tool, invocation is simple and the description gives enough to identify the tool's purpose. However, without an output schema or annotations, 'configuration and connection info' is vague about the actual returned fields, so an agent must infer what the response will contain.

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 tool has zero parameters, so there is no parameter documentation burden. The schema is trivially covered, and the description appropriately avoids inventing parameter guidance.

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 uses a specific verb ('Get') and names the exact resource ('RYLA external MCP server configuration and connection info'). It is clearly distinct from all sibling tools, which cover generation, account credits, gallery, and character operations.

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

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

The description implies the tool is used whenever server configuration or connection details are needed, and none of the sibling tools cover that concern. However, it does not explicitly state when to use it versus alternatives or provide exclusions.

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

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

With no annotations, the description carries the full burden and does most of it: discloses credit cost, that output is faithful with no new content, and that the call is asynchronous (returns a job, needs polling). It doesn't mention validation failure modes (bad imageId, unsupported source) or whether credits are refunded on failure, which keeps it short of a 5.

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?

Four compact clauses, zero filler: capability and constraint first, then cost, then parameter provenance, then the async follow-up. Every sentence earns its place and the critical information is front-loaded.

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 an async mutation tool with no output schema, the description supplies what an agent needs: cost warning, source of the required id, and the polling path. A brief note on the job object's shape or what happens on invalid input would close the last gap.

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 scale, imageId, and requestId idempotency are already documented in structured fields. The description adds provenance for imageId, which is genuinely useful, but nothing extra on scale defaults or requestId retry semantics beyond what the schema states. Baseline 3 applies.

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?

States a specific verb (upscale) and resource (one of your own generated images), plus scope qualifiers: 2x or 4x, faithful, no new content. That distinguishes it from ryla_generate_image and ryla_generate_base_image, which create content rather than enlarge existing output.

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 tells the agent where imageId comes from (ryla_generation_status output.imageIds or ryla_account_gallery_list) and the follow-up workflow (poll with ryla_generation_status). No explicit when-not-to-use case, e.g. that non-owned or externally sourced images can't be upscaled, but the 'your own generated images' phrasing implies it.

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