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 discloses a useful output trait ('its URL when it is ready') and implies a non-mutating read, but says nothing about other terminal states (failure, expiry) or polling/latency behavior beyond what the schema's 'wait' parameter already documents.

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 sentence with the core action front-loaded and no filler. Every clause (status, source tools, URL-on-ready) contributes 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 must convey the return shape, and it covers only the success case (a URL when ready). It omits the pending/other status values an agent would need to branch on, leaving a meaningful gap for a status-polling 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%, and both parameters (run_id, wait) are documented in the schema itself. The description adds no syntax or format detail beyond the schema, 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 and resource ('Read the status of a run') and distinguishes itself from siblings by naming the exact tools that create the run (generate_video, generate_image). An agent can immediately tell this is the polling/read companion to the generation tools.

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 implicitly and clearly scopes usage to runs created by generate_video or generate_image, which is the key routing condition among siblings. It does not state any exclusions or edge cases (e.g., how long run records persist), but the primary when-to-use context is present.

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. 'Free to call' is a genuine behavioral disclosure (no cost/credit consumption), but it says nothing about rate limits, whether the call is read-only, errors when the key is missing/invalid, or the shape of the returned balance.

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, zero padding, with the resource identity front-loaded and the cost note appended as supporting context. Every clause 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 no-parameter read of a single value, this is nearly sufficient. The only gap is that no output schema exists and the description does not indicate what the returned credit balance looks like (number vs. object) or how to interpret it.

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 and the schema is empty, so there is nothing for the description to clarify. Baseline 4 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 identifies the exact resource (remaining credits) and scopes it to the account behind EMAKI_API_KEY, which distinguishes it from the generate_* and check_status siblings. It is a noun phrase rather than an explicit verb+resource statement, so it is clear but slightly less actionable than a '5' would require.

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 only implied: an agent infers it should call this to check balance. There is no explicit when-to-use, no mention of how it relates to check_status or when to prefer it over generating, and no stated preconditions beyond the implicit API key.

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 some behavior: it returns a URL and consumes emaki credits. It omits key operational traits such as what happens when wait=false (likely a job needing check_status), latency expectations, or failure/auth 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, no filler, with the core action and return value front-loaded. Every sentence contributes (action, default/cost, downstream use).

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?

It covers what is returned and the credit cost, but with no annotations and no output schema, the description should explain the async contract implied by the wait parameter and check_status sibling. Six parameters and a cost-bearing operation warrant more disclosure than is present.

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 is 3 and the schema already documents prompt, model, wait, quality, resolution, and aspect_ratio. The description only adds cost rationale ('lowest-cost model') for the default model, offering no guidance on when to pick other enum values.

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 an image from a text prompt on emaki.ai'), names the platform, and declares the return value (a URL). It also differentiates itself from the sibling generate_video by positioning itself as the source for a first frame.

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 usage context: it is the lowest-cost option and a good way to make a first frame for generate_video, which routes the agent between siblings. It does not, however, state when not to use it or how it compares to other image-producing paths.

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 so well: it discloses cost ('Runs on your emaki credits, the same price as on the website'), latency ('Video takes minutes'), sound-in-same-pass behavior, and the async run-id return contract. These are non-obvious behaviors an agent must plan around.

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 dense sentences, front-loaded with purpose, then default model, then cost, then async contract. Every sentence earns its place with no repetition of schema fields.

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 9 parameters, no output schema, and no annotations, the description fills the critical gaps: what is returned (a run id), how to continue (check_status), cost implications, and expected latency. An agent has everything needed to invoke and follow up correctly.

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, but the description adds cross-parameter meaning the schema does not: the Seedance 2.5 default, the 4–30s range coupling, and the fact that image_url switches the tool into image-to-video mode. That extra interpretive context lifts it above baseline.

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 a video clip from a text prompt on emaki.ai') and immediately distinguishes the two modes: text-to-video vs image-to-video via image_url. It also names the default model and routes the agent to the check_status sibling.

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?

Explains the two usage modes and the asynchronous default ('returns a run id to poll with check_status'), plus the wait flag as the blocking alternative. It lacks any when-not-to-use guidance against siblings like generate_image, so it stops short of a 5.

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