APICK AI

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

The description adds substantial behavioral context beyond the annotations: immediate point deduction (장수×25포인트 선차감), instant refund for failed images, no cancellation after submission, and per-image pricing. It also confirms the async nature of the operation. Nothing contradicts the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) — the cost and no-cancellation policy are exactly the kind of disclosure that annotations don't capture.

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 with zero waste: the first states the core function and scope, the second covers cost/refund/cancellation policy, and the third states pricing. Information is front-loaded with the primary purpose first, and 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 9-parameter, no-output-schema submission tool, the description covers the essential operational aspects: what it does, cost, refunds, cancellation, and async behavior. The main gap is that it doesn't state what the response contains (e.g., a batch/task ID) or how to track completion, though the async framing and sibling names image_batch_status and image_batch_result make this inferable.

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 meaningful semantic context beyond the schema: it binds image_count to the cost formula (장수×25포인트), explains mode covers both generate and edit, and clarifies the async behavior of the whole operation. This goes beyond what the schema's brief field descriptions provide, though it doesn't enumerate individual parameter details.

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 (접수합니다 - accepts/submits), resource (이미지 대량 작업 - bulk image tasks), and scope (1~50 images, async, generate or edit). It clearly differentiates from the single-image siblings image_generate and image_edit by emphasizing the batch and asynchronous nature, so an agent can tell them apart 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?

The description implies usage context through '1~50장의 비동기 생성 또는 편집 작업' (bulk, async, 1-50 images), which signals when to prefer this over single-image tools, and the async wording implies pairing with image_batch_status/image_batch_result. However, it never explicitly names alternatives, states conditions for choosing this tool, or says when not to use it.

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?

Annotations already provide readOnlyHint=true; the description adds the key behavioral constraint that only completed jobs are valid and that the output is image content. It does not contradict annotations, though it remains silent on error behavior for invalid indexes or incomplete jobs.

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, front-loaded sentence that conveys the action and condition without unnecessary words. The '[무료]' note is extra but minimal and does not detract from clarity.

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 read-only tool with fully described parameters and a clearly stated return type (image content), the description is sufficiently complete. It does not detail edge cases like index-out-of-range, but that is already constrained by schema maximum/minimum and does not impede 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?

Both parameters have schema descriptions (job_id as '작업 ID' and index with 0-based semantics and min/max), giving 100% schema coverage. The description adds no parameter-specific detail beyond what the schema already documents, 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?

The description uses a specific verb ('반환합니다') and a precise resource ('완료된 대량 작업 결과 중 지정한 한 장'), clearly indicating it retrieves one image from completed batch results. This differentiates it from creation or status siblings, making its purpose unmistakable.

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 when a batch job is completed ('완료된'), but it does not explicitly state when to use this tool over alternatives like image_batch_status or image_batch_create. No direct exclusions or alternative referrals are provided.

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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context beyond that: it surfaces billing-related state (pre-deduction, refund, current deduction points) and marks the operation as [무료]. This helps the agent understand what kind of read operation it is and what domain information is involved, with no contradiction to the annotations.

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 that names the resource, the action, and the key returned information. The [무료] note is compact and informative, and there is no redundant wording.

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 one simple parameter, readOnly annotations, and no output schema, the description reasonably covers what the tool returns by listing progress status and point-related fields. It does not enumerate possible status values or error behavior, but for a 1-parameter status query this is a minor gap rather than a significant 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?

The schema has 100% coverage for the single required parameter job_id, including its format pattern and description, so the description does not need to compensate. The description adds no extra semantic detail about job_id itself, which is appropriate given the high schema coverage.

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 (조회합니다, 'queries') and a precise resource: the status of batch image jobs, including progress and point-deduction details like 선차감, 환급, and current deducted points. This clearly differentiates it from sibling tools such as image_batch_create and image_batch_result, even without naming them explicitly.

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?

There is no explicit when-to-use guidance or mention of alternatives. The intended use—checking the status of a batch image job by job_id—is implied by the description, but the description does not tell the agent when to prefer this over image_batch_result or when it is not appropriate.

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?

The description adds useful behavioral context beyond the annotations: it advertises the cost (25 points per image) and clarifies the output is returned as image content. Annotations already cover idempotency and non-destructive behavior, so the description's additional pricing and return-type disclosure is meaningful and non-redundant.

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 short and front-loaded with the core purpose, and the cost sentence is useful. However, the pricing information is repeated unnecessarily ('장당 25포인트입니다' and '[이미지당 25포인트]'), introducing minor redundancy.

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 six parameters, a complete schema, and annotations covering idempotency and safety, the description provides enough context: core operation, single-image scope, return type, and pricing. There is no output schema, but the description adequately states that the result is image content. Explicit guidance on sibling alternatives is missing, but that is already penalized under usage guidelines.

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 input schema already documents all parameters including prompt, image_url, size, background, output_format, and idempotency_key. The description only restates the two core parameters ('원본 이미지' and '편집 지시') without adding new semantic detail, which matches the baseline 3 for high schema coverage.

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 a specific action: editing a single image using an original image and an edit instruction, and returning image content. The phrase '한 장' (one image) differentiates it from batch-oriented siblings like image_batch_create, and the editing framing distinguishes it from image_generate.

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 use case: you have an original image and an edit instruction and want one edited image back. However, it does not explicitly say when to prefer this tool over image_generate or the batch tools, nor does it mention any exclusions or alternative conditions.

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?

The description adds useful behavioral context beyond the annotations: it states the output is a new image, clarifies that the reference image is only reference material, and discloses the cost of 25 points per image. This complements the annotations readOnlyHint=false and idempotentHint=true without contradicting them.

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: the first sentence states the core function, the second clarifies the reference-image behavior, and the third gives cost. The only minor redundancy is repeating the 25-point cost in brackets after already stating it in prose.

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 description covers the key operational details: single image generation, reference image purpose, new-image output, and cost. It relies on the schema for parameter details, which is appropriate given 100% schema coverage. It does not describe the return payload, but the output-schema absence is partially mitigated by the clear statement that a new image is produced.

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 meaningful semantics for reference_image_url by explaining that it is used to understand product, person, color, and composition, and that the result is a newly created image. It also clarifies that the prompt can be used alone or with a reference image.

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 action ('generate one image') and the resource, explicitly noting 'one image' (한 장) to distinguish from the batch sibling. It also explains that the result is a new image, which differentiates it from an editing operation like image_edit.

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 clear usage context: text alone or reference image plus text, and describes the reference image's role. However, it does not explicitly mention when not to use this tool or name alternatives such as image_edit or image_batch_create, so it stops 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?

Annotations include readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: asynchronous nature, idempotency key usage, point reservation/deduction policy, and result_url validity (7 days). However, it doesn't detail error handling or exact response structure, but given the annotations already convey the idempotent and non-read-only nature, the description adds enough to be a 3.

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 moderately concise but contains redundant bilingual content: it repeats the full description in both English and Korean. The Korean portion repeats the same information, making it longer than necessary. The front-loading is decent, but the bilingual repetition reduces conciseness and structure efficiency.

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's high complexity (24 parameters, multiple inter-dependent enums) and lack of output schema, the description provides a good high-level overview but relies heavily on external developer guides for critical details (version-specific prices, allowed combinations). It doesn't mention response format or error handling, but for an async job submission, it covers the essential flow. It's a solid 3, not a 4, because the version-dependent rules are not summarized.

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. The description adds significant semantic value beyond the schema: it explains pricing (points per second), modes (text/image/reference), and explicitly points to version-specific tables for details. It also clarifies audio behavior and that version/tier default values depend on each other, which is not fully in 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 it submits an asynchronous Kling video generation job with specific modes (text/image/reference) and mentions the version/tier selection. It is distinguishable from sibling tools like seedance_jobs_create and veo_jobs_create by naming the model, but does not explicitly differentiate itself from other job creation tools, though the model name is a strong differentiator.

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 clear usage guidance: it explicitly tells the agent to use kling_jobs_status to check status and download via result_url, and mentions the billing/reservation policy. It does not explicitly state when NOT to use this tool or when to prefer a sibling, but the model-specific isolation and typical async generation workflow make the context clear.

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?

Annotations already declare readOnlyHint and openWorldHint=false, so safety profile is covered. Description adds useful behavioral facts: result URL delivery on completion and 7-day result validity. Does not explain output format beyond that, but adds real value over annotations.

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 purpose, then Korean translation and key behavioral facts. The '[무료]' at the end is slightly redundant with '무료입니다' but otherwise compact.

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 one required param, full schema coverage, no output schema, and read-only annotations, the description covers purpose, linkage to creation tool, result delivery, and retention. Enough to invoke 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 description coverage is 100% and the single job_id param is documented there. The description adds no format or constraint info beyond the schema, so 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 ('status of a Kling video generation job') and explicitly ties it to the creating sibling 'kling_jobs_create'. Easily distinguished from other *_status 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?

Clarifies it is for jobs submitted via kling_jobs_create, providing clear context. Does not state when not to use it or rate limits, but the polling relationship is implied well.

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?

Annotations declare readOnlyHint=true, but the description states '토큰 사용량에 비례해 포인트가 차감됩니다' (points are deducted in proportion to token usage), which is a state-changing side effect. This directly contradicts the readOnly hint. The statelessness information is useful, but the contradiction overrides any positive transparency contribution.

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 main purpose is front-loaded and the stateless protocol explanation is compact. However, the second sentence repeats the same idea in Korean, and the trailing '[무료]' tag after the point-deduction warning is confusing. Not 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?

Given 8 parameters and no output schema, the description covers the essential calling protocol: select a model, send the full history, reuse compacted_messages, and expect point deduction. Error cases and output shape are not described, but 'assistant reply' plus the detailed input schema make correct invocation reasonably achievable.

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 parameter descriptions for model, messages, content, speed, compact, max_tokens, and temperature are already detailed. The description reinforces the compacted_messages reuse pattern and model lookup, but these are also expressed in the schema's parameter descriptions, so it adds minimal new value.

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 it sends a chat request to a selected LLM model and receives the assistant reply, with both English and Korean wording. The verb-object pair is specific and unambiguous. It does not explicitly differentiate itself from sibling tools like text_polish or text_summary, so it stops short of a 5.

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 strong operational context: the server is stateless, full history must be sent via messages, compacted_messages should be reused for the next turn, and models can be looked up with llm_models. However, it never states when to use llm_chat versus the specialized text_polish/text_summary alternatives, or when not to use it, so usage selection is only implied.

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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it is free, returns everything in one response ('한 응답에 포함합니다'), and enumerates the fields included. No contradiction with annotations exists.

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 front-loaded with the main purpose, but it repeats information in English and Korean ('List available text-generation LLM models' / '텍스트 생성 모델 카탈로그를 반환합니다') and duplicates the free indicator as '무료입니다' and '[무료]'. Useful details remain, but the repetition keeps it from being tighter.

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 compensates by listing the returned fields: pricing, family, size, multimodal flag, tags, use_cases, and max_context. It also states the intended relationship to llm_chat. Minor gaps like filter combination behavior and exact output shape are acceptable for a simple read-only catalog 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%, with each parameter already documented with its allowed values (e.g., tag as 'reasoning'|'coder'). The description does not add meaning beyond the schema; this matches the baseline of 3.

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: 'List available text-generation LLM models with per-token pricing and max context.' The Korean portion adds concrete output contents, and the tool is clearly distinct from siblings like llm_chat, image_generate, and text_polish.

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 when to use this tool: 'llm_chat Tool의 model 입력값을 찾을 때 사용합니다' (use it when finding the model input for the llm_chat tool). It provides clear context but does not explicitly describe when not to use it or name alternative catalog 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?

Adds substantive behavior beyond the annotations: the job is asynchronous, billing is reserved at submission (duration × per-second points by resolution), finalized on completion, and fully refunded on failure or timeout, plus a 7-day result_url validity window. These are exactly the consequences an agent needs and are not derivable from the readOnly/idempotent hints.

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 the core action, but the English and Korean sentences duplicate the same content, and the bracketed pricing block is dense. Every element is relevant, yet the bilingual redundancy bloats the length without adding unique 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?

For a 62-parameter async job tool with no output schema, the description covers the lifecycle, billing/refund outcome, and where to retrieve results. It leaves the numbered reference_* URL slots entirely to the schema, which is acceptable given their uniform 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%, so the baseline is 3, but the description adds cross-parameter semantics: supported modes, that allowed durations/prices depend on version and tier, and the per-second pricing table by resolution. It surfaces interdependencies the flat schema does not make obvious.

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 ('Submit an asynchronous Seedance video generation job'), names the supported modes, and points to seedance_jobs_status for follow-up. It is clearly distinguishable from sibling job-creation tools like kling_jobs_create and veo_jobs_create.

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 workflow routing: submit here, poll with seedance_jobs_status, then download via result_url. It notes that supported modes/durations/prices depend on the selected version. It does not explain when to prefer this over the sibling veo/kling job tools, but the context is otherwise explicit.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral details beyond annotations: the result_url is a REST download address, results remain valid for 7 days after completion, and the operation is free. It does not cover polling behavior or error states, keeping it from 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?

The definition is front-loaded with the English purpose and then provides Korean translation and completion details. There is minor redundancy (free is stated twice, and the Korean repeats the English), but the information is well organized and not bloated.

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 must carry output-related context. It does so by explaining that a completed job returns a result_url and that results are valid for 7 days. It leaves out status values or polling frequency, but is otherwise sufficient for a status-check 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 the single job_id parameter is documented in the schema with a pattern and description. The description adds no parameter syntax or meaning beyond the schema, 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?

The description states a specific verb (Check) and resource (status of a Seedance video generation job) and directly ties the job to the seedance_jobs_create sibling tool. This lets an agent distinguish it from other job-status tools like kling_jobs_status or veo_jobs_status 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?

The description explicitly says the job is 'submitted via seedance_jobs_create', giving clear context for when to use it. It does not name alternatives or exclusions, which is the only missing piece for a 5.

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?

Annotations already mark the tool read-only and closed-world; the description adds the 100,000-character ceiling, server-fixed model/parameters, latency optimization, and per-request point cost. It doesn't describe the return format, but for a simple transformation this is adequate context.

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 function is front-loaded and the length is manageable, but the English and Korean sentences largely duplicate the same message, and the bracketed point cost is redundant with the preceding sentence. Several sentences repeat information without adding new guidance.

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 transformation tool with a fully documented schema and read-only annotations, the description covers the input limit, operation, and cost model. The absence of an output schema is offset by the obvious return of polished text, though an explicit return description would make it fully 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?

The input schema covers 100% of parameter meaning with its own description of the text field, so the baseline is 3. The description repeats the character limit but adds no unique parameter-level semantics 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 action (polish), a specific resource (input text), and the concrete transformations (grammar, spelling, awkward phrasing, sentence order) while preserving meaning. This clearly differentiates it from the sibling text_summary, which would condense rather than polish.

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 context in which to use the tool is implied: when a text needs grammar/spelling/phrasing corrections. However, it never explicitly contrasts with alternatives or states when not to use it (e.g., text_summary for summarization), so the routing burden is left to the agent.

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?

Annotations already provide readOnlyHint=true, and the description adds meaningful behavior beyond that: the model/parameters are server-fixed, responses are optimized for speed, and points are deducted per request regardless of token count. It also discloses the 100-point cost, which is useful operational context.

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 English first sentence is clear and front-loaded, and the cost/model details are compact and useful. However, the Korean sentence largely repeats the same information as the English sentence, adding redundancy without substantial new 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?

For a simple one-parameter, read-only summarization tool, the description is largely complete: it specifies the input limit, output language, server behavior, and cost. There is no output schema, but the return value is implied as the Korean summary text. Minor details like behavior when the limit is exceeded are not specified, but this is not critical.

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 already describes the only param, text, with its 100,000-character limit, so schema description coverage is 100%. The description repeats the limit but adds little new parameter semantics beyond clarifying the output is Korean. 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?

The description states a specific verb ('Summarize'), a clear resource ('long text up to 100,000 characters'), and a concrete output ('concise Korean summary'). This clearly distinguishes it from image and chat siblings, though it does not explicitly differentiate it from the closely related text_polish 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?

No explicit guidance is given about when to use this tool versus alternatives such as text_polish or llm_chat. The purpose is inferable, but there are no stated exclusions, prerequisites, or routing rules to help an agent choose between text_summary and text_polish.

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?

Discloses important behavioral traits beyond annotations: asynchronous execution, point reservation before submission, refund on failure/timeout, 7-day result_url validity, and version-dependent constraints. These are not visible in the annotations and materially affect how an agent should call and follow up on the 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 front-loaded with the core purpose and immediately moves to billing and lifecycle guidance. The English and Korean sections somewhat duplicate each other, but every sentence carries substantive information. Slightly longer than strictly necessary, yet well organized.

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 16-parameter asynchronous job with no output schema, the description covers submission, status polling, download URL, validity, billing, refunds, and version-dependent variability. It relies on an external developer guide for version-specific allowed values, but the schema already points there, so the description is reasonably 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 the baseline is 3. The description adds a pricing formula (900 points per second × duration) that relates to parameters, but does not otherwise explain individual parameters beyond what the schema already provides. This is adequate given the schema's thoroughness.

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 an explicit action, 'Submit an asynchronous Veo video generation job', and identifies the Veo-specific resource. This clearly distinguishes it from sibling tools like kling_jobs_create, seedance_jobs_create, and image_generate. The bilingual repetition reinforces the purpose 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?

Tells the agent to select version/tier, to use veo_jobs_status for status checks, and to download from result_url. It also warns that supported modes, durations, and prices depend on the selected version. It does not explicitly enumerate alternatives like Kling/Seedance, but the Veo-specific naming and status-tool pointer provide strong practical 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavior — completion surfaces a result_url (REST download address) and results remain valid for 7 days after completion, plus it is free. It omits things like what status values exist or terminal/error states.

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-loads the core action and is short. There is minor redundancy in the bilingual restatement and the duplicated free-of-charge marker ('무료입니다. [무료]'), but nothing is bloated.

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 read-only, single-parameter polling tool with no output schema, the description covers the essentials: input provenance, the completion signal (result_url), and the 7-day retention window. It would be complete with a hint about possible status values or polling expectations.

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?

With one parameter at 100% schema description coverage, the schema already documents job_id and its hex pattern, so the description adds no parameter-level meaning (format, where the ID comes from beyond the create call). 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 ('Check the status of a Veo video generation job') and names the sibling that produces the job (veo_jobs_create), so an agent can place it immediately in the create-then-poll workflow. 'Veo' also differentiates it from the kling_jobs_status and seedance_jobs_status 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?

Makes the usage context explicit: it is for jobs previously submitted via veo_jobs_create, implying it should be called after creation. It stops short of when-not guidance or polling cadence (e.g., how often to re-check while the job is running).

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