GenMagic

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

With no annotations provided, the description carries the full burden and delivers substantially: it discloses asynchronous behavior (job id returned immediately), billing implications ('nothing is charged yet'), the polling protocol, and automatic brand personalization when enabled. Operational behavior that the schema cannot express is fully surfaced.

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 purpose, then the key behavior (async + job id + billing), then the polling workflow, then the brand personalization conditional. Every sentence earns its place; there is no fluff or repetition of schema content.

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 and no annotations, the description explains the return value (job id), the completion condition (status 'completed'), how to obtain the final hosted URL (get_video), and billing behavior. Nothing essential is missing for a 2-parameter async creation 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 description coverage is 100%, so both prompt and aspect_ratio are already fully documented; baseline is 3. The description adds only marginal parameter context by calling prompt a 'text description' and hinting that brand personalization may alter how the prompt is applied. It does not expand aspect_ratio meaning beyond the schema's enum.

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: 'Start generating a video from a text description.' It clearly differentiates from siblings — video creation versus image/music/speech/text generation — and explicitly names get_video as the retrieval sibling, so an agent can distinguish roles without opening schemas.

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 defines the workflow explicitly: use this tool to start generation, then 'Poll it with the get_video tool every few seconds until the status is "completed"'. This routes the agent to the correct sibling for status checking. It does not explicitly state exclusions among the generate_* siblings, but the purpose clarity makes those boundaries obvious.

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 of behavioral disclosure. It usefully states that the image is returned inline plus a hosted URL, and that brand personalization is applied automatically when enabled. However, it does not mention potential account requirements, generation limits, or cost/credit implications, which are relevant for a generative tool with no annotation coverage.

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 with no wasted words. It front-loads the primary purpose, then covers the two key parameter modes, and ends with return behavior and branding context. It is slightly extended but 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 moderately simple tool with four well-documented parameters and no output schema, the description covers the core operation, return format, mode switching, and brand behavior. It could add explicit guidance about when not to use this tool, but the media-based sibling distinction makes that gap minor.

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 semantic value beyond the schema by explaining that passing 'image' switches the tool into image-to-image mode rather than generating from scratch, and by clarifying that 'logo' changes the output type. This helps the agent reason about the relationship between prompt, image, and type 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 states a specific verb and resource ('Generate an image from a text description with GenMagic') and immediately distinguishes it from the sibling generation tools (create_video, generate_music, generate_text, generate_speech) by the output modality. It also clarifies two sub-modes, image-to-image and logo generation, so an agent understands the full scope of the tool.

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 concrete usage conditions: pass an 'image' URL to transform that image, and type 'logo' to make a brand mark. It does not name sibling alternatives explicitly, but the sibling tools are different media types, so the intended context is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that the tool returns audio inline plus a hosted URL and that brand personalization can automatically affect mood. It does not mention limitations, rate limits, or authentication, but the disclosed return behavior and conditional branding behavior are meaningful.

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 filler. It front-loads the core action and result, then adds the brand-personalization nuance. 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 single-parameter tool with no output schema and no annotations, the description covers the essential context: what is generated, how input is provided, what the response includes, and a relevant conditional behavior. It could be slightly richer on output format details, but it is largely complete for 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?

The schema already describes the single 'prompt' parameter with 100% coverage, so the description adds no new parameter-level detail. The mention of 'text description' aligns with the schema but does not enrich 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 identifies a specific verb and resource: 'Generate an original music track from a text description.' It distinguishes this from siblings like generate_speech, generate_image, and generate_text by specifying the output type (music track) and the generation method (from text).

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 does not explicitly say when to use this tool versus alternatives such as generate_speech or generate_image. It implies usage by naming music as the resource, but it offers no selection criteria, exclusions, or comparisons to sibling tools.

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 of behavioral disclosure. It discloses the return format (inline audio plus hosted URL) and a key behavior: the text is voiced verbatim. It does not discuss persistence, rate limits, or authentication, but the core behavior is well covered for a simple 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 with no fluff or redundant content. It front-loads the primary purpose, then adds return behavior and a critical nuance, 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?

The tool is simple with two fully documented parameters and no output schema, so the description's mention of return behavior fills the main gap. It is sufficiently complete for an agent to select and invoke the tool, though it could add notes on URL persistence or audio format.

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 parameters are already fully documented. The description adds marginal reinforcement by stating verbatim voicing, but it does not add significant new meaning beyond the schema's own parameter 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 ('Turn text into spoken audio') and the resource, and the title explicitly labels it as text-to-speech. This distinguishes it from sibling tools like generate_text and generate_music without ambiguity.

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 when to use the tool: whenever spoken audio from text is needed. However, it does not explicitly mention alternatives or state when not to use it, leaving the choice somewhat to inference rather than direct 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 present, so the description carries the disclosure burden. It discloses automatic brand personalization, conversion of non-native attachment formats, and type-specific output behavior such as websites/SVG picking up the brand palette. It does not describe the return format or cost/latency implications, but core behavior is well covered.

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 primary purpose, then parameter variants, attachments, and branding behavior. Every sentence adds new information without redundancy or 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?

No output schema exists, so the description could have stated the return shape more explicitly, but it covers all invocation-relevant aspects: type selection, attachment handling, and brand behavior. The only notable omission is a direct statement of what the tool returns, though that is strongly implied by 'generate text'.

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 value by translating the 'type' enum into concrete outputs ('website' for a full self-contained HTML page, 'svg' for a vector graphic, etc.) and by explaining that attachments of any type are converted as needed. This goes beyond the schema's generic parameter 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?

States a specific verb ('Generate') and resource ('text with GenMagic') and enumerates the artifact types: copy, answer, draft, code, SVG, or complete web page. It also distinguishes the tool from text-related siblings by clarifying that 'type' selects the artifact kind, and the sibling names make the text-vs-media boundary clear.

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 clear operational guidance: pass 'type' for a specific artifact, omit it for plain text, and attach files for the model to read. It does not explicitly name sibling tools or state when not to use generate_text, but the artifact list and 'text' scope make the intended use unambiguous.

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 full burden and succeeds. It discloses the full state machine (queued/processing/completed/failed), that completed includes a hosted URL, that failed is terminal, and the billing behavior ('charged once, on completion'). This is rich behavioral context beyond what the schema provides.

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 zero wasted words. It front-loads the purpose, then covers states, polling behavior, termination conditions, and billing in a tight, readable structure.

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 simple single-parameter polling tool, everything an agent needs is present: what states to expect, what the final success state returns, when to stop polling, and the billing consequence. No output schema exists but none is needed given the state descriptions.

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 the single 'id' parameter is well described in the schema as the job id returned by create_video. The description reinforces this provenance by saying 'started with create_video' but adds no new parameter-level detail. 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 and resource: 'Check a video started with create_video.' It clearly identifies the tool as the status-polling counterpart to the creation tool and distinguishes it from the sibling generation tools (create_video, generate_image, generate_speech, generate_text), which have 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?

Provides explicit usage guidance: poll every few seconds, stop on terminal states, and the exact statuses to expect. It tells the agent when to use the tool (after create_video) and how long to keep using it. The terminal-state rule removes ambiguity about when to stop polling.

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