APICK AI

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

Adds substantial behavior beyond the annotations: async submission, per-image pricing tiers with upfront deduction and refunds for failures, non-idempotency (same request re-creates a new job), and irreversibility ('접수 후에는 취소할 수 없습니다'). This reinforces idempotentHint=false with concrete detail the annotation can't convey.

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?

Purpose is front-loaded and sentences are tight, but the pricing (basic 40P·advanced 350P·premium 1,400P) is stated twice — once in the body and again in the trailing bracket — which is pure 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 an async, non-cancelable, paid batch job the description covers cost, refunds, and irreversibility well. The main omission is any pointer to image_batch_status/image_batch_result, which the agent needs to retrieve results, though the async nature implies polling.

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 9 parameters are already documented, including the quality tiers and their prices. The description repeats the same price mapping in prose, adding essentially no new meaning over 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 (접수/accept) and resource (비동기 생성·편집 대량 작업 for 1-50 images), so the agent knows this submits bulk async image jobs. It never names the single-image siblings (image_generate, image_edit) it competes with, so differentiation is left to the '대량'/'1~50장' scope only.

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 1-50 image count and '대량' framing imply this is the bulk path versus single-image tools, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable from scope 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?

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?

Annotations already declare idempotentHint=false and openWorldHint=true, but the description adds real value by disclosing concrete per-image pricing by quality tier and confirming that resending the same request re-edits and re-charges. This cost/non-idempotency context is genuinely useful for a paid mutation tool, though it omits any note on output delivery or latency.

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 pricing information is stated twice – once in prose and again in a bracketed line – which is redundant rather than additive. The core edit action is front-loaded, but the duplicated cost block wastes space.

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 and a fully documented input schema, the description covers the key non-parameter concerns: cost, per-image billing, and non-idempotent re-charging. It is complete enough to call correctly, though it could note output format defaults or delivery behavior.

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 six parameters are already documented in the schema, including the quality-to-price mapping and size enum. The description restates the quality pricing but adds no syntax or format detail beyond the schema, 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 (이미지 한 장), and the '한 장' (single image) scoping distinguishes it from batch siblings like image_batch_create. It does not explicitly name an alternative such as image_generate, so it stops short of full sibling differentiation.

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: you have an original image plus an edit instruction. There is no explicit when-to-use guidance or routing to alternatives like image_generate for new images, though the input/output distinction is inferable from the required params.

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 readOnly=false, idempotentHint=false and openWorld=true, yet the description adds the key consequence: the same request is regenerated and re-billed every time, plus per-quality cost figures. That billing/idempotency context is genuinely useful beyond the structured hints, though it says nothing about latency or how the resulting image is delivered.

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?

Purpose and cost are front-loaded, which is good, but the per-image pricing is stated twice – once inline and again in a bracketed duplicate – which is redundant bloat.

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 and six mostly self-documented parameters, the description supplies the cost model, non-idempotent billing behavior and mode coverage that an agent needs before spending credits. It would be more complete if it noted whether generation is synchronous or how the image is returned.

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 every parameter (size, prompt, quality, background, output_format, reference_image_url) is already documented in the schema. The description only echoes the quality-to-price mapping already present in the quality field, adding no syntax or format detail beyond 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 names a specific verb (생성) and resource (이미지 한 장), and the explicit '한 장' (single image) scope implicitly separates it from the batch sibling image_batch_create. It stops short of naming any sibling outright, so it is clear but not maximally differentiated.

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?

It describes the two supported modes (text-only vs. reference-image-plus-text), which implies how to invoke it, but gives no explicit when-to-use/when-not guidance and never points to image_edit or image_batch_create as alternatives.

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 cover safety/idempotency, but the description adds genuinely non-obvious behavior: points are reserved at duration × 410/sec, confirmed on completion, and fully refunded on failure or timeout, and result_url is a REST download link valid for only 7 days. That billing/refund and expiry disclosure is exactly the kind of context an agent cannot infer from structured fields.

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?

Content is front-loaded with the core action first, then operational detail. The bilingual restatement (English then Korean) is slightly redundant and inflates length, but every sentence carries distinct information about modes, status flow, download, and billing.

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 24-parameter, no-output-schema, asynchronous job tool, the description covers the essential missing pieces: mode selection, version-dependent constraints, the follow-up status tool, the result download, and the billing lifecycle. Return-value structure beyond result_url is not described, but no output schema exists and the key artifact is named.

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 real value beyond the schema: the pricing formula tied to duration, the default version (3.0), the three supported modes, and the fact that valid tier/resolution/duration combinations are version-dependent. It does not add syntax detail for individual params, so it sits just 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?

The description opens with a specific verb and resource ('Submit an asynchronous Kling video generation job') and immediately scopes it with version/tier dependence. It also names the sibling kling_jobs_status as the status-check path, so an agent can distinguish this submission tool from the polling tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the full lifecycle: submit here, poll with kling_jobs_status, then download from result_url. It also flags that modes/durations/prices depend on the selected version. It stops short of explicit when-not-to-use guidance (e.g., vs veo_jobs_create or seedance_jobs_create), but the context is 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 only declare readOnlyHint/openWorldHint, so the description correctly carries the behavioral load and delivers: the server is stateless and keeps no history, calls are metered and deduct points proportional to tokens, and the rate is given as [token cost × FX × 1.4, rounded up, minimum 5P from 2026-11-06]. That cost/stateless disclosure is real value beyond annotations; it stops short of describing failure modes, quota ceilings, or latency expectations.

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?

Purpose and model-discovery pointer are front-loaded, then scope (stateless) then cost. The bracketed pricing formula and the billing date are somewhat noisy detail for a tool description, but each sentence still maps to a decision the caller must make.

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 the description partially compensates by naming the response field to reuse (compacted_messages). Given 8 parameters, one nested object, and a stateless contract, this is nearly complete — only the fuller response shape and error/refund behavior on failed calls are unstated.

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 every parameter is already documented in the schema, which sets the baseline at 3. The description reinforces only the messages/compacted_messages loop; it adds no syntax or format detail (e.g., content-vs-messages precedence is already 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?

States a specific verb and resource ('Send a chat request to a selected LLM model and receive the assistant reply'), and explicitly differentiates from the sibling llm_models, which only lists models. An agent can tell immediately this is the invocation tool, not the discovery 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?

Points to the sibling that must be called first ('사용 가능한 모델은 llm_models Tool로 조회합니다') and prescribes the multi-turn workflow (resend full history each call, reuse compacted_messages). It lacks explicit when-not-to-use guidance (e.g., use text_summary/text_polish for pure reformatting tasks instead of a paid chat call).

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.