Skip to main content
Glama
kyuza1
by kyuza1

preview_character

Preview a character in chat as four side-by-side directions, animated or static, to verify appearance before generating final assets.

Instructions

Mostra o personagem direto no chat, sem salvar arquivos: as 4 direções lado a lado. animated=True (padrão) devolve um GIF animado tocando a animação; False, uma imagem parada. animation: walk, idle, slash, run... ou uma especial (tool_hammer, slash_128, walk_128...). Use para conferir o visual antes de generate_character.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
animatedNo
animationNowalk
body_typeNomale

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden and does disclose key behavior: no files are saved, output is a GIF (animated=True, the default) or a still image (False). This output-format disclosure is genuinely useful. It omits permission/auth needs and any size or rate-limit characteristics.

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

Conciseness4/5

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

Front-loaded with the core capability and the no-file-saving constraint, then parameter behavior, then the routing hint. Dense and mostly free of waste, though the animation value enumeration is slightly listy.

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?

No output schema exists, so the description's explanation of the returned media type (GIF vs still) is valuable and largely fills the gap. The main incompleteness is the unexplained required items parameter, but the preview behavior itself is adequately conveyed.

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 0%, so the description must compensate. It usefully explains animated (boolean meaning and default) and animation (sample values plus special variants the schema has no enum for), but leaves body_type and the required items parameter entirely undefined.

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

Purpose5/5

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

States a specific verb (shows/previews) and resource (character), plus distinguishing scope: renders the 4 directions side by side directly in chat without saving files. It also implicitly separates itself from generate_character, which it names, so an agent can route between preview and generation without opening either schema.

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?

Explicitly says 'Use to check the visual before generate_character', which gives a clear condition for selecting this tool and names the relevant sibling. It does not state any when-not-to-use conditions or mention other siblings, keeping it just short of the top band.

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