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 does so well: it discloses that the call is asynchronous, returns a job id immediately, charges nothing at kickoff, never charges a failed render, and that polling is required to obtain the hosted video URL. It also notes brand personalization is applied automatically when the account has it enabled.

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 tightly packed sentences, front-loaded with the action first, then async behavior, next step, and billing semantics in descending order of importance. No sentence is filler; the discovery hint and pricing note both serve the caller.

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 must explain the return path, and it does: a job id now, hosted URL via get_video polling. Billing behavior and the optional brand personalization are also covered, leaving no material gap for a 6-parameter async 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%, so each parameter is already fully documented in the schema, including the pointers to list_models for model ids, durations_seconds, resolutions and audio_supported. The description mostly restates the same model-support constraints, adding only the per-second pricing hint; 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 ("Start generating a video from a text description with GenMagic") and immediately scopes it to text-to-video models, clearly distinguishing it from sibling generators like generate_image, generate_music, generate_speech and generate_text. It also separates itself from get_video by framing this tool as the creator that returns a job id.

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 routes the agent to the companion tools: list_models with category "video" to discover models and prices, and get_video for polling "every few seconds until the status is 'completed'." The when-to-use context (asynchronous text-to-video generation) is stated with no inference required.

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 disclose useful behavior: output is returned inline plus a hosted URL, and brand personalization applies automatically when enabled. It does not address auth/permissions, cost/credit consumption, or rate limits, which are material 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?

A single compact cluster of sentences with the core generation behavior front-loaded and the mode-switching clauses following. Nearly every clause earns its place; the brand-personalization sentence at the end is slightly peripheral but still informative.

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, so the description's statement of the return format (inline image + hosted URL) is genuinely valuable. It covers all three usage modes and the model-selection path, leaving only auth and cost details unaddressed.

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 all five parameters are already documented in the schema. The description reinforces the semantics of 'image' (image-to-image) and 'type' ('logo'), but adds little beyond what the schema states, 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+resource (generate an image from a text description) and immediately distinguishes three modes: text-to-image, image-to-image via the 'image' param, and logo generation via 'logo'. An agent can tell it apart from create_video, generate_music, and the other siblings 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?

Gives clear conditional guidance: pass 'image' to transform rather than generate, and set type 'logo' for a brand mark. It also routes the agent to list_models for model ids and prices. It stops short of stating when NOT to use it or naming a sibling alternative explicitly.

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 does disclose useful behavior beyond structured data: the return shape ('audio inline plus a hosted URL') and an automatic personalization behavior ('on-brand in mood ... when brand personalization is on'). It omits cost, latency, auth/permission needs, and whether generation is synchronous or async.

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 with no filler, and the core capability plus return format are front-loaded. The trailing personalization sentence is genuinely informative rather than redundant, though it could be folded into the core statement.

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 compensates by describing the return payload (inline audio + hosted URL), and the 100%-covered input schema handles parameters. It leaves an agent without cost/async/auth expectations, but for a two-parameter generation tool it is close to 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 description coverage is 100%, so both parameters are already fully documented, including the list_models lookup for model ids. The description adds no syntax, format, or constraint detail beyond what the schema says, so the baseline of 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+resource (generate an original music track from a text description) and immediately scopes it against siblings like generate_image/generate_speech via the word 'music'. An agent can tell instantly what this produces and from what input.

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?

Usage is implied by 'generate ... from a text description', but there is no explicit when-to-use guidance, no conditions that would steer an agent away, and no named alternative among generate_image/create_video/generate_speech. Sibling coverage exists in the toolset, so the omission matters.

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 does disclose return behavior ('audio inline plus a hosted URL') and the verbatim voicing contract, which is genuinely useful; however it says nothing about authentication requirements, cost/credits, rate limits, or whether the hosted URL expires, leaving meaningful behavioral 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?

Three short sentences with no waste; the core purpose is front-loaded and the return value and voicing contract follow immediately. Every sentence carries 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?

With no output schema, the description appropriately covers the return shape (inline audio plus hosted URL), and the 100%-covered input schema handles parameters. Only thin on operational context such as cost or auth, which for a simple generation tool is a minor omission.

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 all three parameters (input, model, voice) are already documented with defaults and cross-references to list_models. The description's 'voiced verbatim' only loosely reinforces the input semantics and adds no syntax or format detail 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?

States a specific verb and resource ('Turn text into spoken audio') plus the provider, and the spoken-audio modality cleanly separates it from generate_music, generate_image, generate_video, and generate_text in the sibling set. An agent can pick it without opening the 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?

No explicit when-to-use or when-not-to-use statement and no named alternative, but the purpose sentence plus 'voiced verbatim' implies the use case (verbatim narration rather than music or generic text). Usage is inferable rather than stated.

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 provided, so the description carries the full burden. It discloses useful behaviors: attachment conversion for non-ingestible formats, automatic brand personalization affecting output palette/typeface, and default model selection. Does not cover rate limits, auth, or failure modes.

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 purpose and artifact types, then attachments, then brand behavior. Three sentences with no obvious filler, though the brand paragraph is somewhat tangential.

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 the key behaviors an agent needs: artifact type routing, attachment handling, brand personalization. Lacks explicit mention of what happens with the 'model' parameter default beyond what schema says, but overall complete for a generation tool with no 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 coverage is already 100%, so baseline is 3, but the description adds value by explaining the semantic effect of 'type' values and the attachment auto-conversion behavior beyond raw 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?

States a specific verb (generate) and resource (text) and enumerates the artifact types it can produce. Distinguishes itself from siblings like generate_image and generate_speech by scoping to text and code/SVG/website artifacts.

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 clear conditional guidance for the 'type' parameter (use 'website'/'svg'/'code'/'writing' or omit for plain text). Doesn't explicitly compare to sibling tools like generate_image, but the artifact-type routing is strong.

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.

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 it well: it discloses auth (no API key), cost (free), result ordering (newest first), and the semantic meaning of the 'default' marker. Only pagination behavior is left unstated, which is a minor omission.

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 dense sentences with the core purpose front-loaded and no filler. The parenthetical inventory of per-category detail fields is long but earns its place by previewing the return shape in the absence of an output 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?

Without an output schema or annotations, the description supplies the essentials: what is returned (id, price, capability/voice/resolution details), ordering, filterability, the default-model rule, and cross-tool linkage. 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 description coverage is 100%, so all four parameters (limit, search, category, capability) are already documented in the schema. The description restates filtering by category and search but adds no syntax, defaults or edge-case detail beyond what the schema provides, so 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 ('List the AI models GenMagic runs') plus ordering ('newest first') and the fields returned. It is unmistakably distinct from the generate_* siblings, which it references by name.

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 routes the agent: 'Pass a model's id as model to generate_text, generate_image...' and explains that the model marked default runs when none is named, including the generate_text/no-type case. This is exactly the when-to-use context an agent needs before invoking a generation tool.

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